-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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] [Metrics] Update group by dimensions logic #36491
[Azure] [Metrics] Update group by dimensions logic #36491
Conversation
When users define dimensions in the config, the current implementation groups metrics by timestamp and single dimension. Grouping by ts + single dimension can sometimes lead to multiple documents with the same dimension values. This does not play well with TSDB, because it expects all documents with the same timestamp to have a unique combination of dimensions value. I am updating the group by dimensions logic to use all dimensions for grouping instead of just one. It is working fine with the test cases I am using, but this needs more testing and understanding. Refs: elastic/integrations#7160
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
This pull request is now in conflicts. Could you fix it? 🙏
|
1 similar comment
This pull request is now in conflicts. Could you fix it? 🙏
|
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
Superseded by #36823 |
Proposed commit message
When users define dimensions in the config, the current implementation groups metrics by timestamp and single dimension.
Grouping by ts + single dimension can sometimes lead to multiple documents with the same dimension values. This does not play well with TSDB, because it expects all documents with the same timestamp to have a unique combination of dimensions value.
I am updating the group by dimensions logic to use all dimensions for grouping instead of just one.
It is working fine with the test cases I am using, but this needs more testing and understanding.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
Related issues
kube_node_status_condition
metric integrations#7160Use cases
Screenshots
Logs