活动合约
查询期望的字段
| 字段 | 类型 | 为什么存在 |
|---|---|---|
| timestamp_utc | Timestamp | 运行完成时间。 |
| job_name | Utf8 | 稳定的逻辑作业名称。 |
| queue_wait_ms | Float64 | 从计划到开始的毫秒数。 |
| duration_ms | Float64 | 启动后的执行持续时间。 |
DataFusion SQL
复制查询
sql
SELECT
job_name,
COUNT(*) AS runs,
approx_percentile_cont(queue_wait_ms, 0.50) AS p50_wait_ms,
approx_percentile_cont(queue_wait_ms, 0.95) AS p95_wait_ms,
approx_percentile_cont(duration_ms, 0.95) AS p95_run_ms
FROM job_runs
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY job_name
HAVING COUNT(*) >= 20
ORDER BY p95_wait_ms DESC;此只读查询是针对空类型表计划和执行的 阿帕奇 DataFusion 45.2.0。确定性样本输出是综合的并单独审查；根据您自己的数据验证字段类型、阈值和业务定义。 阅读测试方法。
查询结果
p95 按作业排队等待
报告生成的等待时间大约是 p95 运行时间的两倍。
generate_report
44,200 ms
comparison 21,800 ms
sync_subscription
7,200 ms
comparison 8,400 ms
send_email
460 ms
comparison 930 ms
| job_name | runs | p50_wait_ms | p95_wait_ms | p95_run_ms |
|---|---|---|---|---|
| generate_report | 340 | 1,800 | 44,200 | 21,800 |
| sync_subscription | 980 | 420 | 7,200 | 8,400 |
| send_email | 12,400 | 80 | 460 | 930 |
综合示例输出。在将其用于操作决策之前，针对您自己的事件架构和阈值运行查询。
SQL 是如何工作的
- 1队列等待在工作安排时开始，在执行开始时结束。
- 2p50 到 p95 的差距将持续缓慢的队列与间歇性的积压区分开来。
- 3将 p95 等待时间与 p95 运行时间进行比较可以看出容量或作业代码是否是更大的贡献者。
需要决定的边缘情况
- 使用一个时钟或 UTC 时间戳作为计划时间和开始时间。
- 计划的 cron 延迟和队列延迟可能需要单独的字段。
- 重试应保留尝试次数，以便可以隔离重复的工作。
推荐仪表板
- 酒吧：p50和p95按工作等待
- 趋势：p95 排队等候
- 表：当前排队的最旧项目
让查询示例发挥作用
相关埋点和指南
定义源数据
此分析的事件模式
继续分析
在真实事件中运行它
创建表，调整字段并保存结果
免费开始，发送结构化事件，并将查询结果用作图表、共享仪表板小部件或警报输入。