Skip to content

Conversation

@gpop63
Copy link
Contributor

@gpop63 gpop63 commented Aug 27, 2023

What does this PR do?

Dimensions added:

  • agent.id
  • azure.dimensions.*
  • azure.namespace
  • cloud.region
  • azure.resource.id
  • azure.timegrain

Checklist

  • I have reviewed tips for building integrations and this pull request is aligned with them.
  • I have verified that all data streams collect metrics or logs.
  • I have added an entry to my package's changelog.yml file.
  • I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

  • [ ]

How to test this PR locally

Related issues

Screenshots

@gpop63 gpop63 self-assigned this Aug 27, 2023
@elasticmachine
Copy link

elasticmachine commented Aug 27, 2023

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2023-10-17T13:45:26.336+0000

  • Duration: 14 min 3 sec

Test stats 🧪

Test Results
Failed 0
Passed 16
Skipped 0
Total 16

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

@elasticmachine
Copy link

elasticmachine commented Aug 27, 2023

🌐 Coverage report

Name Metrics % (covered/total) Diff
Packages 100.0% (0/0) 💚
Files 100.0% (0/0) 💚
Classes 100.0% (0/0) 💚
Methods 57.143% (4/7) 👍 32.143
Lines 100.0% (0/0) 💚
Conditionals 100.0% (0/0) 💚
@gpop63 gpop63 marked this pull request as ready for review August 27, 2023 19:49
@gpop63 gpop63 requested a review from a team as a code owner August 27, 2023 19:49
type: flattened
description: >
Azure metric dimensions.
type: group
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member

@jsoriano jsoriano Sep 4, 2023

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 used object - 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.app and labels.app.name as different fields in the same index, because labels.app would need to be mapped as an object and a keyword at the same time). subobjects: false can 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.
Copy link
Member

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 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zmoog , are you good with the suggestions from @jsoriano or should we take any more input from other engineers?

Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor

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.*.*
Copy link
Contributor

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 -

"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"
}

Copy link
Contributor Author

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"
Copy link
Contributor

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
Copy link
Contributor

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 -

- https://github.com/elastic/integrations/blob/987dd5ec338d1b278ba7002db6e827f87a989798/packages/azure_application_insights/data_stream/app_state/sample_event.json with the latest sample

@gpop63
Copy link
Contributor Author

gpop63 commented Aug 29, 2023

Currently, both app_state and app_insights data streams use flattened type for azure.dimensions.

From my understanding there are 2 approaches since flattened type can't be a dimension at the moment:

  • Keep it flattened, add an ingest pipeline to extract fields and mark them as dimensions
  • Convert azure.dimensions to group which would provide more flexibility (breaking change?)

I tested upgrading the old package version 1.0.6 to the new one I'm working on 1.1.0 (which changed azure.dimensions to a group) and I did not see any conflicts in the mapping.

@agithomas
Copy link
Contributor

since flattened type can't be a dimension at the moment:

Have you tested this : elastic/elasticsearch#94113 (comment)?

Copy link
Contributor

@kaiyan-sheng kaiyan-sheng left a 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

Copy link
Contributor

@agithomas agithomas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@agithomas
Copy link
Contributor

@tetianakravchenko , can you please re-check and validate if it is fine?

- name: users_authenticated.unique
type: float
metric_type: counter
Copy link
Contributor

@tetianakravchenko tetianakravchenko Sep 11, 2023

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:
Screenshot 2023-09-11 at 09 44 51
can you please double-check it?

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@tetianakravchenko tetianakravchenko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@agithomas
Copy link
Contributor

@gpop63 , are you good to merge this change? Looks like #7259 is waiting on this change.

@gpop63 gpop63 merged commit 39eea2a into elastic:main Oct 17, 2023
@elasticmachine
Copy link

Package azure_application_insights - 1.2.1 containing this change is available at https://epr.elastic.co/search?package=azure_application_insights

@andrewkroh andrewkroh added the Integration:azure_application_insights Azure Application Insights Metrics Overview label Jul 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Integration:azure_application_insights Azure Application Insights Metrics Overview

8 participants