SQL 和事件警示

它是如何運作的

從訊號到決策的可審查工作流程

與所有者一起選擇訊號

只有當有人理解它的含義並能夠採取行動時，閾值才有用。從使用者、收入或可靠性結果開始。

設定音量和時間保障

避免小分母的比率，允許正常的排程抖動，並在適當的情況下忽略不完整的時間段。

測試回應路徑

使用合成資料觸發條件，確認交付，幷包含足夠的上下文供收件人開啟正確的查詢或儀表板。

邊界

這不能取代什麼

閾值警示不是異常檢測，應使用經過審查的基線、足夠的數量和完整的時間段。
電子郵件傳送不能替代完整的事件管理和升級流程。
Telemetry 無法推斷訊號是否可操作；每個警示仍然需要一個所有者和一個記錄在案的回應。

可檢查的證明路徑

從事件契約到可見的答案

此範例使用宣告的架構、只讀 SQL 和確定性合成結果。它示範了工作流程，但沒有提供範例資料作為客戶基準。

1. 活動合約

一排進入 service_heartbeats，並明確查詢所使用的型別。

timestamp_utc: Timestamp
service_name: Utf8
environment: Utf8
status: Utf8

瀏覽活動合約

2.只讀SQL

哪些預期遙測源已停止傳送心跳？

SELECT
  service_name,
  environment,
  MAX(timestamp_utc) AS last_seen_at,
  COUNT(*) AS heartbeats_in_window
FROM service_heartbeats
WHERE timestamp_utc >= now() - INTERVAL '24 hours'
  AND environment = 'production'
GROUP BY service_name, environment
HAVING MAX(timestamp_utc) < now() - INTERVAL '10 minutes'
ORDER BY last_seen_at ASC;