Prometheus 已经成为 Kubernetes 生态中事实上的监控标准，无论是云厂商托管的集群还是自建的数据中心环境，大部分监控方案都建立在 Prometheus 的指标模型之上。这一套体系之所以流行，关键在于它天生就是为云原生环境设计的：通过服务发现自动找到采集目标，按固定周期拉取指标数据，配合多维度的标签模型，可以灵活应对 Kubernetes 中 Pod 频繁创建销毁的动态特性。本文将从架构原理入手，一步步完成 Prometheus 在集群内的部署和配置。
一、Prometheus 的核心架构与工作原理
在动手部署之前，有必要先弄清楚 Prometheus 是怎么工作的。Prometheus 采用的是拉取模式，服务端会按照配置的时间间隔，主动访问目标暴露的 metrics 接口获取数据。这个设计在 Kubernetes 中非常契合，因为每个 Pod 的地址都是动态变化的，靠静态配置的方式很难维护，而 Prometheus 可以直接对接 Kubernetes API，通过标签选择器自动发现符合条件的 Service 和 Pod。
整个体系主要由几个组件构成：Prometheus Server 负责指标采集与存储，底层使用自带的时序数据库，数据按时间序列保存；node-exporter 以 DaemonSet 形式运行在每个节点上，暴露 CPU、内存、磁盘等主机级指标；kube-state-metrics 关注的是集群对象的状态，比如某个 Deployment 的副本数是否达标、Pod 处于什么阶段；Alertmanager 接收 Prometheus 推送的告警，负责去重、分组和通知渠道分发；Grafana 则负责查询 PromQL 并绘制可视化面板。
需要提醒一点，Prometheus 本地存储并不是为了长期保存数据设计的，默认保留时间只有 15 天左右。如果集群规模较大或者有合规性留存要求，需要考虑接入远程存储方案，比如 Thanos 或者 VictoriaMetrics，本文先聚焦基础部署，不展开这部分内容。
二、使用 Helm 快速部署 kube-prometheus-stack
部署方式有两种思路：一种是手工编写一堆 YAML 清单自己拼装各个组件，另一种是使用社区维护的 Helm Chart 一次性装好整套栈。对于绝大多数场景，推荐第二种方式，官方的 kube-prometheus-stack Chart 已经内置了 Prometheus Operator、Alertmanager、Grafana 以及常用的 exporter 和告警规则，开箱即用。
先添加仓库并安装：
# 添加 Prometheus 社区仓库 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 安装到 monitoring 命名空间 kubectl create namespace monitoring helm install monitoring prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --set grafana.service.type=NodePort \ --set prometheus.prometheusSpec.retention=15d
安装完成后可以检查 Pod 状态，正常情况下 monitoring 命名空间下会有 Prometheus、Alertmanager、Grafana 以及多个 exporter 的 Pod 处于 Running 状态：
kubectl get pods -n monitoring # 输出示例 # prometheus-monitoring-kube-prometheus-prometheus-0 2/2 Running # alertmanager-monitoring-kube-alertmanager-0 2/2 Running # monitoring-grafana-7d8f9c6b5-x2k9p 3/3 Running # monitoring-kube-state-metrics-6c4d8f7b9-mn3pq 1/1 Running
如果想访问 Prometheus 自带的 Web 界面，最简单的办法是做端口转发：kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-prometheus 9090:9090，然后浏览器打开本机 9090 端口，在 Status 菜单的 Targets 页面里能看到所有采集目标的状态，全部为 UP 就说明数据抓取正常。
Helm 方式的好处是升级和回滚都很方便，而且 Chart 默认已经配置好了一大堆实用的告警规则，比如节点不可用、Pod 崩溃重启、证书即将过期等，覆盖了日常运维的大部分场景，可以在此基础上按需裁剪。
三、通过 ServiceMonitor 实现自定义应用的指标采集
Prometheus Operator 引入了 CRD 的概念，这是它比传统配置方式优雅的地方。传统方式下每加一个采集目标就要改一次配置文件并触发重载，而使用 Operator 之后，只需要声明一个 ServiceMonitor 资源，Operator 会自动把它翻译成 Prometheus 的采集配置，整个过程不需要触碰任何静态配置文件。
假设你有一个业务应用，已经通过 HTTP 暴露了 /metrics 接口，并且有对应的 Service，那么只需要提交下面这份清单：
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app-monitor
namespace: monitoring
labels:
release: monitoring # 必须与 Prometheus 的 selector 匹配
spec:
namespaceSelector:
matchNames:
- default
selector:
matchLabels:
app: my-app
endpoints:
- port: http
interval: 30s
path: /metrics
这里有几个容易踩坑的地方需要注意。第一是 metadata 里的 labels，Prometheus 实例默认只认带有特定标签的 ServiceMonitor，这个标签值要和 Helm 安装时的 release 名称对应上，漏掉这个标签会导致 ServiceMonitor 不生效，这也是新手最常见的问题。第二是 selector.matchLabels 匹配的是 Service 的标签而不是 Pod 的标签，端口名 port: http 指的也是 Service 中定义的端口名称。第三，业务应用暴露的指标最好遵循 Prometheus 的文本格式，如果用 Spring Boot，引入 micrometer 依赖后 /actuator/prometheus 端点可以直接使用。
四、Grafana 可视化与告警配置实践
数据采集上来之后，Grafana 提供了展示层。kube-prometheus-stack 安装的 Grafana 已经自动配置好了 Prometheus 数据源，并且导入了一批官方 Dashboard，包括节点资源概览、集群容量分析、Pod 资源消耗排行等。默认账号是 admin，初始密码可以通过 kubectl get secret -n monitoring monitoring-grafana -o jsonpath='{.data.admin-password}' | base64 -d 查询。
除了看现成的面板，日常更多的工作是针对业务写 PromQL 查询。举几个常用的例子：查询某个命名空间 CPU 使用率最高的前十个 Pod，可以用 topk(10, sum by(pod)(rate(container_cpu_usage_seconds_total{namespace='default'}[5m])))；判断节点内存压力，可以看 node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes 的比值；监控 Pod 重启次数，则关注 kube_pod_container_status_restarts_total 的增长趋势。掌握这些基本查询后，自己定制面板就不会太困难。
告警方面，建议在 Helm values 中自定义 PrometheusRule，把业务相关的告警规则集中管理。例如接口错误率超过阈值、副本数与期望值不一致这类问题，写成 PromQL 表达式配上 for 持续时间，避免瞬时抖动误报。Alertmanager 的通知渠道支持企业微信、钉钉、邮件等，国内环境用钉钉 webhook 的比较多，配置 receivers 时记得把 resolve_timeout 和分组策略调合理，不然告警风暴来的时候手机会被轰炸。
最后补充几个运维建议：一是控制采集频率，大规模集群把 interval 设得太短会显著加重 Prometheus 负担；二是定期检查 targets 页面中被丢弃的采集目标；三是为 Prometheus 的数据目录配置足够的磁盘空间，存储写满会导致服务不可用。把这些细节处理好，一套稳定可靠的集群监控体系就算真正落地了。
Kubernetes监控Prometheus部署监控告警修改时间：2026-09-08 16:09:12