Grafana 告警架构详解：从规则到通知的完整闭环

Grafana 告警架构详解：从规则到通知的完整闭环

Grafana 自 8.0 版本起重构了告警系统，引入了现代化的 Unified Alerting（统一告警） 架构，取代了旧版的“面板级告警”。新架构更加灵活、强大，支持多数据源、复杂路由和精细化通知策略。

本文将深入详解 Grafana 告警的三大核心组件：

• ✅ 告警规则（Alert Rules）
• ✅ 联系点（Contact Points）
• ✅ 通知策略（Notification Policies）

帮助你构建一个可靠、可管理、低噪音的告警体系。

---

一、Grafana 告警整体架构

✅ Grafana 自身作为告警评估引擎，无需依赖 Prometheus + Alertmanager。

---

一、1. 告警规则（Alert Rules）——触发条件定义

告警规则定义了“在什么条件下触发告警”，是整个告警系统的起点。

1.1 创建位置

• 在 Dashboard 的 Panel 中直接创建
• 或在 Alerting → Alert rules 中独立管理

1.2 核心配置项

配置项	说明
Rule name	告警名称（唯一标识）
Evaluate every	规则评估频率（如 1m）
For	持续时间，满足条件后等待多久才触发（如 5m）
Conditions	查询条件（基于 Panel 查询或自定义）

1.3 条件（Conditions）详解

示例：CPU 使用率过高

- query: A
  reducer: avg
  expression: avg(last_5m)
  operator: >
  value: 0.8

• query: A：引用 Panel 中的 Query A
• reducer: avg：对多时间序列取平均
• expression: avg(last_5m)：使用过去 5 分钟的平均值
• > 0.8：阈值 80%

1.4 多条件组合

支持 AND / OR 组合多个条件：

# 条件1：CPU > 80%
# 条件2：内存 > 90%
# 两者同时满足才告警

1.5 支持的数据源

• Prometheus（PromQL）
• Loki（LogQL）
• MySQL/PostgreSQL（SQL）
• InfluxDB
• Elasticsearch
• VictoriaMetrics
• 等等

✅ 真正实现“统一告警”，不再局限于指标。

---

二、2. Contact Point（联系点）——通知渠道配置

Contact Point 定义了“告警发送到哪里”，即通知渠道。

2.1 配置入口

• Alerting → Contact points → New contact point

2.2 支持的渠道类型

类型	配置要点
Webhook	自定义 URL，支持 JSON 模板
Slack	输入 Webhook URL，选择频道
Email	配置 SMTP 服务器
PagerDuty	输入 Integration Key
DingTalk / Feishu	国内常用
Kafka	发送到消息队列
Google Hangouts Chat	企业通讯工具

2.3 消息模板（Message Template）

Grafana 支持 Go 模板语法，可自定义通知内容：

{{ range .Alerts }}
**告警**: {{ .Labels.alertname }}
**实例**: {{ .Labels.instance }}
**值**: {{ .Value }}
**描述**: {{ .Annotations.description }}
**链接**: {{ .GeneratorURL }}
{{ end }}

内置变量

• .Status：firing / resolved
• .Labels：告警标签
• .Annotations：描述、runbook_url
• .Value：触发值
• .StartsAt / .EndsAt：时间
• .GeneratorURL：跳转到 Grafana

✅ 可添加 runbook_url 链接，提升故障处理效率。

---

三、3. Notification Policy（通知策略）——路由与分组控制

Notification Policy 是告警系统的“大脑”，决定“什么样的告警发给谁”，并控制分组、静默、重复等行为。

3.1 配置入口

• Alerting → Notification policies

3.2 核心功能

（1）路由规则（Routing Rules）

基于标签（Labels）匹配，将告警路由到不同的 Contact Point。

- name: 'critical-alerts'
  matchers:
    - alertname = "HighCpuUsage"
    - severity = "critical"
  contact_point: 'pagerduty-team-a'

