第1章：Prometheus监控实战——从架构到告警的全链路解析

大家好，我是你们的老朋友。今天咱们聊聊Prometheus。说实话，我在云平台摸爬滚打这么多年，监控系统换了一茬又一茬，但Prometheus是我用得最顺手的一个。它不复杂，但很强大。咱们这一章，就把它的核心脉络捋清楚。

本章核心知识点一览：

  • Prometheus架构设计与部署
  • Exporter配置（Node Exporter / Blackbox Exporter）
  • PromQL查询语言入门
  • Alertmanager告警管理
Prometheus 核心架构图 被监控目标 (Linux / Web / API) Exporter (Node / Blackbox) Prometheus Server 抓取 / 存储 / 查询 Alertmanager 告警路由 / 通知 Grafana / API 可视化与集成

1.1 Prometheus架构：为什么它这么流行？

Prometheus的架构，说白了就是「拉模型」。它主动去各个目标上抓取数据，而不是等数据送上门。这个设计理念，我个人非常喜欢。为什么呢？因为被动接收数据，一旦发送方挂了，你根本不知道是数据没产生还是网络断了。但主动抓取，你心里有数——抓不到就是有问题。

它的核心组件其实不多：

  • Prometheus Server：负责数据抓取、存储和查询。它是整个系统的大脑。
  • Exporter：把各种指标暴露成Prometheus能理解的格式。比如Node Exporter暴露系统指标，Blackbox Exporter做网络探测。
  • Alertmanager：处理告警，去重、分组、发送通知。
  • Grafana：虽然不是Prometheus官方组件，但几乎是标配。用来做可视化仪表盘。

我记得有一次，一个同事问我：「为什么不用Zabbix？」我说：「Zabbix太重了，配置复杂。Prometheus轻量、灵活，尤其适合云原生环境。」你想想看，在Kubernetes里部署Prometheus，简直不要太爽——自动发现、动态配置，省心多了。

1.2 部署Prometheus：三分钟上手

部署Prometheus其实很简单。我习惯用Docker，一条命令搞定：

docker run -d \
  --name prometheus \
  -p 9090:9090 \
  -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
  prom/prometheus

当然，生产环境我建议用二进制部署或者Kubernetes Operator。这里给个简单的配置文件示例：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.100:9100']

小提示： scrape_interval别设太短，5秒以下容易把Prometheus自己搞挂。我一般设15秒，够用了。

1.3 Exporter配置：Node Exporter与Blackbox Exporter

Exporter是Prometheus的「眼睛」。没有它，Prometheus就是个瞎子。咱们重点说两个最常用的。

1.3.1 Node Exporter：系统指标采集

Node Exporter用来采集Linux服务器的CPU、内存、磁盘、网络等指标。部署同样简单：

docker run -d \
  --name node-exporter \
  -p 9100:9100 \
  -v /proc:/host/proc:ro \
  -v /sys:/host/sys:ro \
  -v /:/rootfs:ro \
  prom/node-exporter \
  --path.procfs=/host/proc \
  --path.sysfs=/host/sys \
  --path.rootfs=/rootfs

我曾经遇到过一个坑：默认的Node Exporter会暴露大量指标，有些其实用不上。比如node_disk_io_time_seconds_total这种，如果磁盘很多，指标数量会爆炸。我的建议是：用--collector.disable-defaults关闭不需要的采集器，只开启你关心的。

1.3.2 Blackbox Exporter：网络探测

Blackbox Exporter用来做HTTP、HTTPS、TCP、ICMP等探测。比如你想监控一个网站是否可达：

modules:
  http_2xx:
    prober: http
    http:
      valid_http_versions: ["HTTP/1.1", "HTTP/2"]
      valid_status_codes: [200, 301, 302]
      follow_redirects: true

然后在Prometheus配置里加上：

scrape_configs:
  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://example.com
        - https://google.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 192.168.1.200:9115

注意： Blackbox Exporter的__address__要改成Blackbox Exporter本身的地址，而不是目标地址。这个很多人第一次配置都会搞错，包括我。

1.4 PromQL查询语言：从入门到写复杂表达式

PromQL是Prometheus的查询语言。说实话，刚开始学的时候我觉得它有点反人类，但用习惯了就发现它很优雅。

几个基础概念：

  • 瞬时向量：某个时间点的数据。比如node_cpu_seconds_total
  • 区间向量：一段时间内的数据。比如node_cpu_seconds_total[5m]
  • 标量：单纯的数字，比如100

来个实际例子。你想看CPU使用率：

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

这个表达式什么意思？说白了就是：先算过去5分钟CPU空闲时间的平均变化率，然后用100减去它，得到的就是CPU使用率。嗯，这里要注意rate()函数只能用在Counter类型指标上，Gauge类型用avg_over_time()。

我常用的几个函数：

函数 用途 示例
rate() 计算Counter的每秒增长率 rate(http_requests_total[5m])
irate() 计算瞬时增长率（更敏感） irate(node_network_receive_bytes_total[1m])
avg_over_time() 计算一段时间内的平均值 avg_over_time(node_memory_MemFree_bytes[1h])
topk() 取前N个值 topk(3, node_cpu_seconds_total)

避坑指南： 我曾经在生产环境用irate()做告警，结果因为数据点太少，告警频繁抖动。后来换成rate()加长窗口，问题就解决了。所以，短窗口用irate()，长窗口用rate()，这是经验之谈。

1.5 Alertmanager告警管理：别让告警变成噪音

告警管理是监控的最后一道防线。Alertmanager的核心能力是：去重、分组、抑制、静默。

先看一个告警规则示例：

groups:
  - name: node_alerts
    rules:
      - alert: NodeDown
        expr: up{job="node"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} down"
          description: "{{ $labels.instance }} has been down for more than 1 minute"

然后配置Alertmanager：

route:
  receiver: 'email'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'

receivers:
  - name: 'email'
    email_configs:
      - to: 'admin@example.com'
        from: 'alert@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'alert@example.com'
        auth_password: 'password'

这里有几个关键参数：

  • group_wait：同一组告警等待多久再发送。我一般设30秒，避免短时间大量告警轰炸。
  • group_interval：发送间隔。5分钟比较合理。
  • repeat_interval：重复告警间隔。4小时一次，别太频繁，否则运维会疯的。

个人经验： 告警一定要分级。Critical级别的走电话或PagerDuty，Warning级别的发邮件或钉钉。我曾经见过一个团队把所有告警都设成Critical，结果真正出问题时没人当回事——这就是「狼来了」效应。

好了，这一章的内容就到这里。Prometheus的架构、部署、Exporter配置、PromQL查询、Alertmanager告警管理，咱们都过了一遍。这些东西看着多，其实核心就一句话：主动抓取、灵活查询、智能告警。你只要把这三个环节打通，监控体系就稳了。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →