告警与问题定位：配置规则、分组与通知路由
本篇以Prometheus 告警与通知为例；前置是规则标签、for、路由与接收端。源码与输入与下文配置共用同一份文件，示例未执行。
核对日期2026-10-17；适用范围：机制按核对时Prometheus 3.x官方文档的稳定共同子集说明；示例另固定Prometheus 2.55与Alertmanager 0.28教学配置族，归档族不是生产安装建议。新版新增或实验功能未默认启用，实际升级仍需独立兼容与安全评估。示例未执行；真实环境仍需验证产品配置、权限、连通与恢复结果。先读起点理解前置，再按章节完成推演。
规则文件和测试输入
告警完整文件包括rules.yml、rules.test.yml、prometheus.yml与alertmanager.yml。示例未执行；测试给出每分钟up=0,0,0,1,1，1分钟无firing、2分钟出现TargetDown、3分钟恢复。测试exp_alerts只断言活跃firing结果，pending需通过状态语义推演，不能说已实测。另有无历史Missing、抖动重置与Slow阈值的测试输入；所有测试均未执行，且不覆盖Alertmanager路由与投递，不能扩大成全链路验收。
保留接收端与标签约束
告警接收端teaching-webhook使用example.invalid保留域，读者必须替换为自有授权TLS端点才可能发送。默认discard故意丢弃未匹配告警，生产应配置有人负责的兜底并审核路由。critical且service=checkout走专用分支，warning在本例不会实际发给人，抑制规则仍用于说明机制。没有真实端点、秘密和运行记录，不承诺任何通知已送达。
状态和失败时序推演
告警时序推演要把样本时间、评估时刻与投递时刻分开。0分钟首次up=0进入pending，2分钟评估持续满足进入firing；之后至少受30秒group_wait影响才可能发首个新组通知。若1分钟恢复则pending重置；如果路由命中但端点不可达，规则仍firing，通知失败是另一层事件。恢复up后可发send_resolved通知，但不是业务恢复已被独立确认。
完整源码、配置与依赖
下列文件与README共用同一份仓库内容，保持输入、失败与清理合同一致。示例未执行；以下命令仅供读者在满足前置后自行运行。
dependencies.txt
text
Prometheus 2.55 / promtool 2.55 teaching family (archived)
Alertmanager 0.28 configuration teaching family (archived)
No network receiver or fake service is included.prometheus.yml
yaml
global:
scrape_interval: 15s
evaluation_interval: 1m
rule_files: ['rules.yml']
alerting:
alertmanagers:
- static_configs:
- targets: ['127.0.0.1:9093']
scrape_configs:
- job_name: checkout
static_configs:
- targets: ['127.0.0.1:9109']
labels:
service: checkoutrules.yml
yaml
groups:
- name: checkout-availability
interval: 1m
rules:
- alert: CheckoutTargetDown
expr: up{job="checkout"} == 0
for: 2m
labels:
severity: critical
service: checkout
annotations:
summary: 'Checkout scrape target is unavailable'
- alert: CheckoutTelemetryMissing
expr: absent_over_time(up{job="checkout"}[5m])
for: 1m
labels:
severity: critical
service: checkout
annotations:
summary: 'No checkout target series for the observation window'
- alert: CheckoutSlow
expr: checkout_latency_seconds{service="checkout"} > 0.5
for: 2m
labels:
severity: warning
annotations:
summary: 'Checkout latency is above threshold'alertmanager.yml
yaml
global:
resolve_timeout: 5m
route:
receiver: discard
group_by: [service, alertname]
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
routes:
- receiver: teaching-webhook
matchers: ['service="checkout"', 'severity="critical"']
continue: false
receivers:
- name: discard
- name: teaching-webhook
webhook_configs:
- url: https://alerts.example.invalid/replace-with-owned-endpoint
send_resolved: true
inhibit_rules:
- source_matchers: ['alertname="CheckoutTargetDown"', 'severity="critical"']
target_matchers: ['severity="warning"']
equal: [service]rules.test.yml
yaml
rule_files: ['rules.yml']
evaluation_interval: 1m
tests:
- interval: 1m
input_series:
- series: 'up{job="checkout",instance="lab:9109",service="checkout"}'
values: '0 0 0 1 1'
alert_rule_test:
- eval_time: 1m
alertname: CheckoutTargetDown
exp_alerts: []
- eval_time: 2m
alertname: CheckoutTargetDown
exp_alerts:
- exp_labels:
job: checkout
instance: lab:9109
service: checkout
severity: critical
exp_annotations:
summary: 'Checkout scrape target is unavailable'
- eval_time: 3m
alertname: CheckoutTargetDown
exp_alerts: []
- name: Missing-from-first-evaluation
interval: 1m
input_series: []
alert_rule_test:
- eval_time: 0m
alertname: CheckoutTelemetryMissing
exp_alerts: []
- eval_time: 1m
alertname: CheckoutTelemetryMissing
exp_alerts:
- exp_labels:
job: checkout
service: checkout
severity: critical
exp_annotations:
summary: 'No checkout target series for the observation window'
- name: Flapping-resets-pending
interval: 1m
input_series:
- series: 'up{job="checkout",instance="lab:9109",service="checkout"}'
values: '0 1 0 1 0'
alert_rule_test:
- eval_time: 4m
alertname: CheckoutTargetDown
exp_alerts: []
- name: Warning-has-its-own-stable-label-set
interval: 1m
input_series:
- series: 'checkout_latency_seconds{service="checkout"}'
values: '1 1 1 1'
alert_rule_test:
- eval_time: 2m
alertname: CheckoutSlow
exp_alerts:
- exp_labels:
service: checkout
severity: warning
exp_annotations:
summary: 'Checkout latency is above threshold'README.md
md
# 告警状态、路由与抑制配置
示例未执行。依赖见dependencies.txt，四份YAML完整提供规则、测试、Prometheus连接及Alertmanager路由。没有接收服务、没有真实通知，也没有任何凭据。
读者自跑前置：自行提供隔离的Prometheus/Alertmanager相容版本；从此目录读取相对rule_files。以后可自行执行 `promtool test rules rules.test.yml`；本轮禁止且未运行。测试输入每分钟一个up值，0分钟起为0，1分钟尚pending，2分钟满足for进入firing，3分钟值1恢复，exp_alerts为空；测试只断言firing，不证明路由、通知或空数据策略。
警告接收端默认discard，critical checkout进入teaching-webhook。地址https://alerts.example.invalid/replace-with-owned-endpoint为保留域，故意不可达，读者必须替换为自有且授权的TLS端点及组织批准的秘密管理方式；替换前绝非可部署通知配置。其他未匹配告警会被discard，生产必须改成有人负责的默认接收端。
成功推演：CheckoutTargetDown持续2分钟firing，30秒group_wait后才可能通知，且以接收成功为准。service相同的warning在critical TargetDown期间被抑制；warning默认discard仅用于课堂，不代表已通知。恢复up后规则解除，send_resolved=true允许恢复通知。缺失序列不等于up=0；已有样本需退出5分钟窗口后再连续满足for=1m，而新部署没有任何历史时absent_over_time可能首次求值就为真，再等待1m。精确时刻取决于范围左开右闭与评估间隔，不能承诺启动后至少等6分钟才告警。
失败推演：up在for持续期内恢复会重置pending；severity标签改变会成为另一告警；service缺失可能导致equal误匹配，必须在规则与采集侧固定；保留域接收端失败不会改变Prometheus firing。抑制只影响通知，不修复问题，不改变规则状态。先检查表达式，再检查路由，再检查接收日志。
恢复清理：保存原规则与路由，分开回退；撤销课堂silence，停止读者自己启动的专用实例，删除隔离TSDB和Alertmanager状态前先确认不含需要保留的silence。禁止把清理生产告警状态当作恢复。恢复通知也是预期，未实际发送。本篇练习与参考解答
练习：rules.test.yml通过是否证明webhook可达？
参考解答
不能。测试只断言所列输入的规则firing结果，保留域端点不可用，路由和投递需另外验证。
核对资料与相邻阅读
继续阅读
- 知识专题
- 知识专题