- name: 'warning-alerts'
  matchers:
    - severity = "warning"
  contact_point: 'slack-ops'

✅ 支持 =, !=, =~（正则匹配）

（2）分组（Grouping）

将相似告警合并发送，避免告警风暴。

group_by: ['alertname', 'cluster', 'job']
group_wait: 30s          # 首次触发后等待 30s，收集更多告警
group_interval: 5m       # 每 5m 发送一次组内新告警

（3）静默（Mute Timing）

定义时间段内不发送告警，如维护窗口。

- name: 'maintenance-window'
  time_intervals:
    - weekdays: ['monday:02:00-monday:04:00']
      times:
        - start_time: '02:00'
          end_time: '04:00'

（4）抑制（Inhibition）

当某个告警触发时，抑制其他相关告警，减少噪音。

- source_match:
    alert: 'HostDown'
  target_match:
    alert: 'InstanceUnreachable'
  equal: ['instance', 'job']

✅ 节点宕机时，抑制其上所有服务的“实例不可达”告警。

（5）重复提醒（Repeat Interval）

已触发的告警，每隔一段时间重复通知。

repeat_interval: 3h  # 每 3 小时重发一次

---

四、告警生命周期

• Idle：正常状态
• Pending：条件满足，但未达到 For 时间
• Firing：已触发，发送通知
• Resolved：恢复正常，发送“已解决”通知（可选）

---

五、实战：配置一个完整的告警流程

目标

为 CPU 使用率过高配置告警，发送到 Slack，并设置抑制规则。

步骤

1. 创建 Contact Point：Slack

• Name: slack-ops
• Type: Slack
• URL: https://hooks.slack.com/services/XXX/YYYY/ZZZ
• Channel: #alerts
• Send resolved alerts: true

2. 配置 Notification Policy

- name: 'cpu-alerts'
  matchers:
    - alertname = "HighCpuUsage"
  contact_point: 'slack-ops'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h

3. 创建告警规则

• Rule name: HighCpuUsage
• Evaluate every: 1m
• For: 5m
• Condition:

  - query: A
    reducer: avg
    expression: avg(last_5m)
    operator: >
    value: 0.8
  

• Annotations:

  summary: "CPU usage high on {{ $labels.instance }}"
  description: "CPU usage is {{ $value }} on {{ $labels.instance }}"
  runbook_url: "https://runbooks.example.com/high-cpu"
  

✅ 效果：CPU > 80% 持续 5 分钟 → Slack 收到告警。

---

六、最佳实践

实践	说明
✅ 使用 For 避免瞬时抖动	如 For: 5m
✅ 合理分组	按 alertname, instance 分组
✅ 设置 repeat_interval	避免遗忘处理
✅ 添加 runbook_url	提升故障处理效率
✅ 配置抑制规则	减少告警噪音
✅ 使用静默	维护期不打扰
✅ 测试告警	使用 Test Rule 功能

---

七、与 Prometheus + Alertmanager 对比

特性	Grafana 告警	Prometheus + Alertmanager
多数据源支持	✅ 支持 PromQL、LogQL、SQL	❌ 主要支持 PromQL
可视化配置	✅ Web UI 配置	❌ YAML 文件
统一平台	✅ 指标+日志+数据库告警	❌ 需多个系统
学习成本	✅ 低，适合中小团队	✅ 高，适合大型系统
高可用	需配置多个 Grafana 实例	Alertmanager 天然集群

✅ Grafana 告警更适合中小团队快速上手
✅ 大型系统仍推荐 Prometheus + Alertmanager

---

八、总结

Grafana 的现代告警架构由三大核心组件构成：

组件	职责
Alert Rules	定义“什么情况下告警”
Contact Points	定义“告警发送到哪里”
Notification Policies	定义“如何路由、分组、抑制”

核心优势：

“一个平台，统一管理所有告警。”

通过合理配置，你可以构建一个低噪音、高可用、可维护的告警系统，真正实现“有问题能发现，发现问题能解决”。