Prometheus 监控体系实践：指标采集、存储与告警治理
Prometheus 的价值不在“装上就能看图”，而在它把指标从被采集、被存储、被查询到被告警串成了一条可拆解的链路。本页从极客运维的日常值班视角出发，围绕采集模型、存储与保留、查询与看板、告警收敛与故障复盘几个层面，整理一套能在中小规模生产环境里跑稳的 Prometheus 落地思路，不重复官方配置手册，只讲取舍与踩坑。
一、采集模型：pull 与 push 的边界
Pull 为主：服务发现驱动
静态 targets 只适合实验环境。生产上更常见的是 file_sd、consul_sd 或 Kubernetes SD，让采集目标随实例伸缩自动进出，避免手工改配置导致漏采。
Push 为辅：短生命周期任务
批处理、备份脚本这类跑完就退出的作业，用 Pushgateway 或 textfile collector 兜底；但要注意 Pushgateway 不会自动清理，残留指标会污染告警判断。
二、存储与保留：先算容量再谈调优
- 单样本约 1~2 字节压缩后落盘，按“活跃序列数 × 采集间隔”估算日增量，再决定 retention 天数。
- 本地 TSDB 适合 15~30 天热数据；更长周期交给 remote_write 到 VictoriaMetrics 或对象存储方案。
- 高基数是指标的头号杀手：URL、用户 ID、请求参数绝不能进 label，否则序列爆炸会拖垮整个实例。
- 定期检查
prometheus_tsdb_head_series的增长曲线，比事后救火更有效。
15s
核心指标采集间隔
30d
本地热数据保留建议
≤5万
单实例活跃序列参考上限
三、告警治理：从“响个不停”到“响得有用”
四、常见疑问
Q：Prometheus 单机扛不住怎么办？
先做指标瘦身与分片采集，再考虑联邦或 remote_write 到水平扩展的时序库，不要一上来就堆集群。
Q：Grafana 面板越多越好吗？
不是。按“值班速查—业务概览—深度排障”三层组织面板，比堆满一屏更有用。
Q：告警发出后没人处理？
把每条告警绑定处置动作与责任人，定期做告警复盘，删除长期无人响应的规则。
相关阅读
把监控链路真正跑通
从采集端治理到告警收敛，每一步都可以在现有环境里小步验证。持续记录、持续复盘，监控才会越用越顺手。
返回首页