K8S 中部署 Prometheus 监控体系：从原理到实战

一、Prometheus

Prometheus 是一个开源的监控 + 告警 + 时序数据库组合，采用多维数据模型和 HTTP Pull 模式采集数据。Kubernetes 的流行直接带火了它------Prometheus 能直接把 K8S 的 API Server 作为服务发现系统，动态发现和监控集群中所有对象。

Prometheus vs Zabbix

维度	Prometheus	Zabbix
架构风格	模块化解耦，告警/代理可选配	一套安装全包含，庞大繁杂
数据采集	Pull 模式，客户端本地存数据	Push 模式，客户端只做上报
监控客户端	Exporter 开箱即用 + 多语言 SDK	Agent + 自定义脚本读取日志/数据库
自定义业务监控	各语言官方 SDK，直接埋点	需先把数据存入日志/数据库再采集
界面	极简（只算配置平台）	功能全但陈旧
可视化	都需要搭配 Grafana	都需要搭配 Grafana

一句话总结：Prometheus 更灵活、更适合云原生环境；Zabbix 更传统、更适合物理机/传统架构。

Prometheus 核心特点

• 多维数据模型：指标名称 + 键值对标识的时间序列
• 内置 TSDB：本地存储，无需依赖外部数据库
• PromQL：灵活的查询语言，支持多维数据复杂查询
• Pull 模式：Server 主动拉取，降低耦合
• 也支持 Push：通过 Push Gateway 中转
• 服务发现：静态配置 + 动态发现（K8S/Consul/DNS 等）
• Grafana 集成：作为数据源直接接入

二、监控平台设计思路

一套完整的监控平台可以拆成 6 层，自下而上：

plaintext

┌─────────────────────────────────────────┐
│  第六层：用户展示管理层  统一管理、集中监控  │
├─────────────────────────────────────────┤
│  第五层：告警事件生成层  实时记录、趋势分析  │
├─────────────────────────────────────────┤
│  第四层：告警规则配置层  布尔表达式、阈值    │
├─────────────────────────────────────────┤
│  第三层：数据提取层      定时采集到监控模块  │
├─────────────────────────────────────────┤
│  第二层：数据展示层      曲线图、动态展示    │
├─────────────────────────────────────────┤
│  第一层：数据收集层      网络/硬件/应用/数据 │
└─────────────────────────────────────────┘

核心逻辑：收集数据 → 提取存储 → 判断告警 → 生成事件 → 展示给用户

告警的本质就是布尔值表达式------表达式成立=异常=告警，不成立=健康。

三、Prometheus 监控什么

按层级从底到上，监控内容越来越接近业务价值：

系统层（基础设施）

CPU、内存、Swap、磁盘 I/O、网络延迟、丢包率等 → node-exporter

中间件层

• 消息队列：Kafka、RocketMQ
• Web 容器：Tomcat、Nginx、Spring 系列
• 数据库：MySQL、Redis、MongoDB、ES → 各专用 Exporter

以 Redis 为例，监控内容：

• Redis 服务状态
• 所在服务器系统层指标
• RDB/AOF 持久化状态
• 哨兵模式下的集群信息日志

应用层

衡量代码状态和性能，分两种方式：

表格

类型	原理	典型工具
白盒监控	应用自省，暴露指标等待采集	cAdvisor、Prometheus Client
黑盒监控	外部探针，不侵入应用	Blackbox Exporter、SNMP

业务层

衡量应用价值：DAU、订单量、转化率、支付量等业务接口指标。

各层级对应 Exporter 速查

表格

监控对象	用什么
网络（HTTP/DNS/TCP/ICMP）	Blackbox Exporter
网络硬件（路由器/交换机）	SNMP Exporter
主机资源	Node Exporter
容器资源	cAdvisor
应用（延迟/错误/QPS）	代码集成 Prometheus Client
中间件	专用 Exporter
K8S 集群	Kubernetes Components

四、Prometheus 数据采集三种方式

1. Exporters（指标暴露器）

最常用的方式。部署在被监控端，收集数据并转化为 Prometheus 兼容格式，暴露 HTTP 接口等 Prometheus 来 Pull。

自己不推送，只等采集。

2. Instrumentation（应用内置指标）

被监控对象自身就有数据收集和暴露功能（如 K8S 组件的 /metrics 接口），Prometheus 直接去拉就行，不需要额外装 Exporter。

3. Push Gateway（短周期数据中转）

某些短期任务生命周期太短（5s~10s），Prometheus 来 Pull 的时候任务可能已经结束了。这类场景用 Push：任务主动推数据到 Push Gateway，Prometheus 再从 Gateway 统一拉取。

💡 Push Gateway 是一个中转站，不是存储系统，不要把长期数据都往里推。

五、Prometheus 生态组件

plaintext

                    ┌─────────────┐
                    │  Grafana    │ ← 可视化
                    └──────┬──────┘
                           │ PromQL 查询
