Repository navigation
feat(slos): SLI, error budget and burn rates - #2295
Conversation
sloTotalsQuery reads the SLO window from raw partial minutes, the minutely rollup's partial hours and the hourly interior; sloBucketsQuery buckets by hour (budget chart) or minute (burn windows). SlosService.status returns the SLI, the budget left and the 5m/30m/1h/6h burn rates; history returns hourly budget points over the window. GET /v2/slos/:id/status and /history.
A latency SLI's rollup total is EstimatedLadderSpanCount, so buckets written before migration 0058 drop out instead of reading as all slow.
…O reads The parity test seeds spans on every splice seam of six windows (aligned and not, plus a sub-hour one) and compares sloTotalsQuery and sloBucketsQuery against flat scans of service_overview_spans for availability and latency SLIs, with and without environment filters. A pre-ladder case shows legacy rollup rows drop out of a latency total and still count for availability. Runs in the CI rollup step. bench-suites/slos.ts covers 30-day totals, the 6h minute burn read, the 60-day hourly history and a flat 30-day scan as the baseline the splice replaces.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 15 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
This comment has been minimized.
This comment has been minimized.
|
F1 fixed: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
GET /v2/slos/statuses groups SLOs by SLI and window: one totals read per (SLI, window) and one burn read per SLI, each broken down by service and environment and summed per SLO. The SLOs list no longer costs two warehouse reads per SLO. The parity e2e pins the grouped reads against flat scans.
This comment has been minimized.
This comment has been minimized.
Maple review🟢 Confidence 10/10 · safe to merge. This pass read only the parity e2e change; its ground truth matches the query semantics and the earlier Adds the spliced SLO reads (window totals, hour/minute buckets, burn windows, budget history), the status/history service paths and endpoints, and a raw-vs-rollup parity e2e plus benchmark suite. The CodeQL escaping fix in the parity test is correct; nothing new blocks merge.
Still open from earlier reviews
|
Stack: #2293 model, #2294 latency ladder, #2295 compute, #2296 burn alerts, #2297 MCP, #2298 UI
Part 3 of 6: computing the SLI, the error budget left and the burn rates.
Queries
sloTotalsQueryreads one SLO window from three tiers: raw spans for the partial minutes at each end, the minutely rollup for the partial hours, and the hourly rollup for everything in between. The boundaries come fromrollup-splice.sloBucketsQuerybuckets the same reads by hour (for the budget chart) or by minute (for the burn windows).Service and API
SlosService.statusreturns the SLI and budget left over the window, plus the burn rate of the 5m, 30m, 1h and 6h windows. All four come from one 6-hour minute-grain read.historyreturns hourly budget points over the window.GET /v2/slos/:id/statusandGET /v2/slos/:id/history.Verification
statusandhistory.Benchmark. Run with
bun run bench:queries, suiteapps/api/scripts/bench-suites/slos.ts, on ClickHouse 26.2 with 10 runs and 2 threads. The seed was one service at about 1000 spans/min plus 20 others: 30 days of minutely rows, 60 days of hourly rows, and 2 days of raw spans.The baseline row only scans the 2 days of raw spans that were seeded. At the real 30-day raw retention it would read about 43M rows, roughly 2,200 times what the spliced read touches.
🤖 Generated with Claude Code