Prometheus：现代监控系统的全方位解析与实践指南
一、初识 Prometheus
什么是 Prometheus？
Prometheus（普罗米修斯）是一款开源监控系统，以多维数据模型（指标名称和键值对标识）和基于 HTTP 的 Pull 模型为核心特性，支持多维度数据采集与动态查询。其核心组件 Prometheus Server 通过定期拉取目标数据（静态配置或服务发现），并在内存缓存区满时将数据持久化存储。
被监控目标需通过专用 exporter暴露 HTTP 接口供数据拉取，支持静态配置和动态服务发现两种方式管理监控目标。特别地，它能直接将 K8s API Server 作为服务发现系统，实现集群内所有监控对象的动态发现。
Prometheus vs Zabbix
| 特性 | Prometheus | Zabbix |
|---|---|---|
| 架构 | 模块化解耦，组件可选择性配置 | 一体化安装，庞大繁杂 |
| 数据采集 | 多种 exporter 开箱即用，支持多语言 SDK | 通过 agent 脚本采集数据库、日志 |
| 数据传输 | Pull 模式（服务端主动拉取），客户端本地存储数据 | Push 模式（客户端主动推送） |
| 界面体验 | 简洁，需配合 Grafana 获得良好体验 | 界面陈旧，功能集成度高 |
核心特点
- 多维数据模型：基于度量名称和键值对的时间序列数据
- 内置 TSDB 数据库，支持 InfluxDB、OpenTSDB 等远端存储
- 强大的 PromQL 查询语言，支持复杂多维数据查询
- 基于 HTTP 的 Pull 模式数据采集，同时支持 Push Gateway
- 支持服务发现和静态配置两种目标管理方式
- 可作为 Grafana 数据源实现可视化展示
二、监控平台设计思路
六层架构设计
- 用户展示管理层：统一用户管理、集中监控与维护
- 告警事件生成层：实时记录告警、生成分析图表（趋势分析、可视化）
- 告警规则配置层：设置告警规则与阈值（通过布尔值表达式筛选异常）
- 数据提取层：定时采集数据到监控模块
- 数据展示层：生成时序数据曲线图动态展示
- 数据收集层：整合多渠道监控数据（网络、硬件、应用、数据、物理环境）
三、Prometheus 监控体系
1. 系统层监控
- 主机资源：CPU、负载 (Load)、内存 (Memory)、交换分区 (swap)、磁盘 (disk)、I/O、进程 (process)
- 网络监控：网络设备、工作负载、延迟、丢包率
2. 中间件及基础设施监控
- 消息中间件：Kafka、RocketMQ、Redis 等
- WEB 服务容器：Tomcat、WebLogic、JBoss、Apache、PHP、Spring 系列
- 数据库 / 缓存：MySQL、PostgreSQL、MongoDB、Elasticsearch、Redis
Redis 监控要点：
- 服务运行状态
- 所在服务器的系统层监控
- RDB 和 AOF 日志监控
- 哨兵模式下的集群信息日志
3. 应用层监控
用于衡量应用程序代码状态和性能，分为：
- 白盒监控：自省指标（如 cAdvisor）
- 黑盒监控：基于探针的无侵入式监控（如 SNMP）
4. 业务层监控
衡量应用程序业务价值，包括：
- 电商指标：销售量、OPS、DAU 日活、转化率
- 业务接口指标：登录数、注册数、订单量、搜索量、支付量
四、时间序列数据
数据来源
Prometheus 通过 HTTP 请求从配置的网络端点周期性获取指标数据。对于不支持 HTTP 响应的被监控对象，需通过 prometheus-exporter 进行数据收集和标准化处理，转换为 Prometheus 可识别的格式。
数据收集方式
基于白盒监控，Prometheus 支持三种数据 "抓取 (Scrape)" 途径：
- Exporters：运行在被监控端，周期性抓取并转换数据，等待拉取
- Instrumentation：被监控对象内置数据收集功能，直接供拉取
- Push Gateway：用于短周期（5-10s）数据收集
Pull 模型优势
Prometheus 采用主动拉取数据的 Pull 模型，相比 Push 模型具有：
- 集中控制：配置集中在 Server 端，包括指标和采集速率
- 专注聚合数据：适合收集预先聚合的数据，而非事件驱动存储
- 明确的目标标识：通过 targets 配置（如
targets:['localhost:9090']）
五、生态系统组件
1. Prometheus Server
核心组件，负责收集和存储时间序列数据，包含三个部分：
- Retrival：从活跃目标主机抓取监控指标
- Storage：将采集数据存储到磁盘（默认保留 15 天，可配置）
- PromQL：提供查询语言模块
2. Client Library
为应用程序提供原生 Instrumentation 功能的开发库，便于构建内置测量系统。
3. Push Gateway
作为数据中转站，接收无法被 Pull 的节点推送的数据，供 Prometheus Server 拉取，特别适合短期任务的数据收集。
4. Exporters
用于将不支持 Instrumentation 的应用程序或服务指标暴露给 Prometheus Server，是数据采集的主要来源之一。
5. Alertmanager
独立的告警模块，接收 Prometheus Server 的告警通知后，进行去重、分组，并路由到指定接收方（电子邮件、钉钉、企业微信等）。
6. Service Discovery
服务发现组件，支持文件、DNS、Consul、Kubernetes 等多种发现机制，动态获取待监控目标列表。
7. Grafana
跨平台开源可视化工具，支持 Prometheus 作为数据源，提供丰富的仪表盘插件，实现监控数据的图形化展示。
数据流向
- Prometheus Server 从 jobs、exporters 拉取数据，或从 Pushgateway、其他 Server 接收数据
- 存储收集的指标，运行告警规则，生成新时间序列或推送警报到 Alertmanager
- Alertmanager 处理警报并发送给接收方
- 通过图形界面可视化展示采集数据
六、工作原理
工作模式
- 基于服务发现或静态配置获取监控目标，通过 exporter 采集指标
- 内置文件型 TSDB 存储数据，支持 PromQL 查询和告警规则配置
- 短期作业通过 Pushgateway 推送数据，由 Server 端抓取
工作流程
- Prometheus Server 通过 Pull 方式从目标拉取数据，或从 Pushgateway 拉取推送数据
- 将采集数据存储到本地 TSDB
- 根据报警规则触发报警，发送到 Alertmanager
- Alertmanager 将报警发送到指定接收渠道
- 通过 Web UI（PromQL）或 Grafana 展示监控数据
局限性
- 不适合存储事件及日志，更擅长趋势性监控而非精准数据
- 本地存储设计用于短期数据（默认 15 天），长期存储需借助 InfluxDB 等远端系统
- 集群机制成熟度不高，可通过 Thanos 实现高可用及联邦集群
七、实践总结
数据收集方式
- Exporters：收集节点信息并格式化为 Prometheus 可识别格式
- Instrumentation：收集内置指标暴露器的信息
- Pushgateway：收集短周期数据
防止告警轰炸
通过 Alertmanager 实现告警收敛、静默、去重功能，避免告警信息泛滥。
监控内容与对应 Exporter
| 监控级别 | 监控内容 | 推荐 Exporter |
|---|---|---|
| 网络 | 协议（HTTP、DNS 等）、硬件（路由器等） | BlockBox Exporter、SNMP Exporter |
| 主机 | 资源用量 | Node Exporter |
| 容器 | 资源用量 | cAdvisor |
| 应用 | 延迟、错误、QPS 等 | Prometheus Client |
| 中间件 | 资源用量、服务状态 | Prometheus Client |
| 编排工具 | 集群资源、调度 | Kubernetes Components |
常见时序数据库
| 项目 | 官网 |
|---|---|
| InfluxDB | InfluxData |
| RRDtool | RRDtool |
| Graphite | Graphite |
| OpenTSDB | OpenTSDB |
| Prometheus | Prometheus |
八、安装部署指南
版本选择
根据 Kubernetes 版本选择兼容的 kube-prometheus stack 版本：
| kube-prometheus stack | Kubernetes 版本支持 |
|---|---|
| release-0.11 | 1.23、1.24 |
| release-0.12 | 1.24、1.25 |
| release-0.13 | 1.26、1.27、1.28 |
| release-0.14 | 1.26-1.31 |
| main | 1.27-1.31 |
部署步骤
# 1. 下载对应版本的kube-prometheus git clone -b release-0.14 https://github.com/prometheus-operator/kube-prometheus.git # 2. 修改服务类型为NodePort cd kube-prometheus/manifests vim prometheus-service.yaml vim grafana-service.yaml vim alertmanager-service.yaml # 在每个文件的spec中添加：type: NodePort # 3. 部署 kubectl create -f ./setup kubectl create -f ./ # 4. 查看部署状态 kubectl -n monitoring get pod kubectl -n monitoring get svc # 5. 删除网络策略（如需外部访问） kubectl delete -f manifests/prometheus-networkPolicy.yaml kubectl delete -f manifests/grafana-networkPolicy.yaml kubectl delete -f manifests/alertmanager-networkPolicy.yaml
