中间件全景 · 第10节 · 监控中间件：Zabbix 与 Prometheus

监控中间件：Zabbix 与 Prometheus

Monitoring · Zabbix / Nagios / Prometheus

Zabbix 就是机房的保安——服务器 CPU 飙了、磁盘满了、进程死了，它第一时间给你发邮件。没有监控，线上挂了你都是最后一个知道的。Zabbix 是老牌全能型监控，Prometheus 是云原生时代的新王。

9.1 Zabbix：企业级开源监控

论Zabbix 的架构

企业级开源监控解决方案，监控服务器/网络/应用/数据库，告警+可视化+自动发现。架构分四块：

Zabbix Server：大脑，收集和处理监控数据。

数据库（MySQL/PostgreSQL）：存配置和历史数据。

Zabbix Agent：装在被监控机器上，跑命令采集指标。

Web 前端：浏览器里看图表、配告警。

9.2 监控核心概念

Zabbix 术语表
术语	解释
主机 Host	被监控的一台机器
主机组	把主机分组管理（如"数据库组""Web组"）
监控项 Item	具体监控什么（CPU 使用率、磁盘剩余），有 key 和更新间隔
触发器 Trigger	阈值告警条件（如 CPU>90% 持续 5 分钟就告警）
事件 Event	触发器被触发时产生的告警事件
动作 Action	事件触发后干什么（发邮件/发短信/执行远程命令）
模板 Template	监控项+触发器+图形的集合，复用

9.3 完整案例：监控 Linux 服务器

以监控一台 Linux 服务器的 CPU/内存/磁盘为例：

# 1. 被监控机器装 Zabbix Agent
sudo apt install -y zabbix-agent

# 2. /etc/zabbix/zabbix_agentd.conf 配置
Server=192.168.1.10          # Zabbix Server 的 IP
ServerActive=192.168.1.10
Hostname=web-server-01

sudo systemctl restart zabbix-agent

# 3. Zabbix Web 界面：Configuration → Hosts → Create Host
#    填主机名、IP、链接模板 "Template Linux by Zabbix agent"

# 4. 模板自带监控项：CPU、内存、磁盘、网络
#    自带触发器：CPU>90%、磁盘>85% 等

# 5. 配动作：告警发邮件
#    Configuration → Actions → Create Action
#    Conditions: Trigger severity >= Warning
#    Operations: Send email to admin@example.com

# 告警邮件收到： # PROBLEM: CPU utilization > 90% on web-server-01 # Current value: 95.3% # Duration: 5 minutes

9.4 Nagios：老牌主动监控

Nagios 是更早的开源监控系统，插件机制丰富，主动监控。但它的数据可视化和现代功能不如 Zabbix，现在新项目大多选 Zabbix 或 Prometheus。

9.5 Prometheus：云原生监控事实标准

论Prometheus 的脾气

CNCF 毕业项目，时序数据库 + 拉模型 + PromQL，云原生监控事实标准。和 Zabbix 的"推模型"不同，Prometheus 是拉模型：Prometheus 主动去每个目标（target）拉指标。K8s 场景下天然适配——Pod 起灭自动发现。

核心组件：Prometheus Server（存储+拉取）+ Exporter（采集器，如 Node Exporter 采主机指标）+ Grafana（画图）+ AlertManager（告警）。PromQL 是它的查询语言，功能强大但学习曲线陡。

Zabbix vs Prometheus 选型
对比点	Zabbix	Prometheus
模型	推模型（Agent 推数据）	拉模型（Server 主动拉）
数据存储	MySQL/PG + 时序	自带时序数据库
查询语言	简单（key）	PromQL（强大但难）
K8s 支持	一般	原生支持，自动发现
可视化	自带	Grafana（更强大）
适合	传统机房、服务器监控	云原生、微服务、K8s

9.6 Prometheus 实操：配一次就懂的最小闭环

引子：光看概念对比还是隔靴搔痒。Prometheus 怎么真的采到一台机器的指标？三步走：装 Node Exporter 采指标 → Prometheus 配置去拉 → Grafana 画图。下面是最小可跑的一套。

