从遥测语义到可操作告警：无样本不等于零错误
采集断流时查询返回空——把空当 0 错误，仪表盘在故障最严重时显示"一切正常"。本页定义指标语义契约、燃烧率告警、诊断的因果纪律，以及"恢复"的四种完成状态。分位口径见分位、延迟和正确的聚合；燃烧率的预算背景见SLI、SLO 与预算。
遥测语义契约
指标名称、单位、聚合方式和标签含义组成契约。请求持续时间应以秒或毫秒明确表示；计数器只能单调递增并由查询计算速率；Gauge 表示某一时刻状态。服务端、客户端和用户侧测得的延迟边界不同，不能混为同一 SLI。指标缺失也要定义语义：可能代表零流量、采集失败或服务不可达。
直方图需在观测端选择桶边界；桶太宽会掩盖 SLO 边缘的变化，桶太多会增加时间序列成本。多个实例的桶计数可按相同边界聚合后估算整体分位；本地 summary 分位通常无法通过对分位数求平均得到全局分位。采样分位只对被保留样本成立，排除超时和取消请求会系统性偏低。
燃烧率告警与用户影响
对基于错误预算的告警，可用短窗口和较长窗口共同识别快速燃烧与持续消耗。燃烧率表示当前失败速度相对 SLO 允许速度的倍数；它适合决定响应优先级，不解释故障根因。必须同时观察用户影响和事件分母，低流量时少量失败可能造成比例抖动，关键业务也可能需要独立告警。30天1000万任务、按时成功99.9%，预算1万失败。最近10分钟1万任务有200失败，错误率2%，燃烧率20；在该窗口与流量保持假设下应尽快止损。低流量一个失败的百分比很高，应补最小事件数、业务影响与更长窗口，不能静态百分比寻呼所有服务。SLO告警讨论多窗口燃烧率，这里按教学任务定义阈值而非照抄倍数。
告警的对象是损失与动作：CPU80%可能只是正常利用率，业务队列不动却CPU20%可能已严重失败。告警需绑定用户影响、责任人和可执行动作；诊断指标帮助定位，不应都变成寻呼。告警载荷写服务/用户旅程、窗口、分子分母、受影响范围、相关变更和runbook入口。一个下游失败引发20个上游告警时做依赖聚合，保留独立正确性异常，不能把所有异常都静默。
诊断是带不确定性的因果推断
一条 trace 展示传播上下文中的父子关系，不等于完整因果证明。异步消息、批处理、重试和采样会形成断开的 trace；可用链接、业务 ID、消息 ID 和位点补充关联。时钟偏差会让跨主机时间排序失真，优先利用同机单调时钟、父子关系和明确的请求阶段事件。
诊断应同时记录观察、假设和干预。某项指标在发布后上升只说明时间相关；若回滚、流量变化或依赖故障同时发生，就还需比较分组、控制变量或重放。对每个假设列出能证伪它的观测，避免只收集支持首个猜测的日志。
无数据与恢复不是正常值
采集断流、计数器重启、标签更名和任务没有到达都会改变查询。zero与absent分别表示0和缺样本，不应统一填0。恢复条件需持续窗口与滞回，防止瞬时回落就自动结案；积压清完前HTTP成功率可能已经恢复。
事故恢复有"止损、服务恢复、数据恢复、风险关闭"不同完成状态。进程健康和错误率下降不能证明积压、重复副作用或迟到数据已处理；还需验证业务不变量、差异队列、重放进度和客户影响。事故负责人应逐项宣布状态和遗留风险。
验证规则的三种输入
重放历史事故检验发现延迟与漏报，用正常波动检验误报，用采集断流检验无数据行为。再让负载骤降，确保窗口与分母规则未把少数关键失败吞掉。产物是输入序列、规则输出、应执行动作与恢复门槛，不是截图。这些重放可在隔离监控实例执行，本轮未运行。
比较固定资源阈值与用户SLO规则：前者易部署且可提前发现容量边缘，后者更接近实际损失，但需要可靠业务计数。两者可分层使用，不能只选一种就覆盖全部场景。
告警规则的可执行验证：三输入重放与动作映射
本页前面讲了无数据不等于零错误、燃烧率 20 要先止损，但没有回答"怎么证明一条告警规则能用"。验证方法是三输入重放：一次真实事故回放（测发现速度）、一段正常波动（测误报）、一段遥测断流（测无数据行为）；每条规则都要在这三种输入下给出明确输出与动作。
用本页算例重放。事故输入：5 分钟内 50,000 个事件、600 个坏事件，错误率 1.2%、燃烧率 12，规则应 PAGE。正常波动：60 秒内 200 个事件、1 个坏事件，比例 0.5%、燃烧率 5，看着超标但样本低于最小事件数 1,000，规则应输出 INSUFFICIENT_EVIDENCE 而不是分页——这正是低流量误报的防线。断流输入：5 分钟内 0 个事件，比例无定义，规则不能填 0 错误，必须由独立的"无数据"规则捕获（见本页开头"无样本不等于零错误"）。
三个输出要绑定动作：PAGE 对应"谁在多久内做什么"（如值班 5 分钟内确认并执行 Runbook 第一段）；NO_PAGE 对应记录与趋势观察；INSUFFICIENT_EVIDENCE 对应"补充替代证据或延长窗口"，且必须有人负责收尾——否则证据不足会变成无人处理的灰区。静默与抑制要有边界：维护窗口静默必须写明结束时间与恢复后的补偿检查，抑制规则不能把关键租户一并抑制。
执行 python3 labs/observability_models.py alert_replay：预期事故输入 decision=PAGE（燃烧率 12）、正常波动 INSUFFICIENT_EVIDENCE（燃烧率 5 但样本 200）、断流 INSUFFICIENT_EVIDENCE（burn 为 null）。脚本只做分类，不接真实告警通道；规则部署与 Collector 实跑见 U64。
两个合理选择：A 只有一条静态阈值规则，简单但低流量误报、断流静默；B 多窗口燃烧率 + 最小事件数 + 独立无数据规则，复杂但三类输入都能正确分类。本例选 B，并把三输入重放结果作为规则上线的必备证据——没有重放记录的规则不允许直接进值班。
架构师变化条件
把告警从静态百分比改为多窗口燃烧率加最小事件数：低流量服务不再被单次失败寻呼，但要为每条规则准备历史重放证据。若采集链路本身有单点（单 exporter），无数据告警必须覆盖它并演练。多租户场景下全局燃烧率达标而关键租户超支时，需分层告警与租户级预算（见高基数、采样与遥测成本的分层讨论）。每次变化重放三种输入序列并记录发现/误报率。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。