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;