Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
# 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>
- Loading branch information