Prometheus监控告警体系搭建：Exporter指标采集与Alertmanager告警路由配置

Prometheus监控告警体系的架构组成

监控告警体系是网站运维的标配，Prometheus + Exporter + Alertmanager是最常见的开源组合。Prometheus负责拉取指标、存储时序数据，exporter把系统/中间件指标转换成Prometheus格式，Alertmanager负责把告警分发给钉钉、邮件等渠道。下面按搭建顺序走一遍。

Prometheus与node_exporter部署配置

node_exporter收集CPU、内存、磁盘、网络等主机指标，每个目标机器跑一个：

wget .../node_exporter-1.8.2.linux-amd64.tar.gz
tar xf node_exporter*.tar.gz
./node_exporter --web.listen-address=":9100" &

Prometheus主服务通过配置文件定义抓取目标，prometheus.yml：

global:
  scrape_interval: 15s
scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['192.168.1.10:9100', '192.168.1.11:9100']

启动Prometheus后用Targets页面确认目标UP状态。数据库、中间件都有对应exporter（mysqld_exporter、redis_exporter、kafka_exporter），配置方式一致，只需要新增一个job。

监控告警规则编写与阈值设计

告警规则写在rules.yml里，被Prometheus定时评估：

groups:
  - name: node-alerts
    rules:
      - alert: HostHighCPU
        expr: 100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100 > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} CPU 持续高位"

expr为告警触发表达式，for为持续多久才触发（避免瞬时抖动误报）。阈值要按业务压测数据定，别照抄网上模板——线上85% CPU可能没事，有的服务60%就出问题。

Alertmanager告警路由与去重分组配置

Alertmanager接收Prometheus推送的告警，负责去重、分组、路由到不同接收方。alertmanager.yml核心配置：

route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers:
        - severity = critical
      receiver: page
    - matchers:
        - severity = warning
      receiver: email
receivers:
  - name: page
    webhook_configs:
      - url: 'http://dingtalk-webhook:5000/'
  - name: email
    email_configs:
      - to: 'ops@example.com'

同一个告警名称5分钟内合并为一条通知，同一IP的连续报警不再轰炸。Webhook方式可对接钉钉、企业微信机器人，配置最省事。

告警通知集成：钉钉与邮件webhook实现

Alertmanager本身没有钉钉原生渠道，用webhook把告警转发到钉钉机器人（或通过prometheus-webhook-dingtalk中转）。webhook收到JSON后按钉钉协议发消息，关键字段：alerts[].annotations.summary（摘要）、status（firing/resolved）。生产经验：告警消息里带上实例IP、指标当前值、持续时间，值班人员不用再登录平台看详情。

监控指标留存与告警误报控制

指标保留时间默认15天，磁盘紧张用tsdb的–storage.tsdb.retention.time调整。告警误报的两个常见原因：拉取间隔与for时间设置过短、阈值按峰值拍脑袋。建议把阈值设计成多级（warning/ critical），配合持续时长，把”抖动”和”故障”分开。