Telemetry 如何评估 SQL 告警
有用的告警不仅仅是图表上附加的阈值。评估者必须决定查询何时到期、运行哪个 SQL、计算哪些行、如何将这些行减少到一个值、状态是否更改以及何时通知。
本指南记录了 Telemetry 实施的评估路径。它是可检查的行为描述，而不是正常运行时间、延迟或交付保证。
告警输入模型：一个时间序列信号
Telemetry 的告警创建工作流程有意从一行开始：一个有序的时间轴、一个数值轴，并且没有分组或分割维度。探索需要没有分割的折线图。 SQL 结果需要折线图，其中具有明确的时间 x 轴、数字 y 轴，并且 分组依据设置为无。
此约束使评估者的输入易于理解。每个结果行都是一个时间点，所选指标具有一种含义和单位，配置的阈值会产生一种告警状态。多系列结果将需要额外的策略：是否任何或所有系列控制状态，每个系列是否拥有独立的历史记录，通知如何分组，以及丢失或新出现的系列意味着什么。 Telemetry 避免隐式发明这些语义。
计算信号的SQL仍然可以很复杂。它可以连接表、过滤特定服务或路线、计算比率或强制执行最小样本量。暴露给告警的最终结果应该很简单：一个时间段和每行一个数字信号。在仪表板上保留分组比较，或者在每个组都有自己的阈值、所有者和响应时创建单独的告警。
评估顺序
评估器使用链式一分钟调度循环。每个通道都会加载已启用的告警，与隔离的故障处理同时评估它们，记录通道结果，并在当前通道完成后安排下一个通道。一分钟循环是轮询节奏；每个告警仍然有其自己配置的间隔。
对于每个启用的告警：
- 检查告警是否是从其上次评估时间和配置的时间间隔开始的。
- 使用当前版本声明告警，以便其他评估者无法同时声明相同版本。
- 解析查询：使用精确保存的 SQL 来获取支持查询的告警，或从存储的探索配置重新生成 SQL。
- 拒绝包含写入语句的支持查询的 SQL。
- 执行查询并检查结果列和行。
- 当最新行代表不完整的时间段时，可以选择删除它。
- 获取配置的最近点数量并将它们聚合为一个观察值。
- 将该值与阈值和运算符进行比较。
- 存储新状态、观测值、评估时间和任何受控误差。
- 仅在状态转换时添加历史记录并尝试发送电子邮件。
排除故障时此顺序很重要。有效的查询仍然不会产生可用值，可用值可以保持在阈值以下，并且当告警已经触发时，违反阈值可以保持沉默。
保存的查询和探索源
支持查询的告警运行与告警一起保存的 SQL。评估器不会默默地将其替换为更新的查询修订版。当仪表板和告警出现不一致时，请查看附加到告警的 SQL。
Explore 支持的告警存储 Explore 配置并通过 Explore 使用的相同查询构建边界重新生成 SQL。因此，对架构、过滤器、分组或聚合的更改可能会影响存储的配置是否仍然可以解析。
对于支持查询的告警，拒绝面向写入的语句。告警旨在观察结果，而不是改变表或管理状态。即使 SQL 是只读的，也要保持警惕，SQL 受时间和结果大小的限制。
最新点排除
时间桶查询通常首先返回当前的、不完整的桶。将部分分钟或小时与完整历史存储桶进行比较可能会产生错误的恢复或错误的违规信号。
当 exclude latest incomplete point 启用时，评估器首先对最新的行进行排序，并在选择配置的点数之前删除最新的结果行。仅当每行真正代表一个时间段并且最新行不完整时，该设置才是正确的。
不要为单行聚合启用它，例如：
SELECT
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '15 minutes';
删除唯一的行不会留下任何可评估的值。对于时间序列，返回一个显式存储桶列和一个数值列：
SELECT
date_bin(INTERVAL '5 minutes', completed_at, TIMESTAMP '1970-01-01') AS bucket,
100.0 * SUM(CASE WHEN status = 'failed' THEN 1 ELSE 0 END) / COUNT(*) AS failure_rate
FROM background_job_completed
WHERE completed_at >= now() - INTERVAL '35 minutes'
GROUP BY bucket
ORDER BY bucket DESC;
点选择和聚合
最新点处理后，评估器将获取配置的最近行数。它提取选定的数值并使用告警聚合设置减少这些点。
当 SQL 已经计算出完整的决策窗口时，使用单点。当告警有意需要跨多个存储桶进行持久化时，请使用多个点。聚合应与操作问题相匹配：
maximum询问是否有任何选定点被破坏。minimum询问每个选定点是否位于楼层之上。average平滑了短暂的变化，但可以隐藏一个严重的点。sum适合非重叠桶中累积的计数。latest使用最新的剩余完整点。
在响应过程中记录此选择。 “失败率高于 5”是不明确的，除非团队知道这是否意味着最近五分钟的时间段、三个时间段的平均值或这些时间段的最大值。
状态转换和通知
Telemetry 将告警状态与单个评估分开存储。成功评估可产生ok或firing；执行、提取或配置问题会产生错误结果。
历史记录和通知是面向过渡的。从 ok 到 firing 的移动会创建触发转换。从 firing 到 ok 的移动会创建分辨率转换。同一状态下的重复评估会更新评估记录，而无需在每次轮询时发送相同的转换电子邮件。
该评估员当前的通知发送方式是电子邮件。存储状态转换后尝试传送。传送失败不能消除告警已转换的事实，这就是为什么应单独调查告警历史记录和电子邮件传送的原因。
并发和声明行为
每个告警均使用其当前版本以乐观并发方式声明。如果版本已更改或其他评估者已声明该版本，则声明不会成功。这可以防止两个评估者故意同时处理相同的告警版本。
调度程序使用已确定的承诺来评估已启用的告警集，因此一个被拒绝的告警不会阻止该通道中其余告警的完成。该循环仅在当前传递完成后才安排下一个传递，从而避免一个进程内的重叠传递。
这些控制解释了评估者的行为；它们不是分布式服务可用性声明。部署拓扑、流程重新启动、电子邮件提供商行为和未来的实施更改仍然属于操作审查。
故障排除清单
当告警未按预期运行时：
- 运行附加的 SQL 并确认它是只读的。
- 检查所选值列是否为数字并且存在于每个相关行中。
- 检查结果排序；最新点逻辑取决于知道哪一行是最新的。
- 确认查询返回的是一行聚合还是多个时间段。
- 一起回顾
exclude latest incomplete point、点数和聚合。 - 验证运算符和阈值使用与所选值相同的单位。
- 检查告警历史记录以了解最近的状态转换和受控错误。
- 将查询/评估失败与电子邮件传送失败分开。
- 确认告警已启用，并且其配置的时间间隔已经过去了足够的时间。
- 在阈值两侧使用合成事件固定装置进行测试。
对于特定于交付的调查，请继续 告警传送故障排除。对于事件和查询设计，请使用 告警 和 创建您的第一个仪表板和告警。
解释边界
评估者可以一致地执行配置的决策，但无法决定业务定义是否正确。事件粒度、分母、时间窗口、阈值、缺失数据策略和响应所有者仍然是告警合约的一部分。
在架构更改、查询编辑、版本更改、流量变化和事件回顾后重新审查告警。具有过时阈值或分母的技术上有效的告警仍然是不可靠的告警。