Prometheus 监控告警体系：从主节点到多 Exporter 一站式部署

Sat, 15 Mar 2025 00:00:00 +0800

容器时代，监控从"对单台机器"变成了"对一组动态拉起的服务"。Prometheus（普罗米修斯）凭借 pull 模型、时序数据库、丰富的 Exporter 生态，几乎成了云原生监控的事实标准。这篇文章把零散在多个笔记里的部署、配置、关键指标、踩坑细节，整理成"从主节点拉起→多 Exporter 接入→告警落地"的一条完整路径。

阅读对象：需要在中小规模环境（几台到几十台主机/容器）做统一监控的开发者、运维同学
覆盖范围：Prometheus 主节点（v3.x 时代）、node-exporter / mysqld-exporter / cAdvisor / alertmanager 全套部署、prometheus.yml 配置、MySQL 关键指标解读、Grafana 仪表盘推荐、配置热加载

一、为什么是 Prometheus

在引入 Prometheus 之前，团队通常在几种监控方案之间反复横跳：

Zabbix：传统 SNMP/Agent 模式，重型、关系型数据库后端，容器场景适配差
Nagios：古老、以被动检查为主，配置繁琐
云厂商自带监控：阿里云云监控、AWS CloudWatch 等，绑定厂商、跨云复杂
自研脚本 + 定时任务：简单但难以横向扩展、缺少时序聚合

Prometheus 的优势恰好打在云原生的痛点上：

特性	价值
Pull 模型	服务主动注册，部署新节点只要改主节点 `prometheus.yml`
时序数据库（TSDB）	自带压缩、聚合、PromQL 查询语言
多维标签	`node_cpu_seconds_total{mode="idle", instance="web-01"}` 这种查询极简
生态丰富	官方/社区 Exporter 覆盖 Linux、Windows、MySQL、Redis、K8s、Docker 等
告警分离	Prometheus 只产生告警状态，alertmanager 负责去重/路由/通知
与 Grafana 深度集成	一键导入仪表盘（Dashboard ID）

When to use：当你要监控的对象是"会动态拉起/销毁的服务"，或者主机数量超过两位数且需要统一的指标查询能力，Prometheus 几乎是首选。它也已经成为 Kubernetes 监控（kube-prometheus-stack）的默认后端。

二、架构总览

整套体系由"主节点"和"应用节点"两类组成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


主节点（监控中心）
 ├── Prometheus :9090 # 拉取并存储指标
 ├── AlertManager :9093 # 告警去重/路由/通知
 ├── Grafana :3000 # 可视化（消费 Prometheus 数据源）
 └── webhook-adapter :80 # 适配企业微信/钉钉（可选）

应用节点（被监控对象）
 ├── node-exporter :9100 # Linux 主机硬件/OS 指标
 ├── cAdvisor :8080 # 容器资源指标
 └── mysqld-exporter :9104 # MySQL 指标

架构选择：如果是单机小规模（< 5 台），所有主节点组件跑在同一台机器即可。如果规模稍大（10+ 节点），主节点独立部署更便于容灾。Prometheus 本身不支持集群，但可以通过 Thanos / Cortex / Mimir 等上层方案扩展，本文不展开。

三、镜像清单

本批次部署涉及的镜像如下（版本号按本批次落地时锁定）：

组件	镜像	端口
Prometheus	`prom/prometheus:v3.4.1`	9090
alertmanager	`prom/alertmanager:latest`	9093
node-exporter	`prom/node-exporter:v1.9.1`	9100
cAdvisor	`gcr.nju.edu.cn/cadvisor/cadvisor:v0.47.2`	8080
mysqld-exporter	`prom/mysqld-exporter`	9104
Grafana	`grafana/grafana:10.0.1`	3000
webhook-adapter	`guyongquan/webhook-adapter:latest`	80

镜像源说明：cAdvisor 原镜像托管在 gcr.io，国内直连困难，建议用 gcr.nju.edu.cn/cadvisor/cadvisor（南京大学开源镜像）做中转。

四、主节点部署

4.1 Prometheus（核心）

准备配置目录：

1
2
3


