活动合约
查询期望的字段
| 字段 | 类型 | 为什么存在 |
|---|---|---|
| timestamp_utc | Timestamp | 请求完成时间(UTC)。 |
| status_code | Int64 | HTTP 响应状态代码。 |
| environment | Utf8 | 部署环境。 |
DataFusion SQL
复制查询
sql
WITH hourly AS (
SELECT
date_trunc('hour', timestamp_utc) AS hour,
COUNT(*) AS requests,
SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS bad_requests
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
AND environment = 'production'
GROUP BY date_trunc('hour', timestamp_utc)
)
SELECT
hour,
requests,
bad_requests,
100.0 * bad_requests / NULLIF(requests, 0) AS error_rate_pct,
(1.0 * bad_requests / NULLIF(requests, 0)) / 0.001 AS burn_rate
FROM hourly
ORDER BY hour;此只读查询是针对空类型表计划和执行的 阿帕奇 DataFusion 45.2.0。确定性样本输出是综合的并单独审查;根据您自己的数据验证字段类型、阈值和业务定义。 阅读测试方法。
查询结果
每小时误差-预算消耗率
13:00 时段消耗的预算是可持续比率的 3.72 倍。
12:00
0.49×
13:00
3.72×
14:00
1.28×
| hour | requests | bad_requests | error_rate_pct | burn_rate |
|---|---|---|---|---|
| 12:00 | 18,420 | 9 | 0.05 | 0.49 |
| 13:00 | 19,110 | 71 | 0.37 | 3.72 |
| 14:00 | 18,780 | 24 | 0.13 | 1.28 |
综合示例输出。在将其用于操作决策之前,针对您自己的事件架构和阈值运行查询。
SQL 是如何工作的
- 199.9% 的成功目标允许 0.1% 或 0.001 的不良请求率。
- 2将观察到的比率除以 0.001 得出燃烧率:1× 完全是可持续的,而 3× 则消耗预算的速度太快了三倍。
- 3CTE 使请求分母保持可见,因此可以单独处理小桶。
需要决定的边缘情况
- 定义哪些状态代码对于面向用户的 SLI 来说是错误的;并非每个 5xx 都有相同的影响。
- 使用多窗口警报进行生产寻呼,而不是一个嘈杂的每小时阈值。
- 仅当 SLO 定义明确排除综合检查或内部流量时,才排除它们。
推荐仪表板
- 趋势:burn_rate(按小时)
- 统计:每月剩余错误预算
- 表:造成最坏请求的路由
让查询示例发挥作用
相关埋点和指南
继续分析
在真实事件中运行它
创建表,调整字段并保存结果
免费开始,发送结构化事件,并将查询结果用作图表、共享仪表板小部件或警报输入。