prometheus.yml：告诉 Prometheus 去哪拉

# prometheus.yml —— 核心就两段：全局 + 抓取任务
global:
  scrape_interval: 15s          # 每 15 秒拉一次指标

scrape_configs:
  - job_name: 'linux-servers'
    static_configs:
      - targets: ['192.168.1.10:9100', '192.168.1.11:9100']
        # 9100 是 Node Exporter 的默认端口，上面跑着主机指标采集器

$ docker run -d --name prometheus -p 9090:9090 \ -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus # 浏览器开 http://localhost:9090/targets 能看到两台 UP，就说明拉到了

PromQL：Prometheus 的查询语言（三个最常用的）

# 1. 瞬间值：当前 CPU 使用率（100 - 空闲）
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# 2. 机器内存剩余百分比
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100

# 3. 最近 5 分钟 HTTP 请求每秒次数（QPS）
rate(http_requests_total[5m])

告警规则：CPU 连续 5 分钟超 90% 就报警

# alert.rules.yml —— 配好后 Prometheus 推给 AlertManager，由它发邮件/钉钉
groups:
  - name: host-alerts
    rules:
      - alert: HighCPU
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 5m                 # 持续 5 分钟超阈值才告警，避免抖动
        labels:
          severity: warning
        annotations:
          summary: "CPU 过高：{{ $labels.instance }}"

Prometheus 的两个认知误区

① Prometheus 不是为长期海量存储设计的。它存本地时序库，默认就留 15 天，要长期存历史数据得上远端 TSDB（如 Thanos、VictoriaMetrics）。② 拉模型不适合跨机房/外网。Prometheus 要能直接连到每个 target，如果 target 在它够不着的网络，就得用 Pushgateway 或 exporter 反向隧道。

9.7 分布式追踪：SkyWalking 与 Jaeger（一个请求走了哪）

引子：监控告诉你"这台机器 CPU 95%、那个服务响应 3 秒"，但用户说"下单页面转圈"时，这个请求从 Nginx → 订单服务 → 库存服务 → 数据库，到底卡在哪一跳？日志和指标都答不上来，这就是分布式追踪要干的：给每个请求发一个全局 TraceID，把它经过的每一跳串成一张瀑布图。

请求 TraceID=abc123

入口生成全局 ID

→

订单服务 45ms

把 ID 继续传

→

库存服务 1800ms

罪魁祸首在这一跳

→

数据库 30ms

很快

两个主流开源方案对比
方案	特点	适合
SkyWalking（Apache）	国产开源，Java 生态强，无侵入探针（javaagent），自带 UI 和告警，国内用得多	Java 微服务、国内团队
Jaeger（CNCF）	Uber 开源，云原生标准，语言无关，和 OpenTelemetry 无缝对接	多语言、K8s、云原生

Java 应用接 SkyWalking，一行启动参数就行（无侵入）

# 不用改一行代码，加个 javaagent 就自动埋点
java -javaagent:/path/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=192.168.1.20:11800 \
     -jar order-service.jar

# 打开 SkyWalking UI（默认 8080），按 TraceID 搜
# 一个请求经过哪些服务、每一跳耗时多少，瀑布图一目了然

一句话：日志查"发生了什么"，指标查"现在正不正常"，分布式追踪查"这个慢请求到底卡在哪一跳"。三者是现代可观测性（Observability）的铁三角，缺一不可。

记

第九章小结

① Zabbix = 机房保安，架构 Server+DB+Agent+Web，模板化监控 Linux/数据库。

② Prometheus = 云原生监控王，拉模型 + PromQL + Grafana 画图 + AlertManager 告警。

③ 分布式追踪（SkyWalking/Jaeger）给请求发 TraceID，画出"慢在哪一跳"的瀑布图，和日志、指标合称可观测性铁三角。

④ 传统机房选 Zabbix，K8s/微服务选 Prometheus + Grafana。

← 返回总览中间件全景总览下一节：中间件选型决策树 →