mkdir -p /home/docker/prometheus
cd /home/docker/prometheus
touch prometheus.yml

核心 prometheus.yml（合并多个 job 后的生产配置）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


global:
 scrape_interval: 15s  # 每 15s 拉取一次
 evaluation_interval: 15s  # 规则评估间隔

alerting:
 alertmanagers:
 - static_configs:
 - targets: ["{{ALERTMANAGER_HOST}}:9093"]

rule_files:
 - /etc/prometheus/rules/*.yml

scrape_configs:
 # 监控 Prometheus 自身
 - job_name: "prometheus"
 static_configs:
 - targets: ["{{PROM_HOST}}:9090"]

 # Linux 主机（多节点）
 - job_name: "node"
 static_configs:
 - targets: ["{{NODE_1}}:9100"]
 labels:
 nodeName: "dev-01"
 instance: "dev-01"
 - targets: ["{{NODE_2}}:9100"]
 labels:
 nodeName: "prod-01"
 instance: "prod-01"

 # 容器
 - job_name: "cadvisor"
 static_configs:
 - targets: ["{{NODE_1}}:8080"]
 labels:
 instance: "dev-01"

 # MySQL
 - job_name: "mysql_exporter"
 static_configs:
 - targets: ["{{NODE_1}}:9104"]
 labels:
 nodeName: "mysql-dev"
 instance: "mysql-dev"

配置铁律：prometheus.yml 文件内容及注释强烈建议不要使用中文，否则因编码格式不一致会导致 Prometheus 重启失败。

启动 Prometheus（带热加载 + 管理 API）：

1
2
3
4
5
6


docker run --name=prometheus -d -p 9090:9090 --restart=always \
 -v /home/docker/prometheus:/etc/prometheus \
 prom/prometheus:v3.4.1 \
 --config.file=/etc/prometheus/prometheus.yml \
 --web.enable-lifecycle \
 --web.enable-admin-api

修改配置后无需重启容器，热更新即可：

1

curl -X POST http://localhost:9090/-/reload

端口规划建议：主节点容器使用默认 9090/9093/3000，应用节点对外暴露用 3000+ 偏移（如 3101/3080/3104）避免冲突。

4.2 AlertManager（告警路由）

1
2


mkdir -p /home/docker/alertmanager
vim /home/docker/alertmanager/alertmanager.yml

最小可用 alertmanager.yml（路由到 webhook）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


global:
 resolve_timeout: 5m

route:
 group_by: ['alertname']
 group_wait: 10s
 group_interval: 10s
 repeat_interval: 1h
 receiver: 'webhook'

receivers:
 - name: 'webhook'
 webhook_configs:
 - url: 'http://{{WEBHOOK_ADAPTER_HOST}}/send'
 send_resolved: true

启动：

1
2
3
4
5
6


docker run -d --restart=always \
 --name=alertmanager \
 -p 9093:9093 \
 -v /home/docker/alertmanager:/etc/alertmanager \
 -v /etc/localtime:/etc/localtime:ro \
 prom/alertmanager:latest

4.3 Grafana（可视化）

Grafana 不是监控体系的"必要组件"，但 99% 的生产环境都会装它。/etc/grafana/grafana.ini 改个匿名访问，UI 就能公开给团队看：

1
2
3
4
5
6


#################################### Anonymous Auth ######################
[auth.anonymous]
enabled = true
org_name = Main Org.
org_role = Viewer
hide_version = true

启动：

1
2
3
4
5
6


mkdir -p /home/docker/grafana/conf
docker run -d --restart=always --name=grafana \
 -e TZ=Asia/Shanghai -e LANG=zh_CN.UTF-8 \
 -p 3000:3000 \
 -v /home/docker/grafana/conf/grafana.ini:/etc/grafana/grafana.ini \
 grafana/grafana:10.0.1

配置数据源：Configuration → Data Sources → Add data source → Prometheus，URL 填 http://{{PROM_HOST}}:9090，保存即可。

推荐仪表盘（到 https://grafana.com/grafana/dashboards 搜索 ID）：

监控对象	推荐 Dashboard ID
Linux 主机	`11074`（Node Exporter Full）
Windows 主机	`10467`
MySQL	`7362`（MySQL Overview）
Docker 容器	`10619`（cAdvisor）

导入流程：Grafana → Dashboards → New → Import → 输入 ID → 选数据源 → 完成。约 30 秒内就能看到主机/容器的 CPU、内存、磁盘、网络等十几张图。

五、应用节点 Exporter 部署

5.1 node-exporter（Linux 主机）

1
2


docker run -d --name node-exporter --restart=always -p 9100:9100 \
 prom/node-exporter:v1.9.1

访问 http://{{HOST}}:9100/metrics 能看到原始指标。node-exporter 默认暴露 1000+ 指标，覆盖 CPU、内存、磁盘、网络、文件系统、内核参数等。

5.2 cAdvisor（容器资源）

cAdvisor 需要访问宿主机文件系统以读取容器信息，所以挂载点比较"重"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d --name cadvisor --restart=always \
 --privileged=true \
 --device=/dev/kmsg \
 -p 8080:8080 \
 -v /:/rootfs:ro \
 -v /var/run:/var/run:ro \
 -v /sys:/sys:ro \
 -v /var/lib/docker/:/var/lib/docker:ro \
 -v /dev/disk/:/dev/disk/:ro \
 gcr.nju.edu.cn/cadvisor/cadvisor:v0.47.2

访问 http://{{HOST}}:8080/containers/ 是个 HTML 索引，Web UI 简单但够用——更深度使用走 Grafana。

5.3 mysqld-exporter（MySQL 指标）

准备 MySQL 客户端配置（不要把明文密码写进 docker run 命令）：

1
2
3
4
5
6
7
8


mkdir -p /home/docker/mysqld-exporter
cat << "EOF" > /home/docker/mysqld-exporter/.my.cnf
[client]
host={{MYSQL_HOST}}
port={{MYSQL_PORT}}
user={{MYSQL_USER}}
password={{REDACTED}}
EOF

启动：

1
2
3
4
5


docker run -d --restart=always \
 --name mysqld-exporter \
 -p 9104:9104 \
 -v /home/docker/mysqld-exporter/.my.cnf:/.my.cnf \
 prom/mysqld-exporter

安全建议：为 exporter 单独建一个只读账号，权限仅 SELECT、PROCESS、REPLICATION CLIENT，避免使用 root 或业务账号。

关键 MySQL 指标解读

监控不是"装上 exporter 就完事"，要看得懂指标才能发现真问题。MySQL 常见的指标分四类：

1. 可用性

指标	含义
`mysql_up`	MySQL 实例是否停机（1=正常，0=挂）
`mysql_global_status_uptime`	数据库运行时长（秒），可配置"运行少于半小时"告警，揪出被频繁重启的实例

2. 连接

指标	含义
`mysql_global_status_threads_connected`	当前已连接线程数
`mysql_global_status_threads_running`	当前运行中线程数（正在执行 SQL）
`mysql_global_status_max_used_connections`	历史最大连接记录
`mysql_global_variables_max_connections`	配置最大连接数（超过则拒绝新连接）
`mysql_global_status_aborted_connects`	异常中断的连接（尝试连接阶段失败）
`mysql_global_status_aborted_clients`	异常中断的连接（超时/被动断）

3. 查询

指标	含义
`mysql_global_status_queries`	当前 QPS（每 15s 增量）
`mysql_global_status_slow_queries`	慢查询累计数（配合 `rate()` 看增量）

4. 流量与文件

指标	含义
`mysql_global_status_bytes_received`	入站流量
`mysql_global_status_bytes_sent`	出站流量
`mysql_global_status_open_files`	当前打开的文件数
`mysql_global_variables_open_files_limit`	允许打开的文件上限

关键 PromQL 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# MySQL 实例是否在线
mysql_up == 0

# 当前 QPS
rate(mysql_global_status_queries[1m])

# 慢查询增长速率
rate(mysql_global_status_slow_queries[5m])

# 连接数使用率
mysql_global_status_threads_connected / mysql_global_variables_max_connections

六、配置热加载 SOP

修改 prometheus.yml 后的标准流程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 编辑配置
vim /home/docker/prometheus/prometheus.yml

# 2. 语法检查（promtool 在镜像内）
docker exec prometheus promtool check config /etc/prometheus/prometheus.yml

# 3. 热加载
curl -X POST http://{{PROM_HOST}}:9090/-/reload

# 4. 验证（UI → Status → Targets）
# 所有 targets 状态应为 UP，新加的 job 已出现

不要直接 docker restart prometheus：重启会触发告警状态重置，正在持续中的告警会"消失后再生"，造成误报。热加载是首选。

七、踩坑清单

prometheus.yml 中文注释——YAML 解析失败，Prometheus 启动后立即退出，且日志里只看到"no such file"类错误，很难定位
cAdvisor 镜像拉取失败——gcr.io 国内访问困难，统一改用 gcr.nju.edu.cn/cadvisor/cadvisor 或其他国内镜像
mysqld-exporter 连接失败——MySQL 默认监听 127.0.0.1，远程 exporter 访问会失败；要么改 bind-address=0.0.0.0，要么用 host 网络模式
Grafana 改完 grafana.ini 不生效——容器内只读，必须先 docker cp 出配置、修改后挂载进去
Prometheus 内存爆炸——scrape_interval 设太短（5s 以下）、target 太多（> 1000）会让内存快速膨胀；按需调整而非全局最小化
告警风暴——一个 root cause 触发几十条 alert。配置 group_by: ['alertname'] + group_wait: 30s 做去重

八、2024+ 视角补充

本文写于 2025-03，2025-2026 期间 Prometheus 关键演进：

Prometheus 3.x（2024-11 GA）：WAL 压缩、UTF-8 标签、远程写入 v2（性能 5x 提升）、原生 OpenTelemetry 兼容——3.0 是 Prometheus 自 2.0 以来最大一次重构
Prometheus Agent 模式（3.x GA）：纯抓取不存储，远程写入到 Thanos / Mimir / Cortex——Kubernetes DaemonSet 部署首选
VictoriaMetrics 1.99+ LTS / 2.0：与 Prometheus 兼容，存储压缩 10x、查询快 5-10x——大规模监控默认推荐
Grafana Mimir 2.x：Cortex 演进，水平扩展 + 多租户——50+ 集群首选
OpenTelemetry Collector 0.100+：统一指标 / 日志 / 追踪采集——Prometheus exporter 与 OTel 并存，但 OTel 是未来
kube-prometheus-stack 0.78+：Helm Chart 整合 Prometheus / AlertManager / Grafana / node-exporter，K8s 监控事实标准
告警疲劳应对：2024+ 流行 Mimir 告警去重 + AI 降噪（如 Grafana Sift、Keep）

实战建议（2025-2026 视角）：

单机 / 小规模（< 10 节点）→ Prometheus 3.x 仍 OK
中等规模（10-100 节点）→ VictoriaMetrics 性价比高
大规模 / 多租户（> 100 节点）→ Grafana Mimir / Cortex
K8s → kube-prometheus-stack Helm Chart 一键搞定
新项目：OpenTelemetry Collector 替代纯 Prometheus exporter——避免后续迁移

九、参考资料

Prometheus 官方文档：https://prometheus.io/docs/
Prometheus 3.0 发布说明：https://prometheus.io/blog/2024/11/14/prometheus-3-0/
Grafana Dashboard 仓库：https://grafana.com/grafana/dashboards
cAdvisor GitHub：https://github.com/google/cadvisor
mysqld-exporter GitHub：https://github.com/prometheus/mysqld_exporter
alertmanager 配置：https://prometheus.io/docs/alerting/latest/configuration/
VictoriaMetrics：victoriametrics.com
Grafana Mimir：grafana.com/oss/mimir/
OpenTelemetry：opentelemetry.io

下一步

想做"日志"那一层？→ 看 Loki + Promtail 日志架构一文
想做"链路追踪"？→ 接入 Tempo 或 Jaeger，让 Prometheus + Grafana 体系扩展到 trace
想"少装点东西"？→ HertzBeat 轻量监控告警把监控 + 告警 + 可视化打包到一容器里

Alertmanager on Liangweidong's blog