Grafana告警规则编写与多渠道通知集成配置

Grafana告警体系架构与规则设计原则

网站运维中，告警系统是故障发现的第一道防线。Grafana从9.0版本起引入统一的Alerting引擎，支持将Prometheus、Loki、InfluxDB等多数据源的告警规则集中管理，配合Contact Points实现邮件、钉钉、飞书、企业微信、Slack等多渠道通知。

告警规则设计遵循三条核心原则：可操作性（每条告警都对应明确的处理动作）、信噪比控制（避免告警风暴淹没关键信号）、分级递进（Warning与Critical分层触发）。一条好的告警规则需要明确：检测什么指标、持续多久触发、严重等级是什么、通知到谁。

Alert Rule编写与PromQL表达式实战

Grafana Alert Rule的配置支持UI操作和代码定义两种方式。生产环境推荐用Terraform或GitOps管理告警规则，实现版本控制和批量部署。以下给出几类典型告警规则的PromQL表达式：

# CPU使用率持续高企告警
# 5分钟内CPU平均使用率超迅85%
100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85

# 内存可用率低于阈值
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10

# 磁盘空间告警（排除临时文件系统）
(node_filesystem_avail_bytes{fstype!="tmpfs",fstype!="overlay"}
 / node_filesystem_size_bytes{fstype!="tmpfs",fstype!="overlay"}) * 100 < 10

# HTTP 5xx错误率突增
(sum(rate(http_requests_total{status=~"5.."}[5m]))
 / sum(rate(http_requests_total[5m]))) * 100 > 5

# Pod CrashLoopBackOff检测
increase(kube_pod_container_status_restarts_total[5m]) > 3

规则编写注意事项：避免使用瞬时值做告警判断，always搭配5m以上时间窗口做rate或avg计算，过滤掉短暂的毛刺抖动。标签（label）在告警路由中起关键作用，合理使用severity、team、service标签实现精准分发。

多渠道Contact Points配置

Grafana Contact Points定义告警通知的目标渠道与消息模板。一个Alert Rule可以关联多个Contact Point，实现多渠道同时触达。

# 钉钉机器人Webhook配置（Terraform示例）
resource "grafana_contact_point" "dingtalk" {
  name = "dingtalk-ops"
  dingding {
    url      = "https://oapi.dingtalk.com/robot/send?access_token=xxx"
    message_type = "actionCard"
    title    = "{{ .GroupLabels.alertname }}"
    message  = <<-EOF
### 告警: {{ .GroupLabels.alertname }}
**严重等级**: {{ .CommonLabels.severity }}
**实例**: {{ .CommonLabels.instance }}
{{ range .Alerts }}
- **详情**: {{ .Annotations.summary }}
- **触发时间**: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
{{ end }}
EOF
  }
}

# 飞书机器人Webhook配置
resource "grafana_contact_point" "feishu" {
  name = "feishu-sre"
  webhook {
    url = "https://open.feishu.cn/open-apis/bot/v2/hook/xxx"
  }
}

# 邮件通知配置
resource "grafana_contact_point" "email" {
  name = "email-oncall"
  email {
    addresses = ["oncall@company.com"]
    subject   = "[{{ .CommonLabels.severity }}] {{ .GroupLabels.alertname }}"
  }
}

消息模板设计要点：标题必须包含告警名称与严重等级，正文包含受影响实例、触发值与阈值的对比、时间戳。飞书和钉钉支持卡片消息，比纯文本更易快速识别。模板中使用GroupLabels做告警分组去重，避免同一故障的多个指标重复发送。

Notification Policies告警路由与抑制

Notification Policies决定告警路由到哪个Contact Point，支持基于标签的匹配规则链。路由配置遵循树形匹配，从根节点向下逐级匹配，第一个命中的规则生效。

# 告警路由策略（Terraform示例）
resource "grafana_notification_policy" "routing" {
  group_by      = ["alertname", "instance"]
  contact_point = grafana_contact_point.email.name

  # Critical级别告警同时发邮件+钉钉+飞书
  policy {
    matcher {
      label = "severity"
      value = "critical"
    }
    contact_point = grafana_contact_point.email.name
    group_wait    = "30s"
    group_interval = "5m"
    repeat_interval = "4h"

    policy {
      contact_point  = grafana_contact_point.dingtalk.name
      group_wait     = "30s"
      repeat_interval = "4h"
    }
    policy {
      contact_point  = grafana_contact_point.feishu.name
      group_wait     = "30s"
      repeat_interval = "4h"
    }
  }

  # Warning级别仅发钉钉
  policy {
    matcher {
      label = "severity"
      value = "warning"
    }
    contact_point   = grafana_contact_point.dingtalk.name
    group_wait      = "5m"
    group_interval   = "10m"
    repeat_interval  = "12h"
  }
}

告警抑制（Inhibition）用于在高级别告警触发时自动静默低级别相关告警。例如节点宕机触发的critical告警，应自动抑制该节点上所有service级别的warning告警，避免告警风暴。Grafana通过Mute Timings实现定时静默，维护窗口期间暂停非紧急告警通知。

告警质量治理与SLO驱动告警

告警泛滥是运维团队最大的效率杀手。治理方法分三步：第一步，统计过去30天所有告警，标记未触发任何处理动作的”无用告警”，直接调整阈值或删除；第二步，对保留的告警做分级，只有需要人工介入的才发通知，自动修复的走自愈脚本不告警；第三步，引入SLO（Service Level Objective）驱动告警，基于错误预算消耗率触发，而非单一指标阈值。

SLO告警的优势：将多个底层指标（延迟、错误率、可用性）统一转换为错误预算消耗进度，当30天错误预算在1小时内消耗超过2%时触发告警。这类告警直接关联业务影响，信噪比远高于单一指标告警。Grafana原生支持SLO资源定义，配合Pyrra等开源工具可快速搭建SLO告警体系。

定期做告警复盘：每两周统计告警触发次数、平均响应时间、MTTR，识别高频低价值告警持续优化。目标是将告警数量压缩到每天不超过20条有效告警，每条都有明确处置动作。