规则文件由什么组成
规则文件包含若干规则组，组内每条规则声明告警名称、判定表达式、持续时长与附加信息。Prometheus 按评估间隔周期性执行这些表达式，命中即产生告警实例，再由 Alertmanager 负责分组、抑制与通知。
从等待到触发
表达式命中后告警先进入等待状态，持续满足条件超过设定时长才转为触发并推送；条件恢复则进入已解决状态。这段等待用来过滤瞬时尖刺：设得太短会频繁误报，太长会延误发现，通常结合指标的正常抖动周期来决定。
标签与注解的分工
标签用于匹配与路由，注解用于给人看。标签决定告警走哪条通路、能否被抑制或静默；注解里写摘要、影响说明与排查入口。把大量信息塞进标签会破坏分组与路由，把关键维度只写进注解又会让路由无从下手。
基本信息
| 存放位置 | 由主配置的规则文件列表声明，通常按主题或团队分文件 |
|---|---|
| 评估周期 | 由全局评估间隔控制，单个规则组可覆盖 |
| 核心字段 | alert、expr、for、labels、annotations |
| 状态流转 | 命中后等待，超过持续时长转为触发，恢复后标记已解决 |
| 上线前检查 | 语法与表达式先预检，避免带着错误规则上线 |
典型使用场景
- 资源类告警：使用率或余量越过阈值并持续一段时间后通知
- 错误类告警：错误率或错误数量超过基线，直接对应用户体验
- 可用性告警：目标失联或探针失败，用于发现实例与采集问题
- 容量预警：磁盘可写时间不足，留出处置窗口
- 业务类告警：订单成功率或关键任务失败，需要业务埋点支持
- 记录规则：把常用表达式固化成新指标，供多个面板复用
规则示例
规则示例
groups:
- name: api_alerts
rules:
- alert: ApiHighErrorRate
expr: |
sum by (service) (rate(http_requests_total{code=~"5.."}[5m]))
/ sum by (service) (rate(http_requests_total[5m])) > 0.05
for: 10m # 持续超过 10 分钟才推送
labels:
severity: critical # 供路由与分组使用
annotations:
summary: "{{ $labels.service }} 错误率超过 5%"
description: "当前值 {{ $value | humanizePercentage }}"常用字段
| 字段 | 作用 | 注意 |
|---|---|---|
| alert | 告警名称，会进入标签 | 命名要能自解释 |
| expr | 判定表达式，返回非空即命中 | 先在表达式浏览器验证 |
| for | 需要持续满足的时长 | 覆盖正常抖动周期 |
| labels | 附加标签，用于路由与分组 | 严重级别通常写在这里 |
| annotations | 说明文本，支持变量插值 | 写摘要与排查入口 |
常见写法与效果
| 写法 | 效果 | 改进方向 |
|---|---|---|
| 直接比较瞬时值 | 尖刺即触发 | 配合持续时长过滤 |
| 按实例输出多条 | 告警数量随实例数增长 | 先聚合再判定 |
| 注解写死具体数值 | 故障时信息过期 | 用变量插值引用当前值 |
记录规则示例
记录规则示例
groups:
- name: sli_recording
interval: 30s
rules:
- record: job:http_error_ratio:5m # 固化成可复用的新指标
expr: |
sum by (job) (rate(http_requests_total{code=~"5.."}[5m]))
/ sum by (job) (rate(http_requests_total[5m]))编写规则的经验
- 先在看板上把表达式验证到符合预期，再固化成规则
- 一条规则只表达一个判断，便于定位与后续调整
- 严重级别写入标签，路由与通知策略按级别分流
- 注解给出可操作的信息：现象、影响范围与入口
告警表达式与看板表达式尽量保持一致：两处各写一套，故障时经常出现看板是红的却没人收到通知，或反之。
表达式命中的每条序列都会独立产生告警：标签维度设计不当会造成告警风暴，路由与分组再强也补不回来。
规则文件按主题拆分更易维护：可用性、资源、业务各一个文件，出问题时能快速定位是哪一类规则被改动。