Prometheus 监控实战：从指标采集到告警体系的完整搭建

监控是运维的"眼睛"。在 Prometheus 之前，监控体系往往靠 Zabbix 等轮询式工具，指标零散、告警滞后。Prometheus 以"拉取式采集 + 多维标签 + PromQL"重新定义了监控标准，成为云原生时代的监控事实标准。本文从指标模型讲起，完整搭建一套可用的监控告警体系。

一、核心概念：指标模型与拉取架构

Prometheus 的核心是指标（Metric），格式为 指标名{标签=值} 数值：

http_requests_total{method="GET", status="200"} 1024

• 指标名描述测量对象，标签描述维度，样本值为当前数值；
• 同一指标不同标签组合即不同时间序列（time series）。

架构上 Prometheus 主动拉取（scrape）目标暴露的 /metrics 端点，而非等目标推送。这意味着：

• 目标需要暴露 HTTP 端点（Exporter 就是干这个的）；
• 每个目标配置抓取间隔与超时；
• 无目标上报导致的历史数据可通过 --storage.tsdb.retention.time 控制保留时长。

二、指标体系搭建

2.1 采集层：Exporter 生态

| 采集对象 | Exporter | 端点示例 | |----------|----------|----------| | 服务器基础指标 | node_exporter | node_cpu_seconds_total | | MySQL | mysqld_exporter | mysql_global_status_threads_connected | | Redis | redis_exporter | redis_connected_clients | | Nginx | nginx_exporter | nginx_http_requests_total | | 应用业务指标 | 自研暴露 | http_requests_total |

以 node_exporter 为例：

./node_exporter --web.listen-address=":9100" &
curl localhost:9100/metrics | head

2.2 配置抓取任务

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["10.0.1.11:9100", "10.0.1.12:9100"]
  - job_name: "mysql"
    static_configs:
      - targets: ["10.0.1.11:9104"]
  - job_name: "api"
    metrics_path: "/metrics"
    static_configs:
      - targets: ["10.0.1.21:8080"]

三、PromQL：监控查询语言

3.1 基础查询

node_cpu_seconds_total                                    # 原始时间序列
rate(node_cpu_seconds_total{mode="idle"}[5m])            # 5分钟每秒平均速率
sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)  # 按实例聚合CPU使用率

3.2 常用聚合操作符

• sum / avg / max / min：按维度聚合；
• by / without：按标签分组；
• rate / irate：速率计算（irate 更适合高频突变指标）；
• increase()：增量。

# 每台机器的 CPU 使用率
(1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)) * 100

# 每秒 HTTP 请求数按状态码分布
sum(rate(http_requests_total[5m])) by (status)

四、告警体系：Alertmanager

4.1 告警规则

# rules.yml
groups:
  - name: host
    rules:
      - alert: HostHighCpu
        expr: (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)) * 100 > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} CPU 使用率超过 85%"
          description: "当前 {{ $value }}%"

4.2 Alertmanager 通知渠道

route:
  group_by: ["alertname"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: "webhook"

receivers:
  - name: "webhook"
    webhook_configs:
      - url: "http://notify-service:8080/alert"

通知渠道支持邮件、企业微信、钉钉、Webhook，统一接入便于与工单系统联动。

五、Grafana 可视化

docker run -d -p 3000:3000 grafana/grafana

在 Grafana 中添加 Prometheus 数据源后，可以直接导入现成的 Dashboard JSON（如 node_exporter 全家桶模板），或手工配置面板。告警与可视化是两回事：Grafana 面板用于"看"，Alertmanager 用于"响"。

六、体系化的三大告警维度

| 维度 | 示例指标 | 告警阈值思路 | |------|----------|--------------| | 资源 | CPU/内存/磁盘/带宽 | 持续 85%+ 超过 10 分钟 | | 业务 | QPS、错误率、P99 延迟 | 错误率 > 1%，P99 超基线 2 倍 | | 可用性 | 抓取失败、up 指标 | 任何 target 连续 3 次抓取失败 |

# 目标探活告警
up == 0

结语

Prometheus 体系的落地路径很清晰：Exporter 采集 → 指标建模 → PromQL 查询 → Alertmanager 告警 → Grafana 可视化。真正让监控产生价值的不是工具本身，而是"业务可观测"的设计——为每个关键路径定义 SLO 指标，把告警从"机器报警"升级为"用户体验报警"。从今天起，用 Prometheus 替你把每个深夜的告警变成可定位、可响应、可复盘的标准流程。