结构化事件的 SQL 仪表板

它是如何运作的

从信号到决策的可审查工作流程

以决定为主导

仪表板应该回答一小组相关问题。从主要健康或结果指标开始，而不是从每个可用的图表开始。

检测后进行诊断

首先放置趋势和阈值视图，然后添加解释变化的细分和最近事件表。

文件所有权和响应

使用标题和注释来定义指标、预期范围、所有者和下一步。上下文使仪表板在事件期间可用。

构建共享 Telemetry 仪表板

显示图表排列和协作仪表板编辑的真实产品捕获。

边界

这不能取代什么

仪表板总结了已审核的查询；它们不会使不稳定的度量定义变得值得信赖。
共享董事会应该专注于一个小的决策集，而不是成为每个可用图表的清单。
Telemetry 仪表板不会取代事件操作手册、所有权模型或财务报告的持久真相来源系统。

可检查的证明路径

从事件契约到可见的答案

此示例使用声明的架构、只读 SQL 和确定性合成结果。它演示了工作流程，但没有提供示例数据作为客户基准。

1. 活动合约

一排进入 api_requests，并明确查询所使用的类型。

timestamp_utc: Timestamp
route_template: Utf8
status_code: Int64
latency_ms: Float64

浏览活动合同

2.只读SQL

哪些 API 路由具有最高的有意义 5xx 错误率？

SELECT
  route_template,
  COUNT(*) AS requests,
  SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) AS errors,
  100.0 * SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END)
    / NULLIF(COUNT(*), 0) AS error_rate_pct
FROM api_requests
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
GROUP BY route_template
HAVING COUNT(*) >= 20
ORDER BY error_rate_pct DESC
LIMIT 10;