-
Notifications
You must be signed in to change notification settings - Fork 460
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
[Azure][Storage_account] Add dimension to the storage account datastream #7356
[Azure][Storage_account] Add dimension to the storage account datastream #7356
Conversation
🌐 Coverage report
|
Azure has additional dimensions for storage accounts, such as GeoType, Authentication, FileShare, BlobType , and tier. However, these dimensions are not currently included in this PR. As in the current Beats implementation, only two dimensions, namely ResponseType and ApiName, are allowed. I've used these two dimensions for enabling TSDB for now. Although the current set of dimensions doesn't discard any documents, I'm in the process of using Azure Rest APIs to explore the values for the other dimensions defined by Azure. |
…integrations into azure_tsdb_storageaccount_7215
Oh, I see the dimensions list is pretty limited here. Expanding the list is not in the scope of this PR, so we should not block this PR. We should open an issue to plan this activity. We should also drop the |
I merged this PR with the remaining dimensions included. However, I've come to realize that the TransactionType dimension is still pending and may require a separate PR to incorporate it.
@zmoog However, if this is under consideration, should we wait before migrating this datastream to the TSDB? |
Oh, I missed this one! Thank you for pointing it out.
No, switching from the
We can tackle the switch storage > monitor after completing all the in-flight activities. @kaiyan-sheng, please chime in with your perspective 🙇 |
packages/azure_metrics/changelog.yml
Outdated
@@ -1,3 +1,8 @@ | |||
- version: "1.0.24" |
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.
I think we can bump this one to 1.1.0 since this is an enhancement not a bug fix.
I agree with @zmoog, we are not in a hurry to change storage to use the generic Let's make sure we are not collecting extra data in |
Hi! We just realized that we haven't looked into this PR in a while. We're sorry! We're labeling this issue as |
@ritalwar I was checking the pending issues/PRs, and I want to recap this one to double-check I'm not overlooking something:
|
Yes, now that this is available in release, I've been testing it and now waiting for the TSDB team to provide their feedback.
I've observed that for all other similar changes, such as those related to dimensions and metric_type PRs, the version update was done at the patch level rather than the minor version. Should I follow the same approach and update the patch version for consistency? Edit: My apologies! I overlooked the Kibana version and was referring to the package version instead.
I checked if this datastream is affected by the grouping issue seen in other Azure and GCP datastreams. However, it seems unaffected because the implementation for this datastream is separate in the Beats module, and it already groups data based on allowed dimensions. If you think there's anything I missed, please let me know, and I'll test further. |
packages/azure_metrics/data_stream/storage_account/fields/agent.yml
Outdated
Show resolved
Hide resolved
packages/azure_metrics/data_stream/storage_account/elasticsearch/ingest_pipeline/default.yml
Outdated
Show resolved
Hide resolved
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.
kibana version should be changed to 8.10 I think, since this change is relying on the 8.10 beats release
kibana.version: "^8.9.0"
I also agree that the package version should be changed to 1.1.0
when the new kibana version restriction will be added.
Should we consider updating the Kibana version in the TSDB enablement PR, as we've done for some other packages?
I'll follow this in the PR where I update the Kibana version, and we can decide whether it's in this one or the enablement PR. |
adding additional fields is not related to the tsdb enablement. Here I've seen similar discussion regarding the handling of kibana constrains - #6821 (comment) (this is a conclusion, but see the whole discussion) for adding new fields, based on that my understanding was that it is a proper way of handling it.
@zmoog I've seen your comment regarding the kibana version #7356 (comment). Is your understanding the same as in discussion linked above? |
for other packages usually we were introducing the Kibana version constrain together with tsdb enablement, because tsdb is supported starting from ^8.8.0 in this case if TSDB enablement PR would include kibana constrain ^8.10.0, it will not be correct since TSDB enablement itself does not require bumping kibana version to 8.10 |
That makes sense. I've made the update and updated both Kibana and package version. |
Package azure_metrics - 1.1.0 containing this change is available at https://epr.elastic.co/search?package=azure_metrics |
What does this PR do?
This PR add dimension for azure storage_account datastream.
Specified dimension fields are as follows:
- agent.id
- azure.dimensions.api_name
- azure.dimensions.response_type
- azure.namespace
- azure.resource.id
- azure.timegrain
- cloud.region
Link for azure defined dimensions: https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/microsoft-classicstorage-storageaccounts-metrics
Checklist
changelog.yml
file.How to test this PR locally
Related issues
Screenshots