很多团队在 k8s 里做监控第一个想到的方案就是 Prometheus Grafana。这套组合在云原生领域基本是事实标准Prometheus 负责采集和存储指标Grafana 负责可视化。但真正落地的时候事情没那么简单——命名空间怎么规划、ServiceMonitor 怎么写、存储怎么挂、告警怎么发每一步都有讲究。这篇文章基于我实际维护的一套生产集群监控体系把从零部署到稳定运行的完整过程做个梳理,适合正准备在 k8s 里搭建监控、或者已经部署了但遇到一堆问题的同学参考。先说结论不建议直接在 k8s 里手动部署单机 Prometheus而是用 Prometheus Operator 的方式部署。后面我会详细解释为什么这么选以及每一步背后的原理。1. 部署前先想清楚选型、版本与存储规划1.1 用 Operator 还是手动编排我第一次在 k8s 里部署监控时第一反应是写一堆 Deployment、Service、ConfigMap把 Prometheus、Grafana、Alertmanager 各组件串起来。后来发现这条路走不远。手动部署意味着每次调整采集配置都要改 ConfigMap 然后重启 Pod而 k8s 里的服务实例是动态伸缩的Pod IP 会随时变化传统的静态配置文件无法适应这种动态环境。Prometheus Operator 解决的核心问题就是配置即代码。它把 Prometheus 实例、采集目标、告警规则、通知配置全部抽象成自定义资源CRD通过声明式 YAML 来管理。底层组件像 Prometheus、Alertmanager 的 Pod 由 Operator 自动生成和滚动更新你不需要手工重启。在 k8s 这种以 API 为中心的平台上用 Operator 的方式管理有状态服务才是正确姿势。选择 Operator 方案的另一个原因是社区维护成本低。Prometheus Operator 由云原生社区持续维护新版本 Prometheus 出来后会同步跟进。我自己维护三套集群如果手动部署每套集群的配置差异会越滚越大用 CRD 统一管理后三套集群的监控配置几乎完全一致只是标签和副本数略有不同。1.2 版本组合与存储方案先看版本搭配。从 kube-prometheus 项目发布节奏来看当前主流组合是组件版本建议说明Kubernetes1.26 及以上太老的版本对 CRD 支持有问题Prometheus Operatorv0.71 及以上太老版本不支持部分新 CRD 字段Prometheusv2.50 及以上支持新的 TSDB 特性内存管理更好Grafanav10.x新版对告警和数据源管理更友好Alertmanagerv0.26 及以上与 operator 配套即可版本这里提醒一句不要随便用 latest 标签。我有一次直接在部署文件里写了 latest结果某天 operator 自动升级后 CRD schema 变了导致现有 ServiceMonitor 全部失效。生产环境务必锁定具体版本号。存储是一个容易忽略的环节。Prometheus 是有状态服务数据必须持久化。如果直接让 Prometheus 用 emptyDirPod 一重启所有历史数据全没了。生产环境建议提前规划好 StorageClass用块存储或云盘。Prometheus 对存储的要求是低延迟随机写入SSD 优先不要用网络文件系统NFS做 Prometheus 的数据盘性能会非常糟糕。存储容量估算是另一个常见误区。很多人不知道 Prometheus 数据量怎么算这里有公式磁盘空间 采集速率样本/秒 × 样本大小约2字节含索引估算 × 保留时间举例来说采集速率是每秒 8 万个样本保留 15 天那么大约需要 8万 × 2字节 × 86400秒 × 15天 ≈ 200GB。注意这只是粗略估算如果加了大量高基数标签比如 request_id 这种高唯一值标签存储消耗会成倍放大。建议从小容量开始实际跑一周后观察数据目录增长速率再按需扩容。2. 监控体系的核心组件拆解2.1 服务发现ServiceMonitor 是怎么工作的在 k8s 部署 Prometheus 和裸机部署的最大差异在于服务发现机制。物理机上我们通常在 prometheus.yml 里写一堆 static_configs 指定目标地址。但在 k8s 里Pod 是随时变化的IP 也是动态的所以需要用 Kubernetes 的服务发现能力。Prometheus Operator 引入了一个核心概念叫 ServiceMonitor。它的作用是把采集哪些目标的规则声明出来Operator 根据 ServiceMonitor 里定义的标签选择器从 API Server 动态查询匹配的 Service再解析出后端的 Pod IP 列表自动生成 Prometheus 的采集配置。用生活例子类比ServiceMonitor 就像一张快递配送单指定了哪些网点的货物要收Prometheus 就是那个每天按配送单上门取件的快递员。每个 Service 加上了特定标签后就相当于在配送单上登记了一个新网点Prometheus 重启后会自动把这个新网点纳入配送范围。具体到工作机制ServiceMonitor 有三个核心字段需要理解selector匹配 Service 的标签endpoints定义端口、路径、认证方式等采集参数namespaceSelector限定在哪些命名空间内查找 Service第一次用的时候容易犯的错是只写了 selector 不写 namespaceSelector。如果 Prometheus 实例本身定义里设置了 serviceMonitorNamespaceSelector 限定范围那么不写 namespaceSelector 的 ServiceMonitor 很可能没被加载。这个排查起来比较隐蔽后面常见问题部分我会专门讲。2.2 指标采集与指标类型搞清 Prometheus 的指标模型对后续写采集规则很有帮助。Prometheus 采集到的每一条数据都是一个时间序列由指标名 标签集合唯一标识。比如 node_cpu_seconds_total{instancexxx, cpu0, modeidle}这里的 labels 决定了时间序列的维度。在 k8s 监控里最常用的指标来源有三个node-exporter暴露节点层面的指标CPU、内存、磁盘、网络kube-state-metrics从 kube-apiserver 获取集群对象状态比如 Pod 副本数、Deployment 状态、资源配额kubelet 内置的 cAdvisor采集容器层面的指标比如容器 CPU 使用率、内存使用量很多新手分不清 node-exporter 和 kube-state-metrics 的区别。简单说node-exporter 看的是机器本身的状态kube-state-metrics 看的是k8s 对象的状态。如果节点挂了但 Pod 被调度到了其他节点node-exporter 会显示某节点消失而 kube-state-metrics 会显示 Pod 仍在运行但实际用的可能是新节点。指标类型方面需要重点理解 Counter 和 Gauge 的区别Counter 只增不减适合计数类指标比如请求总数Gauge 可增可减适合状态类指标比如当前内存占用。写 PromQL 查询时需要根据类型选择函数像 rate() 只能用在 Counter 上用在 Gauge 上会得到完全无意义的结果。2.3 Prometheus 实例的 CRD 定义前面说 Operator 会自动生成 Prometheus StatefulSet那么它是怎么知道 Prometheus 实例长什么样的答案在 prometheus 这个 CRD 里。下面是我实际用的一个精简版配置apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: name: main namespace: monitoring spec: replicas: 2 logLevel: info serviceAccountName: prometheus serviceMonitorSelector: matchLabels: release: my-monitor podMonitorSelector: matchLabels: release: my-monitor ruleSelector: matchLabels: role: alert-rules retention: 15d storage: volumeClaimTemplate: spec: storageClassName: fast-ssd resources: requests: storage: 200Gi resources: requests: memory: 4Gi cpu: 1000m limits: memory: 8Gi cpu: 2000m affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: prometheus: main topologyKey: kubernetes.io/hostname这里几个关键字段的作用serviceMonitorSelector 和 podMonitorSelector这是过滤器决定 Prometheus 加载哪些 ServiceMonitor/PodMonitor。设计意图是把监控职责分开——比如你想部署多套 Prometheus一套只负责业务监控另一套只负责集群基础监控就可以在各自的 prometheus CRD 里用不同的 label 过滤。ruleSelector决定加载哪些 PrometheusRule 告警规则。retention数据保留时间。storage.volumeClaimTemplatePrometheus 是 StatefulSet这个字段会让 Operator 自动为每一个副本创建 PVC而不是手动一个个去建 PV。affinity.podAntiAffinity让两个副本尽量调度到不同节点避免一台节点挂了导致整个监控挂掉。2.4 Grafana 与 Prometheus 的数据源连接Grafana 是纯展示层它通过 HTTP API 读取 Prometheus 数据。部署 Grafana 本身很简单但要注意数据源配置方式。Grafana 官方镜像里有一个环境变量叫 GF_PROMETHEUS_URL 或通过 provisioning 方式配置数据源。在 k8s 里推荐使用 provisioning 机制在启动时自动配置好数据源和 Dashboard而不是进 Web UI 手工点。具体来说挂载一个 ConfigMap 到 /etc/grafana/provisioning/datasources/ 目录文件内容大致如下apiVersion: v1 kind: ConfigMap metadata: name: grafana-datasources namespace: monitoring data: datasources.yaml: | apiVersion: 1 datasources: - name: Prometheus type: prometheus url: http://prometheus-operated.monitoring.svc:9090 access: proxy isDefault: true注意这里的 URL 用的是 Prometheus Operator 自动创建的 Service 名称 prometheus-operated端口是 9090。Grafana 通过集群内 DNS 解析到这个 Service再由 Service 转发到后端的 Prometheus Pod。相比直接写 Pod IP用 Service 的好处是即使 Prometheus Pod 重建了DNS 依然能解析到最新地址Grafana 不需要任何改动。3. 一步步在 k8s 里部署 Prometheus Grafana3.1 准备命名空间与关键配置部署前的第一件事是规划命名空间。我习惯把所有监控相关组件放在一个独立的命名空间里比如 monitoring这样做的好处是权限管理方便、资源隔离清晰。用以下命令创建kubectl create namespace monitoring接下来要准备的是 RBAC 权限。Prometheus 需要通过 Kubernetes API 发现目标所以必须给它绑定合适的 ServiceAccount 和 ClusterRole。一个标准的 ClusterRole 需要包括对 nodes、services、endpoints、pods、ingresses 等资源的 get、list、watch 权限。这些权限缺一不可否则会看到 Prometheus 日志里刷一堆 forbidden 错误服务发现的目标列表全是空的。3.2 部署 Prometheus Operator 本体从项目仓库获取部署清单建议锁定 commit 或 tag避免拉取到 master 上尚未稳定的版本。操作如下git clone https://github.com/prometheus-operator/kube-prometheus.git cd kube-prometheus git checkout release-0.14 # 根据实际版本调整 kubectl create -f manifests/setup/manifest/setup/ 目录里是 CRD 定义和 Operator 自身的 RBAC 资源。这个目录必须最先应用因为后面的组件都在使用这些 CRD。接着创建 Operator 以及关联组件kubectl create -f manifests/这一步会创建 Prometheus、Alertmanager、Grafana、node-exporter、kube-state-metrics 等所有资源。等一两分钟检查 Pod 状态kubectl -n monitoring get pods正常情况下应该看到 prometheus-operator、prometheus-main-0、alertmanager-main-0、grafana、node-exporter-xxx、kube-state-metrics-xxx 这些 Pod 处于 Running 状态。用官方清单部署的好处是默认配置经过了社区大量生产环境验证省去了自己调优的初始步骤。但这不等于什么都不用改——后面我们会针对自己的集群情况做定制。3.3 配置 Prometheus 实例官方清单默认创建的 Prometheus CRD 可能不符合你的实际集群环境最典型的问题包括存储没有配置、副本数不合适、serviceMonitorSelector 范围太宽或太窄。在部署后检查当前的 Prometheus CRDkubectl -n monitoring get prometheus main -o yaml常见的修改点包括存储官方清单默认不配置 storage意味着数据存在 emptyDir 里Pod 重建就丢失。通过上一节提到的 storage.volumeClaimTemplate 增加持久化。副本数小集群不需要 2 副本设置 1 个副本即可但如果你有告警需求建议至少 2 个副本搭配 Thanos 或 VictoriaMetrics 做 HA 场景时更灵活。资源限额默认 requests 和 limits 可能比较保守。如果采集目标很多内存不够的话 Prometheus 会频繁 OOM。设置合理的 limits 很重要但别设太高否则集群资源的压力会很大。修改后直接 apply 即可Operator 会自动滚动更新 StatefulSet不需要手工操作。3.4 部署 node-exporter 和 kube-state-metrics官方清单里一般已经包含了这两个组件的配置。如果你的场景是从零开始搭需要单独部署这里给一个参考。node-exporter 的部署方式是一个 DaemonSet确保每台节点上都跑一个 Pod 采集节点指标。它通过 hostNetwork 方式直接监听节点网络端口 9100这样即使 Pod 网络有问题也能正常工作。在 kube-prometheus 清单里node-exporter 使用 hostNetwork: true 和 tolerations保证即便节点处于不可调度状态也能在一定程度上继续运行。kube-state-metrics 是普通 Deployment它从 kube-apiserver 获取集群资源对象状态。它消费的目标是 Pod、Deployment、Service 等对象而不是节点硬件。部署后验证采集目标是否正常加入可以通过 Prometheus Web UI 的 Targets 页面查看。如果一切正常应该能看到 node-exporter 对应每个节点的 target、kube-state-metrics 的一个 target、以及 kubelet 的若干 target。3.5 部署 Grafana 并配置 DashboardGrafana 本身在官方清单里已经包含但它默认的 admin 密码和持久化需要处理。获取密码的方式kubectl -n monitoring get secret grafana-admin -o jsonpath{.data.admin-password} | base64 -dGrafana 的 ConfigMap 存储建议单独创建持久化 PVC否则升级 Grafana 或者 Pod 迁移后配置会丢失。我用的做法是给 Grafana 的 Deployment 加上 volumeClaimTemplate挂载到 /var/lib/grafana。Dashboard 的导入有两种方式。一种是进去 Web UI 手动 import适合临时使用。另一种是用 provisioning 机制把 Dashboard JSON 文件挂载到 /etc/grafana/provisioning/dashboards/ 目录Grafana 启动时自动加载。推荐用第二种便于版本管理和团队共享。推荐安装的 Dashboard 有 315Kubernetes Cluster 概览和 1860Node Exporter 节点监控这些可以在 Grafana 官方社区找到。3.6 访问方式监控系统搭建好后通常有几种访问方式Ingress、NodePort 或 Port-Forward。开发测试环境直接用 Port-Forward 最简单kubectl -n monitoring port-forward svc/grafana 3000:3000然后浏览器打开 http://localhost:3000用上面获取的账号密码登录。生产环境建议用 Ingress并为 Grafana 和 Prometheus 分别配置域名。注意 Prometheus Web UI 默认没有登录认证如果暴露到公网必须加上反代层的 Basic Auth 或 OAuth。这一点经常被忽略网上总是能看到一些裸奔的 Prometheus 实例。4. 告警链路配置从规则到通知4.1 编写 PrometheusRule部署好采集和展示监控体系只完成了一半。另一半是告警。Prometheus 里告警规则用 PrometheusRule 这个 CRD 定义它会被 Operator 加载并转换为内置的 rules 文件。下面是一个实际可用的 Pod 重启告警规则apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: kube-prometheus-rules namespace: monitoring labels: role: alert-rules spec: groups: - name: kubernetes-pods rules: - alert: PodRestarting expr: increase(kube_pod_container_status_restart_total[1h]) 5 for: 10m labels: severity: warning annotations: summary: Pod {{ $labels.namespace }}/{{ $labels.pod }} 频繁重启 description: Pod 在 1 小时内重启超过 5 次编写规则时两个关键点expr 的表达式必须基于某个实际存在的指标。先用 Prometheus Web UI 的 Graph 页验证指标存在再写规则否则容易踩规则加载成功但从不触发的坑。for 字段的作用是规则在满足 expr 条件后需要持续 for 指定的时间才会真正触发。这个设计是为了过滤瞬时抖动比如一次快速恢复的 CPU 飙升不应该产生告警。4.2 配置 Alertmanager默认部署的 Alertmanager 是空配置不能直接发通知。需要配置 route 和 receiver把告警发到钉钉、企业微信或邮件。Alertmanager 的配置藏在名为 alertmanager-main 的 Secret 里因为里面可能包含 webhook URL、密码等敏感信息。修改方式如下kubectl -n monitoring edit secret alertmanager-main其中 data 字段是用 base64 编码的 alertmanager.yaml。一个精简配置示例global: resolve_timeout: 5m route: group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://your-webhook-service/notify send_resolved: true参数含义group_by告警按什么维度分组这样同一个应用的多条告警合并为一条通知。group_wait一组告警在首次通知前等待的时间用于合并同一时间窗口内的告警。repeat_interval如果告警没有恢复多久重新发一次通知。设 4 小时比较合适太短会被告警轰炸。修改完 Secret 后Alertmanager 会自动重载配置。如果没生效检查 Pod 日志确认配置格式是否正确。4.3 告警链路验证配置完成后手动触发一条测试告警验证全链路。一个简单方法是降低告警阈值比如把 PodRestarting 的阈值改成 0然后随便重启一个 Pod等 10 分钟观察通知是否到达。验证通过后别忘把阈值改回来。另外有一次我犯过的错误只在 Alertmanager 里配置了 webhook没有确认 webhook 服务本身能接收请求结果测试告警一直显示已发送但目标方没收到。排查时先用 curl 直接调 webhook 服务的接口确认接口通再反向排查 Alertmanager 侧。提示Alertmanager 的 Web UI默认端口 9093可以查看 Alertmanager 收到的告警和通知状态这是排查告警链路的重要工具。很多问题在这里一眼就能看出是规则没触发、没有发送、还是已发送但被丢弃。5. 常见问题与排查实录5.1 问题速查表我用表格整理一下实际运维中遇到的高频问题现象可能原因排查思路Prometheus Target 列表为空RBAC 权限不足或 ServiceMonitor 标签不匹配查 Prometheus 日志里的 forbidden 报错检查 serviceMonitorSelector 是否匹配某个 Target 显示 DownPod IP 无法连接通常是 NetworkPolicy 或安全组从 Prometheus Pod 内 curl 目标地址测试连通性指标数据断断续续采集间隔过短、存储 IO 瓶颈或目标端过载拉长 scrape_interval检查节点 IO 使用率查询 Grafana 有数据但告警不触发expr 条件写错或 for 时间过长先在 Prometheus Graph 页执行 expr 确认结果Prometheus 内存持续上涨高基数标签、采集目标过多用 promhttp_metric_handler_requests_total 定位高消耗 job精简标签告警重复发送Alertmanager repeat_interval 设置太短调长 repeat_interval 到 4 小时以上Grafana 无法登录默认密码被改或 Secret 被误删删掉 grafana 的 Deployment 重新创建让它重新初始化密码5.2 三个容易踩的坑第一个坑是 ServiceMonitor 的 namespace 限定。我在生产集群里遇到过一个问题新建的 ServiceMonitor 应用后Prometheus 的 target 没有任何变化也没有报错。排查半天发现 Prometheus CRD 里设置了 serviceMonitorNamespaceSelector 只允许 monitoring 命名空间而我把业务监控的 ServiceMonitor 放在了业务命名空间于是被过滤掉了。这个点官方文档写得很隐蔽不看 Prometheus CRD 实际配置很难发现。第二个坑是节点磁盘压力导致 Prometheus 写入失败。Prometheus 在做压缩时涉及读改写如果磁盘空间不足或 IO 抖动会导致写入失败。而且它不会主动清理旧数据——直到 retention 到期才逐步删除所以磁盘占用率会在数据量高峰时突然上升。我的做法是给数据卷加独立的监控告警当磁盘使用率超过 80% 提前响应同时配置 prometheus 的 -storage.tsdb.retention.size 参数让它在达到容量上限时主动删除最旧的数据而不是死等 retention 到期。第三个坑是高基数指标把 TSDB 打爆。正常情况下每个时间序列大约占 2 字节的索引内存。一个常见的反模式是给指标加上 request_id 或 user_id 这类高唯一性标签。比如某个服务的 HTTP 请求指标加上了 user_id 标签一天几百万个独立用户那么这个指标会产生几百万条时间序列内存直接翻几倍。排查方式是在 Prometheus Web UI 的 Status Cardinality 页面查看哪些指标占据了最多的时间序列数。解决方法是删掉这类标签或者用记录规则做预聚合。5.3 资源规划参考最后给一组我实际使用的资源参数基本可以覆盖大多数中小集群100 个节点以内的监控需求组件请求资源建议限制Prometheus2副本4Gi 内存 / 1 CPU8Gi / 2 CPUAlertmanager2副本256Mi / 100m512Mi / 200mGrafana1副本512Mi / 200m1Gi / 500mnode-exporter每节点1个128Mi / 50m256Mi / 200mkube-state-metrics1副本256Mi / 200m512Mi / 500m这套配置在 80 个节点的集群上运行Prometheus 的采集速率约每秒 6 万样本内存消耗大约 5-6Gi8Gi 的 limits 有足够余量。6. 扩展建议与个人体会6.1 高可用与联邦当集群规模增长到一定程度单个 Prometheus 实例会成为瓶颈。常见的扩展方向有两个一是高可用架构部署两套完全相同的 Prometheus搭配 Thanos 或 VictoriaMetrics 做长期存储和全局查询。Thanos 的 Sidecar 模式可以与现有 Prometheus 无缝集成先用 Thanos Query 聚合两个副本的数据再配置对象存储做长期归档。二是联邦架构在中心集群部署一个聚合层 Prometheus各边缘集群用专用 Prometheus 做本地采集通过 federation 把聚合后的指标上报到中心。这样每个集群有独立的故障域中心只做展示和全局告警网络故障时边缘集群的监控不依赖中心。如果只是中小规模集群不建议一开始就上 Thanos 这类重型方案。prometheus 实例加双副本配合 Grafana 的高可用展示对大多数场景已经足够。6.2 给新手的几条建议从零搭完这一整套我最大的体会是监控系统的复杂度主要不在装起来而在维护好。装起来可能只需要半天但后续的规则调优、容量规划、告警收敛、以及持续迭代才是长期工作。给刚接触这个体系的人几条具体建议第一把所有配置都放在 Git 仓库里管理用 CI 流程做变更和审核。配置文件里一个标点符号错误会导致整个 Prometheus 实例不加载任何规则回溯起来很麻烦。有 Git 历史可以快速 diff 定位。第二先把集群基础监控节点、容器、k8s 对象跑稳再做业务监控。业务监控一定是从简单的 RED 方法开始也就是 request rate、error rate、duration 这三个黄金指标起步别一开始就想算尽所有业务指标。第三告警规则宁少勿滥。刚开始实践时我一次性加了 100 多条规则结果每天告警轰炸不断到最后大家直接忽略所有告警完全失去了告警的意义。后来精简到 15 条核心规则消息频率明显下降每条告警都有人认真看。6.3 最后补充一个节省资源的小技巧如果集群里的 Pod 数量非常多默认的指标采集会对 kubelet 产生较大的请求压力。这里可以在 Prometheus CRD 里调整 kubelet 的采集方式把 metrics_endpoints 的 bearerTokenFile 改为 serviceAccount 方式并在 kubelet serviceMonitor 上配置 scrape_interval 拉长到 60 秒而不是默认的 30 秒。节点层面的容器指标如 CPU、内存变化通常不是那么频繁60 秒的采集精度完全够用却能把 kubelet 的负载降低一半以上。实际调整时也顺手把 Prometheus 本地的 --storage.tsdb.retention.time 设为 15 天、--storage.tsdb.retention.size 设为 200GB。这两个参数同时配置后Prometheus 内部会优先考虑容量上限数据量到 200GB 就删除最老的块相当于给磁盘加了一道保险。第一次因为磁盘满导致 Prometheus 只读时Prometheus 会拒绝所有查询请求这个我踩过一两次。这套部署方案我前后迭代了大半年从最初手动部署的混乱状态逐步演进到用 Operator 统一管理。过程中学到的核心思路就是尽量把运维知识沉淀成声明式配置让平台替你处理那些重复的、容易出错的操作。如果你在部署过程中遇到了我没列出来的问题可以从 Prometheus Operator 的官方文档里找找线索绝大多数已知问题在那里都能找到答案。