3. Grafana 告警体系概述

Grafana Alerting 是统一的可观测性告警中枢,它从多个数据源采集指标与日志,通过灵活的规则引擎评估是否触发告警,再经由通知渠道将告警送达运维人员。本章从架构、数据源集成、规则引擎、通知渠道四个维度拆解其核心设计。

3.1 告警体系架构总览

Grafana Alerting 采用“采集 → 评估 → 路由 → 通知”的分层架构,各组件职责清晰、可独立扩展。下图展示了告警数据流与核心模块的协作关系。

Grafana Alerting 架构总览 数据源层 Prometheus / Loki / Graphite 规则引擎层 评估 / 分组 / 抑制 通知路由层 路由匹配 / 接收器 告警存储 (Alertmanager) 通知渠道 架构要点说明 1. 数据源层:支持 Prometheus、Loki、Graphite、InfluxDB 等,通过统一接口获取时序数据。 2. 规则引擎层:周期性评估告警规则,支持条件表达式、聚合查询、多维度分组。 3. 通知路由层:根据标签匹配将告警分发到不同接收器,支持抑制与静默。 4. 告警存储:内置 Alertmanager 负责去重、分组、抑制,保证通知不泛滥。
架构设计要点:Grafana 8.0 之后将告警引擎内嵌到核心,不再依赖外部 Alertmanager。规则评估在 Grafana 服务端执行,通知路由由内置 Alertmanager 处理,减少了部署复杂度。

3.2 数据源集成

Grafana Alerting 支持多种数据源类型,每种数据源在告警规则中的查询语法和返回格式略有差异。下表列出主流数据源的集成方式与关键参数。

数据源类型 查询语言 告警规则示例 返回格式 适用场景
Prometheus PromQL avg(rate(http_requests_total[5m])) > 100 瞬时向量 / 范围向量 指标告警、SLO 监控
Loki LogQL rate({job="api"}[5m]) > 50 日志流 / 指标 日志告警、错误率监控
Graphite Graphite 函数 sumSeries(api.*.latency) > 500 时间序列 传统指标告警
InfluxDB InfluxQL / Flux SELECT mean("cpu") FROM "cpu" WHERE time > now() - 5m 表格式结果 自定义指标告警
Elasticsearch ES DSL {"query":{"range":{"@timestamp":{"gte":"now-5m"}}}} 文档计数 日志告警、异常检测
集成注意事项:告警规则中使用的数据源必须在 Grafana 中预先配置并测试连通性。Prometheus 和 Loki 是告警场景中最常用的数据源,因为它们原生支持聚合查询和标签过滤,适合构建复杂的阈值条件。

3.3 告警规则引擎

规则引擎是 Grafana Alerting 的核心,负责周期性执行查询、评估条件、生成告警实例。每条规则包含以下关键属性:

  • 查询表达式:使用数据源查询语言定义要监控的指标或日志。
  • 评估频率:每隔多少秒/分钟执行一次查询,默认 60s。
  • 条件表达式:对查询结果进行逻辑判断,如 avg() > 90 或 count() == 0。
  • 持续时间:条件满足后持续多久才触发告警,用于避免抖动。
  • 标签与注释:附加元数据,用于路由匹配和告警信息展示。

规则引擎的工作流程如下图所示:

规则引擎评估流程 定时触发 执行查询 条件评估 生成告警实例 不满足 → 重置 条件不满足 关键参数:评估频率(evaluate_every)、持续时间(for)、条件表达式(condition)。 持续时间用于过滤瞬时抖动,例如“CPU > 90% 持续 5 分钟”才触发告警。
规则引擎避坑:避免设置过短的评估频率(如 5s),否则可能对数据源造成过大查询压力。建议评估频率不低于 30s,持续时间至少为评估周期的 2 倍以上。

3.4 通知渠道

告警触发后,Grafana 通过通知渠道将告警信息推送到运维工具。支持的通知渠道类型及配置要点如下表所示。

通知渠道 协议/方式 配置关键字段 适用场景
Email SMTP SMTP 服务器、端口、认证、收件人 非紧急告警、日报
Slack Webhook Webhook URL、频道、消息模板 团队即时通知
PagerDuty API 集成密钥、服务 ID、严重级别 值班 On-Call 告警
Webhook HTTP POST URL、请求头、自定义 JSON 模板 自定义集成、自动化
钉钉/飞书 Webhook Webhook URL、签名、消息格式 国内团队即时通知

通知路由通过“标签匹配”将告警分发到不同接收器。例如:

# 路由规则示例
route:
  receiver: 'critical-team'
  match:
    severity: critical
  routes:
    - receiver: 'warning-team'
      match:
        severity: warning
通知渠道最佳实践:为不同严重级别配置独立路由,critical 告警走 PagerDuty 或电话通知,warning 告警走 Slack 或 Email。避免将所有告警发送到同一个渠道,防止通知疲劳。

3.5 告警规则与通知协同

告警规则与通知渠道的协同通过“告警组”和“路由树”实现。每条告警规则可以指定标签,路由树根据标签匹配将告警分发到对应接收器。协同流程如下:

  1. 定义告警规则时设置标签,如 severity=critical、team=platform。
  2. 在 Alertmanager 配置中创建路由树,按标签匹配分发。
  3. 每个路由节点绑定一个接收器(Receiver),接收器包含通知渠道配置。
  4. 告警触发后,Alertmanager 根据路由树将告警发送到对应接收器。
协同调优要点:告警规则中的标签设计直接影响路由效率。建议统一标签命名规范,例如 severity、team、service,避免使用动态值作为路由标签。