結構化事件的 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;