Prometheus监控告警体系搭建：Metrics采集与Alertmanager规则配置

Prometheus架构与Metrics采集模型

Prometheus是CNCF毕业的第二个项目（仅次于Kubernetes），已成为云原生监控告警体系的事实标准。其核心架构包含四个组件：Prometheus Server负责指标采集与存储、Alertmanager处理告警路由与通知、Pushgateway支持短生命周期任务指标上报、Exporter采集被监控目标的数据。

Prometheus采用Pull模型采集指标，Server主动访问目标端点抓取Metrics。这种模型相比Push模型的优势在于：主动控制采集频率、便于发现目标不可达、避免Agent故障导致数据积压。四种指标类型满足不同监控需求：

# prometheus.yml 核心配置

global:
  scrape_interval: 15s        # 默认采集间隔
  evaluation_interval: 15s    # 规则评估间隔
  scrape_timeout: 10s         # 采集超时

# 告警规则文件
rule_files:
  - "rules/node_alerts.yml"
  - "rules/app_alerts.yml"

# Alertmanager配置
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

# 采集目标配置
scrape_configs:
  # Prometheus自我监控
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']
  
  # Node Exporter - 主机指标
  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.101:9100', '192.168.1.102:9100']
  
  # 应用自定义指标
  - job_name: 'app'
    metrics_path: /metrics
    static_configs:
      - targets: ['192.168.1.101:8080', '192.168.1.102:8080']

四种指标类型中，Counter只增不减（如请求总数），Gauge可增可减（如内存使用），Histogram分桶统计分布（如响应延迟），Summary计算分位数（如P99延迟）。选择正确的指标类型是构建有效监控体系的基础。

Exporter部署与核心指标采集

Node Exporter采集主机级指标，包括CPU、内存、磁盘I/O、网络流量等。部署时需关注端口管理和系统权限配置。

# Node Exporter部署
wget https://github.com/prometheus/node_exporter/releases/download/v2.0.0/node_exporter-2.0.0.linux-amd64.tar.gz
tar xzf node_exporter-2.0.0.linux-amd64.tar.gz

# systemd服务配置
cat > /etc/systemd/system/node_exporter.service << 'EOF'
[Unit]
Description=Node Exporter
After=network.target

[Service]
ExecStart=/usr/local/bin/node_exporter --web.listen-address=:9100
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now node_exporter

# 常用PromQL查询
# CPU使用率（排除idle）
100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 内存使用率
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100

# 磁盘空间使用率
node_filesystem_avail_bytes / node_filesystem_size_bytes * 100

# 磁盘I/O吞吐
rate(node_disk_read_bytes_total[5m]) + rate(node_disk_written_bytes_total[5m])

textfile collector支持自定义脚本输出的指标，将脚本定期采集的数据写入.collector文件，Node Exporter自动采集并暴露为Prometheus指标。这一机制在不修改Exporter代码的前提下扩展了监控能力。

告警规则编写与Alertmanager配置

告警规则的编写需要平衡灵敏度和噪音。规则过松导致故障漏报，过紧产生告警疲劳。合理设置阈值和持续时间是关键。

# rules/node_alerts.yml

groups:
  - name: node_alerts
    rules:
      # CPU使用率超过80%持续5分钟
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
          team: ops
        annotations:
          summary: "CPU使用率过高 {{ $labels.instance }}"
          description: "实例 {{ $labels.instance }} CPU使用率为 {{ $value }}%，超过80%阈值"
      
      # 磁盘空间不足
      - alert: DiskSpaceLow
        expr: node_filesystem_avail_bytes / node_filesystem_size_bytes * 100 < 15
        for: 10m
        labels:
          severity: critical
          team: ops
        annotations:
          summary: "磁盘空间不足 {{ $labels.instance }}"
      
      # 服务宕机
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
          team: ops
        annotations:
          summary: "服务不可达 {{ $labels.instance }}"

for字段指定告警条件持续多久后触发，避免短暂抖动导致误报。labels中的severity和team用于Alertmanager路由分发。

# alertmanager.yml

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s        # 告警分组等待时间
  group_interval: 5m     # 同组告警发送间隔
  repeat_interval: 4h    # 重复告警间隔
  receiver: 'default'
  
  routes:
    - matchers: ['severity="critical"']
      receiver: 'critical-webhook'
      group_wait: 10s
    - matchers: ['severity="warning"']
      receiver: 'warning-webhook'

receivers:
  - name: 'default'
    webhook_configs:
      - url: 'http://127.0.0.1:5000/alert'
  
  - name: 'critical-webhook'
    webhook_configs:
      - url: 'http://127.0.0.1:5000/critical'
        send_resolved: true
  
  - name: 'warning-webhook'
    webhook_configs:
      - url: 'http://127.0.0.1:5000/warning'
        send_resolved: true

group_by将同一实例的多个告警合并发送，避免告警风暴。send_resolved: true在告警恢复时发送恢复通知，帮助运维人员确认问题已解决。Alertmanager支持Webhook、邮件、钉钉、企业微信等多种通知渠道。

Grafana可视化与监控看板搭建

Grafana作为Prometheus的前端可视化组件，通过PromQL查询将指标绘制为实时图表。搭建监控看板的关键是按服务维度组织面板：

# 关键看板面板PromQL

# 1. QPS - 每秒请求数
sum(rate(http_requests_total[1m])) by (handler)

# 2. P99响应延迟
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

# 3. 错误率
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100

# 4. 在线连接数
http_connections{state="active"}

# 5. JVM GC时间
rate(jvm_gc_collection_seconds_sum[5m]) * 1000

Grafana支持导入社区共享的看板模板（Dashboard ID），Node Exporter Full（ID: 1860）提供了完整的主机监控面板，Spring Boot Statistics（ID: 12900）覆盖了JVM和应用层指标。在看板中设置变量下拉菜单实现多实例切换，配合告警注释面板可以快速关联指标异常与告警事件。

监控告警体系的搭建是一个持续调优的过程。初期应从核心指标（CPU、内存、磁盘、网络）入手，逐步扩展到应用层指标（QPS、延迟、错误率）和业务指标。告警阈值建议参考历史数据P95/P99值设定，上线运行两周后根据实际触发情况微调，最终形成贴合业务特征的告警规则。