告警：基础对象与机制
告警条件、责任人与响应入口
告警的目标是让负责人采取行动。先定义业务影响、阈值和处理入口，再区分规则计算、告警状态与通知投递；只有面板变红而没有明确责任人和恢复证据，响应链路仍不完整。
告警责任与行动
告警责任设计先定义用户影响、值班人和可执行处置，再写阈值。CPU高不必然影响用户，ERROR日志也不自动等于事故；优先让告警回答哪个服务出现什么影响、从哪里开始排查。规则引擎判断条件，Alertmanager聚合通知，接收端负责投递及升级，这三层健康需要分别观察。没有负责人和runbook的通知通常只增加噪声。
规则检查与管理入口
告警管理入口中promtool test rules读取规则测试，amtool用于Alertmanager查询和管理；它们是产品CLI。规则检查只能证明某类语法或预期输入，不证明通知通道能送达。读者以后须在隔离环境核对版本、配置路径和目标地址，避免amtool对生产silence作写入；silence管理是一种状态变更，不能当只读命令复制。
输入数据与安全边界
告警输入数据应有稳定service和severity标签，任意用户输入不得直接进入标签或通知模板。模板可能包含内网路径、实例名与查询参数，通知到外部渠道前要裁剪敏感字段。规则表达式观察样本而非直接检查每个用户请求，采样缺失和评估失败必须有专门处理；本例没有账号、令牌或可用通知端点，不把保留域写成可部署配置。
本篇练习与参考解答
练习：收到一条ERROR日志是否应该立即呼叫值班人？
参考解答
不必然。先确定用户影响、持续条件和可执行处置；日志事件、规则条件和通知投递是独立层。
核对资料与相邻阅读
状态机、持续时间与空数据
先明确规则标签、for、路由与接收端，再对照配套示例理解pending/firing、静默/抑制与投递结果。
核对日期2026-10-17；适用范围：机制按核对时Prometheus 3.x官方文档的稳定共同子集说明；示例另固定Prometheus 2.55与Alertmanager 0.28教学配置族，归档族不是生产安装建议。新版新增或实验功能未默认启用，实际升级仍需独立兼容与安全评估。示例未执行；真实环境仍需验证产品配置、权限、连通与恢复结果。先读起点理解前置，再按章节完成推演。
Pending与Firing
告警pending状态表示表达式已产生某标签集合，但尚未连续满足for时长；持续达到for后才进入firing。在本例未设置keep_firing_for时，任意一次求值条件不再成立会打断持续期，标签变化也会创建新实例。Prometheus 3.x还提供keep_firing_for控制已firing条件消失后的保持期，属于另一项恢复策略，本例未启用。for不是通知延迟总量，通知还受评估间隔、网络与group_wait影响。例子up=0持续2分钟触发，up恢复1即解除该规则，不把Alertmanager resolve_timeout误当Prometheus恢复等待。
空数据与采集失败
告警空数据必须与数值零区分：up=0表示已有目标抓取失败，目标从发现列表消失后up可能完全不存在，up==0就不再返回该目标。absent_over_time观察窗口内是否完全缺样本；它通常产生汇总缺失信号，不能自动知道每台原目标身份。业务延迟为空不代表延迟为0；缺失规则、抓取失败与业务阈值应分别设计，并监控规则引擎本身。
分组路由与抑制
告警路由按标签选择接收端，group_by决定哪些通知合并，group_wait等候新组，group_interval控制组变化通知，repeat_interval控制重复提醒。抑制在一个根因告警存在时暂停相关次要通知，silence是有时限的人为匹配静默；两者都不改变Prometheus的firing。equal中的service若双方缺失可能视为相等，必须固定关键标签，避免一个故障抑制无关系统。
本篇练习与参考解答
练习：up从0变成没有序列，TargetDown不触发是否说明恢复？
参考解答
不是。目标可能从发现列表消失，应核对期望清单与缺失窗口，独立区分合法下线和盲区。
核对资料与相邻阅读
本节沿用本页资料与示例入口。
继续阅读
- 开发与配置实践
- 知识专题