theme: default themeName: "默认主题" title: "从0到1搭建企业监控体系：一个运维老兵的Prometheus+Grafana踩坑记"
做运维这行十二年，监控体系搭了不下十套。从最早的Nagios到Zabbix，再到如今的Prometheus，踩过的坑能装一箩筐。今天不搞虚的，把这几年真金白银换来的经验掰开了揉碎了讲。
监控选型：为什么我最终抛弃了Zabbix
2019年之前，Zabbix几乎是国内监控的代名词。我也不例外，Zabbix用了整整六年。但真正让它在我手里“失宠”的，不是功能问题，是架构问题。
先说Zabbix的优点：模板丰富、界面友好、告警机制成熟。这些没得黑。但当你服务器规模突破500台，监控指标超过10万点位时，问题就来了——Zabbix那套MySQL存储+Agent拉取的模式，查询开始变慢，磁盘IO成了瓶颈。更要命的是，Zabbix的自动发现机制在容器环境里几乎废掉，你需要写各种脚本来适应动态伸缩的场景。
Prometheus不一样，它是为云原生而生的。拉取模式（Pull-based）天然适配动态环境，容器起来了metrics接口就暴露出来，Prometheus自动就能采集。而且PromQL那种查询语言，对我们这种需要做聚合分析、趋势预判的运维来说，简直是神器。
当然，Prometheus不是银弹。它不擅长那种需要保存多年历史数据的场景，也不适合监控网络设备（SNMP支持需要额外组件）。我的建议是：短期高频指标用Prometheus，历史归档和网络设备监控可以用Zabbix或者VictoriaMetrics做长期存储。两者结合，才是正解。
Prometheus部署：从单机到高可用，我走过的弯路
一开始我把Prometheus装在单机上，极其简单——一个二进制文件，一份配置文件，启动完事。这种方式支撑了我大概半年，直到有一次服务器硬盘故障，监控数据全丢，告警也没发出去。那一刻才意识到，监控自身的高可用有多重要。
后来改成分布式方案。我的线上环境用的是 Thanos + Prometheus 的组合拳。简单说就是多个Prometheus实例分别采集不同业务的数据，然后通过Sidecar把数据上传到对象存储（S3兼容），Thanos Query 做统一查询，Thanos Compact 做压缩和降采样。
这套架构跑了两年，没出过大问题。但说实话，对于中小规模团队（50台服务器以内），完全没必要搞这么复杂。简单的高可用方案是：两台Prometheus实例，互为冗余，用Keepalived做VIP漂移。告警规则两边各配一份，任何一台活着，告警就 能发出去。
有个坑必须提：Thanos的存储桶配置很容易出错。最常见的问题是权限不对，或者endpoint写错了。建议先用minio本地测试通过了再上生产。另外，压缩任务（Compact）会占用大量CPU和IO，建议放在业务低峰期执行，或者干脆用CronJob定时跑。
Exporter配置：这些坑踩一次就够了
Prometheus生态里，Exporter就是“数据采集员”。官方维护的比如node_exporter、blackbox_exporter、cadvisor，用起来相对省心。但第三方Exporter质量参差不齐，有些文档写得跟天书一样。
说几个我踩过的坑：
第一个坑是nginx_exporter。
这玩意儿默认只监听一个URL路径，但实际场景中nginx可能运行了多个instance，每个instance的stub_status路径都不一样。我当时没仔细看文档，配置了全局一个URL，结果一半服务器数据是空的。解决方案是用nginx_exporter的--web.config参数做多个target的relabel。
第二个坑是MySQL Exporter的连接池。
默认配置下，MySQL Exporter会为每个指标查询都建立新连接，高并发时直接把数据库连接数打满。正确做法是在mysqld_exporter的collector配置里启用连接池，并设置合理的max_open_conns参数。
第三个坑是Kubernetes监控。
kube-state-metrics是个好东西，但它采集的数据量巨大，新手很容易被数据量吓到。我的经验是：先用--apiserver-labels过滤掉不需要的标签，只保留namespace、pod、deployment这些核心标签。数据量能减少70%。
还有一点提醒：所有Exporter都建议用容器方式部署，统一用Docker或者K8s管理。手动安装的话，后续迁移和版本升级都是噩梦。
Grafana仪表盘：别再堆数字了，看看业务吧
Grafana可能是整条链路上最“好看”的组件，但也是最容易做成花瓶的。我见过太多仪表盘，密密麻麻全是图表和数字，业务方一眼看过去根本不知道该关注什么。
我的设计原则是：从业务视角出发，而非技术视角。
什么意思？不要按“CPU、内存、网络、磁盘”来分组，而是按“订单系统、支付系统、用户中心”来分组。每个业务域用一张大屏，关键指标用醒目的数字卡片展示，异常状态用颜色区分。
颜色也是有讲究的：绿色代表正常，黄色代表预警，红色代表告警。但很多仪表盘做得花里胡哨，颜色滥用，结果看的人眼花。我建议统一用Grafana的阈值（Thresholds）功能，设置明确的值域和对应颜色，一目了然。
仪表盘的层级也重要。顶层是全公司看的“驾驶舱”，只放5-8个核心指标；中层是部门看的业务域详情；底层是技术团队用的详细排查界面。各层之间用变量（Variables）做钻取，点击就能跳转。
最后说个很多人忽略的问题：仪表盘的刷新频率。实时性要求高的监控（比如大促期间）可以设成5秒一次，但日常环境30秒甚至1分钟都行。刷新越频繁，浏览器端GPU占用越高，大屏服务器容易烫手。
告警规则：别让你的告警成为噪音
告警是监控的核心价值。但告警做不好，分分钟变成“狼来了”的故事——收太多了，麻木了，真正出问题反而看不到。
我的第一条原则是：告警必须有明确的动作指向。 “CPU使用率高于80%”这种告警毫无意义，你知道了然后呢？改成“CPU持续15分钟高于80%，且业务响应时间上升超过50%”，这才有意义。
第二条原则是：分级告警，避免告警疲劳。 我们分四级：Info、Warning、Critical、Emergency。Info和Warning走企业微信和邮件，Critical走电话和短信，Emergency直接打电话给值班负责人。每个级别有独立的静默期（Silence），避免同一问题反复报警。
第三条原则是：告警抑制和聚合。 这一点在微服务架构里特别重要。比如数据库告警了，上层服务的响应时间告警应该被抑制，因为根因在数据库，修了数据库上层自然恢复。Prometheus的alerts里用group_by和continue参数可以实现这个逻辑。
还有一个实战技巧：给告警加“预热期”。新上线的告警规则，先设成Warning级别，观察一周没问题再升到Critical。这样能避免误报导致的虚惊一场。
写在最后
监控体系建设没有标准答案，合适的才是最好的。从选型到落地，每一步都有坑，趟过去了就是经验。这套Prometheus+Grafana的组合拳，我打了三年，整体满意。如果你正在考虑监控方案，希望这篇文章能帮你少走弯路。
有问题随时找我聊，运维这条路上，互相踩坑才能走得更稳。
【放心，我们兜底】
不管你是自己尝试修复，还是需要专业人员上门，易云城IT服务都给你托底。修不好不收费，修好了质保期内随时找我。
📞 服务热线：13708730161 💬 微信：eyc1689 📧 邮箱：service@eycit.com 🌐 https://www.eycit.com
您身边的IT专家。