告警规则

两个创建入口

• 从面板创建：在仪表盘面板的编辑页选 Alert 标签页，把当前查询直接变成规则。适合「先有图、再给图加哨兵」，规则会引用面板的查询。
• 独立创建：进入 Alerting → Alert rules → New alert rule，完全在告警编辑器里定义。适合正式运维场景——规则不依赖任何仪表盘，面板删了告警还在。

提示： 生产环境优先用独立创建或 Provisioning 文件管理规则；从面板创建的规则与面板耦合，仪表盘一改容易连带影响告警。

规则的骨架：查询与表达式

一条规则由若干**步骤（step）**串成，最后一步必须是条件判断：

1. Query A：数据源查询，如一段 PromQL。
2. Reduce B：把每条序列的多点数据压成单值，默认取 Last。
3. Math C：可选，对已化简的结果做四则运算，如 $B > 80。
4. Expression D（Threshold）：最终判断，IS ABOVE 80 之类。

独立创建时界面会引导你逐步添加；从面板创建时这些步骤会被自动生成，再手动调整。

for：给抖动留缓冲

Evaluate for（for） 是实例保持越线状态的时长，越线先进 Pending，熬过 for 才 Firing。它是去抖的核心手段：for: 5m 能滤掉绝大多数毛刺；设成 0 则一到即响，只适合最敏感的场景。恢复方向同理，回落也要持续满足条件才回 Normal。

标签与注解

两者长得像，用途完全不同：

注解进入通知正文，供模板引用（见静默与通知模板）。内置标签如 alertinstance、grafana_folder、alertname 由系统附加，自定义时避免占用。

多查询规则

一个数据源的多个查询不能直接比较，必须先各自 Reduce 成标量，再用 Math 步骤组合，例如 (A错误率 + B延迟) 阈值判断。跨数据源同理：A 用 Prometheus、B 用 Loki，各自化简后在 Math 里汇合。

规则组、文件夹与权限

规则必须放进某个文件夹里的评估组（组名 + 间隔）。权限随文件夹走：Viewer 只能看规则状态，Editor 及以上可创建与修改。OSS 版以组织角色为主，精细到文件夹的角色授权在 Enterprise/Cloud 提供，具体以你的实例界面为准。

导入 Prometheus 规则

已有 Prometheus 生态的 groups YAML 可以迁移进来：在 Alert rules 页选择导入（不同小版本入口名称略有差异，一般在 New alert rule 附近），粘贴原生格式即可；Provisioning 侧也支持同一格式的文件。注意导入后 annotations、labels 会保留，但通知行为完全交给 Grafana 侧策略，不再依赖原 Alertmanager。

用文件管理规则时，apiVersion: 1 的 YAML 大致如下：

group: eval-example
folder: payments
interval: 1m
rules:
  - uid: payments-high-error-rate
    title: 支付错误率过高
    condition: C
    data:
      - refId: A
        relativeTimeRange: {from: 600, to: 0}
        datasourceUid: prometheus
        model:
          expr: 'sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))'
          instant: true
      - refId: B
        datasourceUid: __expr__
        model: {type: reduce, expression: A, reducer: last}
      - refId: C
        datasourceUid: __expr__
        model: {type: threshold, expression: B, conditions: [{type: gt, value: 0.05}]}

下一步

• 规则触发后通知去哪，看联系点。
• 用标签控制分发，读通知策略与路由树。
• 端到端例子在指标与日志告警实战。