- Notifications
You must be signed in to change notification settings - Fork 519
[azure_application_insights] [app_state] Add dimensions, metric_type to the app_state data stream #7550
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🌐 Coverage report
|
| type: flattened | ||
| description: > | ||
| Azure metric dimensions. | ||
| type: group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the purpose behind converting flattened to keyword type? Can this be a breaking change?
Alternate options that can be tried can be found here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow I think it could be a backporting mistake that this was changed to flattened, for example in beats is used object - https://github.com/elastic/beats/blob/main/x-pack/metricbeat/module/azure/_meta/fields.yml#L53-L58
maybe worth to double-check with codeowners
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, not sure why flattened was used in the data stream that's why I thought changing it makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be considered as a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may not be an isolated mistake but an intentional change.
I see a similar change in mapping the azure.resource.tags field. Here is how we are mapping the azure.resource.tags field in the Beats module and several metrics integrations:
| Metrics | Mapping | |
|---|---|---|
| Integrations | Azure Metrics | object |
| Metricbeat | Azure module | object |
| Integrations | Azure Billing | flattened |
| Integrations | Azure App Insights | flattened |
| Integrations | Azure App State | flattened |
I agree with @agithomas that we must double-check whether this is a breaking change.
Switching field types should not create mapping exceptions since the mapping will only change at rollover, however the search behavior may vary due to the different mapping types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed about this on slack with @gpop63. TLDR; In principle this change looks safe to me, if we are completely sure that this is the list of fields we can have here.
In principle this won't be a breaking change, because keyword fields allow the same operations as individual members of a flattened object (probably more). It could be considered an enhancement because keyword fields probably have better support in Kibana than the flattened type.
It could be breaking only if somehow users put additional fields under azure.dimensions, but I guess there is no reason to think that.
Somehow I think it could be a backporting mistake that this was changed to
flattened, for example in beats is usedobject- https://github.com/elastic/beats/blob/main/x-pack/metricbeat/module/azure/_meta/fields.yml#L53-L58
The flattened type was introduced relatively recently, so this is why you can see it more used in integrations than in Beats. It comes to solve a couple of issues we had with fields with wildcards:
- You can have mapping conflicts if there are fields with dots (you cannot store
labels.appandlabels.app.nameas different fields in the same index, becauselabels.appwould need to be mapped as an object and a keyword at the same time).subobjects: falsecan also help with this issue, but is not supported in packages yet. - You can have "field mappings explosion" if there are too many different fields under this path. This doesn't happen with flattened because it only requires a single mapping for any number of subfields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But regarding the breaking change, even if it doesn't seem to be actually breaking, please try to do an upgrade from the previous mapping to the proposed here in any case 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsoriano tested upgrading and everything is fine, no errors thrown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsorianom, thank you for chiming in and sharing more details and backstory!
@agithomas, after these clarifications, I see no reason to dig more. In addition, @gpop63 tested the mapping transition is smooth.
subobjects: false can also help with this issue, but is not supported in packages yet.
I am working on adding subobjects to package-spec, so we'll have this option soon.
| type: flattened | ||
| description: > | ||
| Azure metric dimensions. | ||
| type: group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow I think it could be a backporting mistake that this was changed to flattened, for example in beats is used object - https://github.com/elastic/beats/blob/main/x-pack/metricbeat/module/azure/_meta/fields.yml#L53-L58
maybe worth to double-check with codeowners
| dimension: true | ||
| description: The name of the request that was made. | ||
| | ||
| - name: metrics.*.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is azure.metrics actually present in the document? in azure_metrics package this field was usually not needed - and was removed
sample document does not include it and metrics are stored under azure.app_state -
integrations/packages/azure_application_insights/data_stream/app_state/sample_event.json
Lines 63 to 75 in 987dd5e
| "azure": { | |
| "app_state": { | |
| "end_date": "2021-08-23T14:37:42.472Z", | |
| "requests_count": { | |
| "sum": 4 | |
| }, | |
| "start_date": "2021-08-23T14:32:42.472Z" | |
| }, | |
| "application_id": "42cb59a9-d5be-400b-a5c4-69b0a0026ac6", | |
| "dimensions": { | |
| "request_name": "GET Home/Index", | |
| "request_url_host": "demoappobs.azurewebsites.net" | |
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, metrics could be removed here.
| - observability | ||
| conditions: | ||
| kibana.version: "^7.14.0 || ^8.0.0" | ||
| kibana.version: "^8.9.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this change is required to support azure.metrics.*.* as I understand, so can be reverted if azure.metrics.*.* will be removed and introduced with tsdb enablement pr
| ignore_above: 1024 | ||
| description: Region in which this host is running. | ||
| example: us-east-1 | ||
| dimension: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this field actually present in the document?
If yes - could you please update sample_event -
integrations/packages/azure_application_insights/data_stream/app_state/sample_event.json
Lines 15 to 17 in 987dd5e
| "cloud": { | |
| "provider": "azure" | |
| }, |
| Currently, both From my understanding there are 2 approaches since
I tested upgrading the old package version |
Have you tested this : elastic/elasticsearch#94113 (comment)? |
This reverts commit 987dd5e.
kaiyan-sheng left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the dimensions and metric types look good to me
agithomas left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
| @tetianakravchenko , can you please re-check and validate if it is fine? |
| - name: users_authenticated.unique | ||
| type: float | ||
| metric_type: counter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are those metrics actual counter? in azure_metrics.container_registry I've seen a different behavior for those type of metrics - https://github.com/tetianakravchenko/integrations/blob/master/packages/azure_metrics/data_stream/container_registry/fields/fields.yml#L4-L11
Those seems to be a counter, but in reality it is not constantly growing:

can you please double-check it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah you're right, most are actually gauges.
| type: group | ||
| fields: | ||
| - name: cloud_role_instance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are those fields dimension.* defined?
As I see part of those dimensions here is the same as in segmentNames https://github.com/elastic/beats/blob/main/x-pack/metricbeat/module/azure/app_insights/data.go#L24-L38
wondering if this list of dimensions is complete
I assume that the list defined in beats could need some updates as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
used for app_state configuration - https://github.com/elastic/beats/blob/main/x-pack/metricbeat/module/azure/app_state/manifest.yml
tetianakravchenko left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
| Package azure_application_insights - 1.2.1 containing this change is available at https://epr.elastic.co/search?package=azure_application_insights |
What does this PR do?
Dimensions added:
agent.idazure.dimensions.*azure.namespacecloud.regionazure.resource.idazure.timegrainChecklist
changelog.ymlfile.Author's Checklist
How to test this PR locally
Related issues
Screenshots