从0到1部署Prometheus监控：K8s环境避坑实操
很多人觉得部署Prometheus很简单，helm install一下就完事了——但在生产环境里，“能用”和“好用”完全是两码事。我见过不少团队上来就用默认配置，结果要么监控不到关键指标，要么资源占用高到影响业务。这里结合我帮三个客户落地的经验，跟你说清楚从部署到配置的关键步骤，以及每个环节最容易踩的坑。
部署前必须做的3件事：别让“默认配置”坑了你
在动手部署前，你得先想清楚三个问题：监控哪些组件？数据要存多久？服务器资源够不够？去年那个电商客户就是忽略了这一步，直接用helm chart的默认值部署，结果踩了三个大坑。
第一个坑是“监控范围盲目求全”。他们当时觉得“反正都监控了，不如把所有Pod的指标都采进来”，结果连日志组件、数据库备份的Pod都配了监控，导致Prometheus每秒要处理2万多个指标，CPU直接飙到80%，业务Pod开始卡顿。后来我们一起梳理了“核心监控对象清单”，只保留了K8s节点、核心业务Deployment、数据库和中间件，指标量降到每秒3000个，CPU立刻降到20%以下。所以你部署前一定要列清楚：节点层（CPU/内存/磁盘IO）、网络层（Ingress流量/Service响应时间）、应用层（业务Pod的请求量/错误率） 这三层是必须监控的，其他非核心组件可以后面再加。
第二个坑是“存储策略没调整”。Prometheus默认会把数据存15天，而且 retention size 没限制——这意味着如果你的集群规模大（比如50个节点、200个Pod），每天可能产生50G数据，15天就是750G，普通服务器根本扛不住。我后来帮他们改了配置：把 retention time 设为7天，同时加了 retention size: “100GB”，意思是“要么存满100G就删旧数据，要么超过7天删，哪个先到算哪个”。你可以根据自己的业务需求调整，比如金融客户可能需要存30天，但至少要设个上限，别让它“无限吃磁盘”。
第三个坑是“资源分配拍脑袋”。很多人部署时不给Prometheus设置资源限制，或者随便填个“CPU 1核、内存2G”。但 Prometheus的资源消耗和指标量直接相关：每秒采集1000个指标，大概需要0.5核CPU+1G内存；每秒5000个指标，就得2核CPU+4G内存。你可以用这个公式估算：CPU核数 = 每秒指标数 / 2000，内存G数 = 每秒指标数 / 1000，然后在此基础上再加30%的冗余。比如你算出来需要2核CPU，就设request: 2核，limit: 3核，避免资源不够时被K8s杀掉。
部署时的关键步骤：ServiceMonitor配置避坑指南
用Prometheus Operator部署时，最核心的配置就是ServiceMonitor——它相当于Prometheus的“采集任务清单”，告诉Prometheus要从哪些Service拉取指标。但很多人在这里会遇到“监控目标显示0”或者“重复采集”的问题，我之前帮一个游戏客户排查时，发现他们配了5个ServiceMonitor，结果有3个的label selector重复了，导致同一个Pod被采集了3次，数据直接翻倍。
正确配置ServiceMonitor的步骤其实很简单，记住“三看”：看label匹配、看端口配置、看命名空间。你可以先创建一个基础的ServiceMonitor.yaml，然后按这三步检查：
第一步，label selector要精准。比如你要监控名为“user-service”的Deployment，它对应的Service标签是“app: user-service”，那ServiceMonitor的selector就要写：
selector:
matchLabels:
app: user-service # 只匹配带这个标签的Service
千万别用“app: *”这种模糊匹配，否则会把其他服务的Service也匹配进来，导致采集无关指标。
第二步，端口名和指标路径别写错。Service里暴露的端口名要和ServiceMonitor里的port.name一致，比如Service里端口名叫“metrics”，那ServiceMonitor里也得写“metrics”； 指标路径默认是“/metrics”，但有些应用（比如Spring Boot）可能自定义了路径（比如“/actuator/prometheus”），这时候要在endpoints.path里指定，不然Prometheus会报“404 Not Found”。
第三步，命名空间别遗漏。如果你把ServiceMonitor部署在“monitoring”命名空间，而要监控的Service在“default”命名空间，一定要在ServiceMonitor里加上namespaceSelector：
namespaceSelector:
matchNames:
default # 明确指定要监控的命名空间 去年有个客户就是没加这个，结果ServiceMonitor一直在“monitoring” namespace里找Service，自然啥也找不到。
为了让你更直观避坑，我整理了一个“ServiceMonitor常见问题排查表”，你部署后如果发现监控目标异常，可以对着查：
| 问题现象 | 可能原因 | 排查步骤 |
|---|---|---|
| Prometheus Targets显示“down” |
3. 网络策略拦截 |
3. 检查是否有NetworkPolicy禁止9090端口访问 |
| 指标采集重复 |
|
|
| 部分指标缺失 |
|
|
部署完成后，记得在Prometheus的Web界面（http://prometheus-ip:9090/targets）检查Targets状态，所有目标都显示“UP”才算部署成功。如果有“DOWN”的，按上面表格的步骤排查，基本都能解决。
告警系统优化：从“吵死人”到“精准提醒”
搞定了监控数据采集，接下来就是告警——这可是个“老大难”问题。我见过最夸张的一次，一个客户的告警群一天发了2000多条消息，结果运维同学直接把群屏蔽了，最后真的业务故障时反而没人看到。其实告警不是越多越好，关键是“该响的时候响，不该响的时候别吵”。这部分结合我帮金融客户优化告警系统的经验，跟你说清楚怎么从规则配置到Alertmanager设置，把告警系统从“噪音制造机”变成“贴心助手”。
告警规则配置：别让“小问题”触发“大动静”
很多人写告警规则时，喜欢用“CPU使用率>80%就告警”这种简单逻辑，结果业务高峰期每个Pod都触发告警，直接变成“告警风暴”。其实好的告警规则要满足三个条件：影响业务才告警、有持续时间才告警、区分严重程度。
先说说“影响业务才告警”。比如节点CPU使用率高，如果只是某个非核心节点（比如日志处理节点），就算到90%也不用告警；但如果是核心业务所在的节点，CPU持续5分钟>80%，就必须告警。这里的关键是“关联业务重要性”，你可以给节点或Pod打标签（比如“priority: critical”“priority: normal”），然后在告警规则里用labels.priority做判断：
groups:
name: node_alerts
rules:
alert: HighCpuUsage
expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) > 0.8
for: 5m # 持续5分钟才告警
labels:
severity: critical
annotations:
summary: "节点CPU使用率过高"
description: "节点 {{ $labels.instance }} CPU使用率持续5分钟超过80% (当前值: {{ $value }})"
# 只对核心节点生效
match_labels:
priority: critical
再说说“持续时间”。用“for: 5m”意味着指标要连续5分钟满足条件才触发告警，这样能过滤掉瞬时波动——比如业务突然来了一波请求，CPU短暂升到85%，但30秒后就降下来了，这种情况完全不用告警。我之前帮一个支付客户优化时，他们把“for”从1分钟改成5分钟，告警量直接减少了70%。
还有“区分严重程度”。告警至少要分三级：critical（紧急，必须马上处理）、warning（警告，需要关注）、info（信息，记录即可）。比如“核心数据库连接数>90%”是critical，“缓存命中率<80%”是warning，“某个非核心Pod重启”是info。这样运维同学看到告警时，能立刻判断优先级，不会被低级别告警分散注意力。
这里有个小技巧：用PromQL的“offset”函数排除“已知问题”。比如你知道每周三凌晨2点会跑数据备份，这时候节点CPU肯定高，就可以在expr里加“offset 1w”，排除这个时间段的数据：
# 排除每周三 2:00-3:00 的数据
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) > 0.8
and hour() != 2 or (hour() == 2 and day_of_week() != 3)
这样就不会在备份时段误发告警了。
Alertmanager配置：让告警“该给谁看就给谁看”
就算告警规则写得再好，如果Alertmanager配置不对，告警还是可能“送不到该看的人手里”。比如告警明明是数据库问题，结果发到了前端群；或者同个问题触发多条告警，重复发送。这部分重点说两个核心配置：路由（route）和抑制（inhibition）。
先看“路由”。Alertmanager的路由就像“快递分拣系统”，根据告警的labels（比如severity、alertname）把告警送到不同的接收渠道（邮件、钉钉、企业微信）。比如critical级别的告警发钉钉群+电话，warning级别的发企业微信群，info级别的只记录日志。你可以在route里用match和continue控制路由逻辑：
route:
group_by: ['alertname'] # 相同alertname的告警合并发送
group_wait: 10s # 组内第一个告警触发后，等待10s再发送，可能合并更多同类告警
group_interval: 1m # 同一组告警发送间隔，避免频繁发送
repeat_interval: 4h # 重复告警间隔，critical可以设1h，warning设4h
receiver: 'default' # 默认接收者
routes:
match:
severity: critical
receiver: 'critical-receiver' # critical告警走这个接收者
match_re:
alertname: ^(HighCpuUsage|HighMemoryUsage)$ # 匹配CPU/内存告警
receiver: 'node-receiver' # 发给节点运维群
这里的“group_by: [‘alertname’]”很重要，它能把同一类告警合并成一条消息——比如10个Pod都触发“HighMemoryUsage”，合并后只会发一条“10个Pod内存使用率过高”，而不是10条单独的告警。
再看“抑制”。抑制规则可以避免“连锁告警”——比如节点宕机时，该节点上的所有Pod都会触发“PodUnavailable”告警，但其实根因是“NodeDown”，这时候就可以抑制掉所有由NodeDown引起的Pod告警。配置示例：
inhibit_rules:
source_match:
alertname: NodeDown # 源告警：节点宕机
severity: critical
target_match:
alertname: PodUnavailable # 目标告警：Pod不可用
equal: ['instance'] # 当源告警和目标告警的instance标签相 抑制目标告警
去年帮电商客户配置这个规则后，他们节点宕机时的告警量从平均30条降到了1条（只保留NodeDown），运维同学再也不用在一堆告警里找根因了。
最后提醒一下，配完告警规则和Alertmanager后，一定要用“amtool check-config alertmanager.yml”检查配置文件语法，避免因为缩进错误导致配置不生效。如果你发现告警没触发，先检查Prometheus的Alerts页面，看规则是否有“Pending”状态的告警（说明条件没满足或持续时间不够）；如果是“Firing”状态但没收到消息，再检查Alertmanager的配置和日志。
如果你按这些步骤配完告警，可能会发现还是有漏报或误报的情况——别担心，告警系统本来就是“迭代优化”的过程。你可以每周复盘告警记录，看看哪些告警是无效的（比如“磁盘使用率>85%”但实际还有200G空间），哪些重要问题没告警（比如“API响应时间>500ms”没配规则），慢慢调整就能越来越精准。
给Prometheus配资源这事儿，真不能拍脑袋随便填个数，我见过太多团队要么给少了监控卡顿，要么给多了浪费服务器资源。其实这里面有个简单的估算逻辑，是我之前帮好几个客户调优时 出来的——核心看你每秒要采集多少个指标，这直接决定了CPU和内存该给多少。
你可以记个大概的公式：CPU核数差不多是每秒指标数除以2000，内存G数是每秒指标数除以1000，而且一定要多留30%的冗余。为啥是这俩数？我之前在测试环境试过，每秒1000个指标时，Prometheus的CPU大概跑在0.5核左右，内存用1G上下，按这个比例反推就有了这两个公式。比如小规模集群，像10-20个节点、50-100个Pod的那种，每秒指标量一般在500-2000个，这时候CPU request给0.5-1核，limit设1-2核就够了；内存request1-2G，limit2-4G，多留的30%空间就像给汽车留油箱余量，避免业务突发时监控自己先扛不住。
要是你的集群再大点儿，比如30-50个节点、150-300个Pod，每秒指标量会到2000-5000个，这时候CPU得加到1-2核，limit2-3核，内存request2-4G，limit4-6G。我去年帮一个做在线教育的客户调优时，他们一开始按小规模配的，结果指标量到3000时，Prometheus频繁被K8s杀掉，后来按这个中规模配置调完，CPU稳定在1.5核左右，内存3G上下，再也没出过问题。
至于大规模集群，就是每秒指标量5000+的情况，比如50个以上节点、300+Pod，这时候千万别想着用单实例硬扛。我之前见过一个客户硬撑，单实例配到8核CPU、16G内存，结果监控页面打开要等半分钟，查询稍微复杂点就超时。后来改成Prometheus联邦集群，把监控范围拆开，比如按命名空间或业务线分，每个子Prometheus负责一部分指标，单个实例CPU控制在2-4核，内存4-8G，压力一下子就分散开了，查询速度快了好几倍。记住啊，这时候单实例资源不是越多越好，超过4核CPU反而可能因为内部锁竞争导致效率下降，适可而止才是关键。
Prometheus部署后监控目标显示DOWN，可能的原因有哪些？
常见原因包括：
如何根据集群规模合理设置Prometheus的数据保留策略？
数据保留策略需结合集群规模和磁盘资源调整，核心参数包括retention time（保留时间）和retention size（保留大小）。一般
告警规则中“for: 5m”的作用是什么？是否可以省略？
“for: 5m”表示指标需持续5分钟满足告警条件才触发告警，主要作用是过滤瞬时波动（如业务高峰期短暂的CPU升高），避免“告警风暴”。不 省略：若直接省略，指标一旦超过阈值会立即告警，可能导致大量无效告警（如瞬时网络抖动引起的指标异常）。实际配置时，可根据指标稳定性调整时长，核心业务指标 3-5分钟，非核心指标可设为10-15分钟，平衡及时性与准确性。
Alertmanager接收不到告警，应该从哪些方面排查？
排查方向包括：
K8s集群规模不同，Prometheus资源配置（CPU/内存）有什么参考标准？
资源配置需根据每秒采集的指标量估算，参考公式：CPU核数 ≈ 每秒指标数 / 2000，内存G数 ≈ 每秒指标数 / 1000，同时预留30%冗余。具体参考：