┌──────────┐  Pull   ┌─────┴──────────┐  Push  ┌──────────────┐
│ Exporter │◄────────│ Prometheus     │◄───────│ Push Gateway │
│          │         │ Server         │        └──────────────┘
│          │         │ ┌────────────┐ │
└──────────┘         │ │Retrieval   │ │  抓取数据
┌──────────┐  Pull   │ ├────────────┤ │
│ K8S API  │◄────────│ │TSDB Storage│ │  本地存储(默认15天)
│ Server   │         │ ├────────────┤ │
└──────────┘         │ │PromQL      │ │  查询引擎
                     │ └────────────┘ │
                     └───────┬────────┘
                             │ 告警
                    ┌────────┴─────────┐
                    │  Alertmanager    │ ← 告警通知
                    │  去重/分组/路由    │
                    └──────────────────┘

核心组件说明

表格

组件	职责
Prometheus Server	核心：抓取数据(Retrieval) + 存储数据(TSDB) + 查询数据(PromQL)
Exporters	暴露被监控端数据，转化为兼容格式
Push Gateway	接收短周期推送数据，等 Server 来拉
Alertmanager	接收告警 → 去重/分组/路由/静默 → 发通知（邮件/钉钉/企微）
Service Discovery	动态发现监控目标（K8S/Consul/DNS）
Grafana	数据可视化展示

为什么告警要分两层？

Prometheus Server 只负责生成告警指示 （计算规则是否触发），Alertmanager 负责具体告警行为（去重、分组、路由、发送）。

这样设计的好处：Alertmanager 支持静默、去重、抑制，可以有效防止告警轰炸。

六、Prometheus 局限性

面试也可能会问，提前了解：

1. 不适合存事件和日志：它是指标监控系统，展示趋势而非精准数据
2. 本地存储只保存短期数据：默认 15 天，不支持大量历史数据长期存储
3. 集群机制成熟度不高：可基于 Thanos 实现高可用和联邦集群

长期存储方案：对接 InfluxDB、OpenTSDB 等远端存储。

七、K8S 部署实战：kube-prometheus

版本选择

K8S 版本和 kube-prometheus 版本必须匹配：

表格

kube-prometheus	K8S 1.26	K8S 1.27	K8S 1.28	K8S 1.29	K8S 1.30	K8S 1.31
release-0.13	✔	✔	✔	✗	✗	✗
release-0.14	✔	✔	✔	✔	✔	✔

下载地址：https://github.com/prometheus-operator/kube-prometheus

部署步骤

① 修改 Service 为 NodePort（外部可访问）

三个文件都要改，加上 type: NodePort：

yaml

# manifests/prometheus-service.yaml
# manifests/grafana-service.yaml
# manifests/alertmanager-service.yaml
spec:
  type: NodePort

② 提交部署

bash

# 先部署 operator
kubectl create -f ./setup
# 再部署所有监控组件
kubectl create -f ./

③ 删除网络策略（允许外部访问）

bash

kubectl delete -f manifests/prometheus-networkPolicy.yaml
kubectl delete -f manifests/grafana-networkPolicy.yaml
kubectl delete -f manifests/alertmanager-networkPolicy.yaml

⚠️ 不删这三个 NetworkPolicy，集群外部访问不了 Prometheus/Grafana/Alertmanager。

④ 验证 Pod

bash

kubectl -n monitoring get pod

正常运行的 Pod 列表：

表格

Pod	说明
prometheus-k8s-0/1	Prometheus Server（2副本高可用）
alertmanager-main-0/1/2	Alertmanager（3副本高可用）
grafana-xxx	Grafana 可视化
node-exporter-xxx	每个节点一个，采集主机指标
kube-state-metrics-xxx	K8S 资源状态指标
blackbox-exporter-xxx	黑盒探针
prometheus-adapter-xxx	资源指标适配器（HPA 用）
prometheus-operator-xxx	Prometheus Operator 控制器

⑤ 查看 Service 端口

bash

kubectl -n monitoring get svc

表格

Service	端口映射	用途
prometheus-k8s	9090:NodePort	Prometheus Web UI
grafana	3000:NodePort	Grafana 面板
alertmanager-main	9093:NodePort	Alertmanager UI

⑥ 访问 Grafana

plaintext

http://<节点IP>:<Grafana-NodePort>

默认账号密码：admin / admin

卸载

bash

kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup

八、速查总结

Prometheus 收集 K8S 数据的三种方式

1. Exporters：收集节点信息，格式化后暴露 HTTP 接口
2. Instrumentation ：直接收集内置指标暴露器的信息（如 K8S 组件自带的 /metrics）
3. Push Gateway：收集短生命周期任务的数据

防止告警轰炸

Alertmanager 三板斧：去重 + 分组 + 静默

• 去重：同一告警不重复发
• 分组：同类告警合并为一条通知
• 静默：维护期间或已知问题，临时屏蔽告警

常见时序数据库

表格

TSDB	特点
Prometheus	自带，轻量，适合短期存储
InfluxDB	外置长期存储，社区活跃
OpenTSDB	分布式，基于 HBase
Graphite	老牌，纯存储+渲染

全文总结 ：Prometheus 的核心思路就是------Exporter 暴露数据 → Server Pull 采集 → TSDB 存储 → PromQL 查询 → Alertmanager 告警 → Grafana 展示。在 K8S 环境下，通过 kube-prometheus 一键部署整套监控栈，开箱即用。