Prometheus告警规则配置与Alertmanager多渠道通知实战

Prometheus告警体系架构与规则定义语法

Prometheus告警系统由两部分组成：Prometheus Server负责告警规则评估和触发，Alertmanager负责告警去重、分组、路由和通知发送。告警规则使用PromQL表达式定义，当表达式结果包含时间序列且持续满足for指定的时长后，告警状态从pending转为firing并发送给Alertmanager。这一设计将告警触发与通知解耦，使得规则维护和通知渠道管理相互独立。

告警规则的核心语法结构如下：alert定义告警名称，expr指定PromQL表达式，for设置从pending到firing的等待时长，labels和annotations分别用于附加结构化标签和描述信息。annotations支持模板变量引用告警标签值，实现动态告警内容。

核心指标告警规则编写实战

以下是覆盖CPU、内存、磁盘、服务可用性等核心维度的告警规则配置：

# /etc/prometheus/rules/alerts.yml

groups:
  - name: node_alerts
    rules:
      # CPU使用率持续5分钟超过85%
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU使用率过高 {{ $labels.instance }}"
          description: "实例 {{ $labels.instance }} CPU使用率已达 {{ $value }}%，持续超过5分钟"

      # 内存使用率超过90%
      - alert: HighMemoryUsage
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "内存不足 {{ $labels.instance }}"
          description: "可用内存低于10%，当前使用率 {{ $value }}%"

      # 磁盘空间不足
      - alert: DiskSpaceLow
        expr: (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "磁盘空间不足 {{ $labels.instance }} {{ $labels.mountpoint }}"
          description: "挂载点 {{ $labels.mountpoint }} 使用率 {{ $value }}%"

  - name: service_alerts
    rules:
      # 服务宕机 - 目标无法抓取
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "服务不可达 {{ $labels.job }} {{ $labels.instance }}"
          description: "Prometheus已超过1分钟无法抓取 {{ $labels.job }} 的指标"

      # HTTP 5xx错误率突增
      - alert: HighHttpErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m])) by(service)
          / sum(rate(http_requests_total[5m])) by(service) > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "HTTP 5xx错误率过高 {{ $labels.service }}"
          description: "服务 {{ $labels.service }} 5xx错误率 {{ $value | humanizePercentage }}"

      # 接口响应时间P99超过阈值
      - alert: HighLatency
        expr: |
          histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by(le, service)) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "接口延迟过高 {{ $labels.service }}"
          description: "P99延迟超过2秒，当前 {{ $value }}秒"

Alertmanager路由分组与抑制规则配置

Alertmanager收到告警后执行去重、分组、静默和路由操作。合理的路由配置能确保告警发送到正确的接收人并通过合适渠道通知：

# /etc/alertmanager/alertmanager.yml

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alert@example.com'
  smtp_auth_username: 'alert@example.com'
  smtp_auth_password: 'password'

# 告警模板
templates:
  - '/etc/alertmanager/templates/*.tmpl'

# 路由配置
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default-webhook'
  
  routes:
    # critical级别走电话+短信+钉钉
    - match:
        severity: critical
      receiver: 'critical-notify'
      group_wait: 10s
      
    # warning级别走钉钉+邮件
    - match:
        severity: warning
      receiver: 'warning-notify'
      
    # 按业务线路由
    - match_re:
        service: '^(order|payment|inventory)$'
      receiver: 'core-business'
      group_by: ['alertname', 'service']

# 抑制规则：服务整体宕机时抑制该服务的子告警
inhibit_rules:
  - source_match:
      alertname: ServiceDown
    target_match_re:
      alertname: 'High.*|Low.*'
    equal: ['instance']

receivers:
  - name: 'default-webhook'
    webhook_configs:
      - url: 'http://localhost:9094/webhook'

  - name: 'critical-notify'
    webhook_configs:
      - url: 'https://oapi.dingtalk.com/robot/send?access_token=TOKEN'
        send_resolved: true
    email_configs:
      - to: 'ops-team@example.com'
        send_resolved: true

  - name: 'warning-notify'
    webhook_configs:
      - url: 'https://oapi.dingtalk.com/robot/send?access_token=TOKEN2'
    email_configs:
      - to: 'dev-team@example.com'

  - name: 'core-business'
    webhook_configs:
      - url: 'http://localhost:9094/core-business-webhook'

group_by控制聚合维度，将同一alertname和service的告警合并为一条通知。group_wait是首批告警的等待窗口，在这段时间内产生的同组告警会合并发送。inhibit_rules中的source_match匹配到ServiceDown告警时，同实例的其他告警被抑制，避免告警风暴。

钉钉与企业微信通知模板定制

Alertmanager原生不支持钉钉和企业Webhook格式，需通过转发服务适配。推荐部署prometheus-webhook-dingtalk作为中间层：

# 部署dingtalk-webhook
docker run -d --name dingtalk-webhook \
  -p 8060:8060 \
  -e DINGTALK_TOKEN=your_token \
  timonwong/prometheus-webhook-dingtalk:latest

# Alertmanager配置指向dingtalk-webhook
receivers:
  - name: 'dingtalk'
    webhook_configs:
      - url: 'http://127.0.0.1:8060/dingtalk/webhook1/send'
        send_resolved: true

告警模板文件定义通知内容的格式化输出：

# /etc/alertmanager/templates/dingtalk.tmpl

{{ define "dingtalk.default.title" }}
[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}
{{ end }}

{{ define "dingtalk.default.content" }}
### 告警状态: {{ .Status | toUpper }}
{{ range .Alerts }}
---
**告警名称:** {{ .Labels.alertname }}
**严重级别:** {{ .Labels.severity }}
**实例:** {{ .Labels.instance }}
**描述:** {{ .Annotations.description }}
**触发时间:** {{ .StartsAt.Format "2006-01-02 15:04:05" }}
{{ if eq .Status "resolved" }}
**恢复时间:** {{ .EndsAt.Format "2006-01-02 15:04:05" }}
{{ end }}
{{ end }}
{{ end }}

告警质量治理与防骚扰实践

告警系统的长期运营核心是控制告警质量，避免告警疲劳。从工程实践看，有效的治理手段包括：按severity分级，critical级别必须关联值班On-Call，warning级别仅通知团队群；设置repeat_interval避免未恢复告警重复轰炸；利用静默(silence)在维护窗口期间临时屏蔽已知告警；定期审计告警命中率，对从未触发的规则和频繁误报的规则进行调整。

# 通过amtool管理静默规则
# 创建静默：维护期间屏蔽disk告警
amtool silence add \
  --comment "磁盘维护窗口" \
  --duration 2h \
  alertname=DiskSpaceLow

# 查看活跃静默
amtool silence query

# 提前结束静默
amtool silence expire <silence-id>

# 查看当前firing告警
amtool alert query alerted=true

Prometheus每15秒评估一次告警规则（由evaluation_interval控制），规则文件挂载后通过SIGHUP信号或POST /-/reload接口热加载，无需重启服务。Alertmanager配置变更同样支持热加载。生产环境建议将告警规则纳入Git版本管理，通过CI流水线语法校验后自动部署，确保变更可追溯。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/prometheus-gao-jing-gui-ze-pei-zhi-yu-alertmanager-duo-qu/