开头：为什么我要换监控
去年公司从传统IDC搬到K8s，监控系统得换。我之前用了5年Zabbix，管理着300多台物理机和虚拟机，自认为很熟。结果新来的架构师说必须上Prometheus，理由是云原生。我一开始很抵触，觉得Prometheus就是个半成品，连个像样的Web UI都没有。但硬着头皮搞了三个月，踩了无数坑，现在回头对比，发现两者根本不是同一类东西。如果你也在纠结，不妨看看我的真实经历。
数据模型：一个把标签当命，一个把键值当命
Zabbix是push/pull结合，但主要是agent主动上报，数据存关系型数据库。Prometheus是纯pull，所有指标都是时间序列，带标签。我刚开始把Zabbix的item概念往Prometheus套，结果发现label cardinality爆炸。举个例子，我监控Nginx的请求状态，Zabbix里一个item对应一个key，Prometheus里得用nginx_http_requests_total{status="200", instance="..."}，标签组合一多，内存直接飙到8G。后来才知道要控制标签数量，别超过10个。而且Zabbix的键值可以灵活用，但Prometheus的标签一旦定义就不能乱改，否则历史数据对不上。
存储与查询：MySQL的痛和TSDB的坑
Zabbix的housekeeper是噩梦。我们每天新增2000万条数据，MySQL的history表涨到500G，清理时锁表，监控界面卡死。后来上了分区表才勉强撑住。Prometheus用本地TSDB，默认保留15天，写性能好，但查询要学PromQL。我花了两个星期才搞懂rate()和irate()的区别。不过PromQL确实强大，可以算P99延迟，Zabbix得用计算项，很麻烦。另外Prometheus的存储是按块压缩，但如果你不设置retention，磁盘很快满。我一开始没设，结果一周就写了200G。
告警与扩展：触发器乱如麻，Alertmanager要耐心
Zabbix的触发器很直观，但配置多了以后，依赖关系乱成一团。Prometheus的Alertmanager支持分组、抑制、静默，但配置YAML容易缩进错。我有次把告警发到了测试群，被同事骂了一顿。扩展性方面，Zabbix Server是单点，虽然能加Proxy，但数据库是瓶颈。Prometheus可以联邦，可以Thanos，但架构复杂。我们最终选了Prometheus + Thanos，存了半年数据，查询慢但能接受。还有一点，Zabbix的自动发现对网络设备很友好，Prometheus得自己写exporter。
我的选择建议：别问哪个好，先看团队和场景
如果你的团队都是传统运维，不会写代码，别碰Prometheus。Zabbix的模板和自动发现能让你省心。但如果你的应用跑在K8s上，服务发现频繁变化，Zabbix的自动发现根本跟不上，Prometheus的Kubernetes SD才是救星。另外，Prometheus不适合做长期存储和审计，那是ELK的活。具体步骤：1. 统计监控对象数量，超过500台且动态变化，选Prometheus。2. 看团队技能，如果有人会Go或Python，选Prometheus。3. 如果必须用SQL查询历史数据，Zabbix。4. 如果预算有限，Zabbix开源版够用，Prometheus需要额外存储成本。5. 试试Grafana，两者都能接。
结尾：没有银弹，只有适不适合
我现在两个都在用，Zabbix监控网络设备（SNMP），Prometheus监控容器。没有银弹，只有适不适合。希望你别像我一样走弯路。最后说一句，开源软件最大的坑不是功能，而是文档和社区。Zabbix中文文档多，Prometheus英文文档多但更新快。遇到问题，先搜GitHub issue，比看官方文档管用。
