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
[SLOS] fix APM group by cardinality count #183171
[SLOS] fix APM group by cardinality count #183171
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
/ci |
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
💛 Build succeeded, but was flaky
Failed CI StepsTest FailuresMetrics [docs]Module Count
Public APIs missing comments
Async chunks
Page load bundle
History
To update your PR or re-run it, just comment with: |
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.
🚢 it
## Summary Resolves elastic#179046 Summarize your PR. If it involves visual changes include a screenshot or gif. Applies filters based on the selected APM indicator params to the cardinality count query. <img width="845" alt="Screenshot 2024-05-10 at 1 07 27 PM" src="https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec"> ### Testing. 1. Create mock api data via `node scripts/synthtrace continuous_rollups --live` 2. Navigate to create SLI and choose APM latency 3. Select a service 4. Select group by as `service.name`. Cardinality count should be 1 5. Select environment all and change the group by to `service.environment`. Cardinality count should be 2. 6. Now select a specific environment. Notice cardinality count changes to 1. 7. Repeat this testing strategy with transaction name and transaction type, changing the group by field to `transaction.name` or `transaction.type`, respectively and playing around with the ALL_VALUE versus a specific value. 8. Also make sure to test the global filter for regressions ### Release note The cardinality count for SLOs generated from a single SLI definition was previously incorrect for APM latency and APM availability SLIs. The cardinality count is now accurate. (cherry picked from commit d3945a3)
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
# Backport This will backport the following commits from `main` to `8.14`: - [[SLOS] fix APM group by cardinality count (#183171)](#183171) <!--- Backport version: 9.4.3 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Dominique Clarke","email":"dominique.clarke@elastic.co"},"sourceCommit":{"committedDate":"2024-05-14T18:45:38Z","message":"[SLOS] fix APM group by cardinality count (#183171)\n\n## Summary\r\nResolves #179046 your PR. If it involves visual changes include a screenshot or\r\ngif.\r\n\r\nApplies filters based on the selected APM indicator params to the\r\ncardinality count query.\r\n\r\n<img width=\"845\" alt=\"Screenshot 2024-05-10 at 1 07 27 PM\"\r\nsrc=\"https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec\">\r\n\r\n### Testing.\r\n1. Create mock api data via `node scripts/synthtrace continuous_rollups\r\n--live`\r\n2. Navigate to create SLI and choose APM latency\r\n3. Select a service\r\n4. Select group by as `service.name`. Cardinality count should be 1\r\n5. Select environment all and change the group by to\r\n`service.environment`. Cardinality count should be 2.\r\n6. Now select a specific environment. Notice cardinality count changes\r\nto 1.\r\n7. Repeat this testing strategy with transaction name and transaction\r\ntype, changing the group by field to `transaction.name` or\r\n`transaction.type`, respectively and playing around with the ALL_VALUE\r\nversus a specific value.\r\n8. Also make sure to test the global filter for regressions\r\n\r\n### Release note\r\nThe cardinality count for SLOs generated from a single SLI definition\r\nwas previously incorrect for APM latency and APM availability SLIs. The\r\ncardinality count is now accurate.","sha":"d3945a3e50eaad9f850bb4d88863e6a91026acbc","branchLabelMapping":{"^v8.15.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Feature:SLO","ci:project-deploy-observability","Team:obs-ux-management","v8.14.0","v8.15.0"],"title":"[SLOS] fix APM group by cardinality count","number":183171,"url":"#183171 fix APM group by cardinality count (#183171)\n\n## Summary\r\nResolves #179046 your PR. If it involves visual changes include a screenshot or\r\ngif.\r\n\r\nApplies filters based on the selected APM indicator params to the\r\ncardinality count query.\r\n\r\n<img width=\"845\" alt=\"Screenshot 2024-05-10 at 1 07 27 PM\"\r\nsrc=\"https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec\">\r\n\r\n### Testing.\r\n1. Create mock api data via `node scripts/synthtrace continuous_rollups\r\n--live`\r\n2. Navigate to create SLI and choose APM latency\r\n3. Select a service\r\n4. Select group by as `service.name`. Cardinality count should be 1\r\n5. Select environment all and change the group by to\r\n`service.environment`. Cardinality count should be 2.\r\n6. Now select a specific environment. Notice cardinality count changes\r\nto 1.\r\n7. Repeat this testing strategy with transaction name and transaction\r\ntype, changing the group by field to `transaction.name` or\r\n`transaction.type`, respectively and playing around with the ALL_VALUE\r\nversus a specific value.\r\n8. Also make sure to test the global filter for regressions\r\n\r\n### Release note\r\nThe cardinality count for SLOs generated from a single SLI definition\r\nwas previously incorrect for APM latency and APM availability SLIs. The\r\ncardinality count is now accurate.","sha":"d3945a3e50eaad9f850bb4d88863e6a91026acbc"}},"sourceBranch":"main","suggestedTargetBranches":["8.14"],"targetPullRequestStates":[{"branch":"8.14","label":"v8.14.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.15.0","branchLabelMappingKey":"^v8.15.0$","isSourceBranch":true,"state":"MERGED","url":"#183171 fix APM group by cardinality count (#183171)\n\n## Summary\r\nResolves #179046 your PR. If it involves visual changes include a screenshot or\r\ngif.\r\n\r\nApplies filters based on the selected APM indicator params to the\r\ncardinality count query.\r\n\r\n<img width=\"845\" alt=\"Screenshot 2024-05-10 at 1 07 27 PM\"\r\nsrc=\"https://github.com/elastic/kibana/assets/11356435/7283f7cc-b141-47e2-883e-e463556e4aec\">\r\n\r\n### Testing.\r\n1. Create mock api data via `node scripts/synthtrace continuous_rollups\r\n--live`\r\n2. Navigate to create SLI and choose APM latency\r\n3. Select a service\r\n4. Select group by as `service.name`. Cardinality count should be 1\r\n5. Select environment all and change the group by to\r\n`service.environment`. Cardinality count should be 2.\r\n6. Now select a specific environment. Notice cardinality count changes\r\nto 1.\r\n7. Repeat this testing strategy with transaction name and transaction\r\ntype, changing the group by field to `transaction.name` or\r\n`transaction.type`, respectively and playing around with the ALL_VALUE\r\nversus a specific value.\r\n8. Also make sure to test the global filter for regressions\r\n\r\n### Release note\r\nThe cardinality count for SLOs generated from a single SLI definition\r\nwas previously incorrect for APM latency and APM availability SLIs. The\r\ncardinality count is now accurate.","sha":"d3945a3e50eaad9f850bb4d88863e6a91026acbc"}}]}] BACKPORT--> Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
Summary
Resolves #179046
Summarize your PR. If it involves visual changes include a screenshot or gif.
Applies filters based on the selected APM indicator params to the cardinality count query.
Testing.
node scripts/synthtrace continuous_rollups --live
service.name
. Cardinality count should be 1service.environment
. Cardinality count should be 2.transaction.name
ortransaction.type
, respectively and playing around with the ALL_VALUE versus a specific value.Release note
The cardinality count for SLOs generated from a single SLI definition was previously incorrect for APM latency and APM availability SLIs. The cardinality count is now accurate.