监控工具对比：Prometheus vs Datadog vs CloudWatch vs Zabbix
「该选哪个监控工具？」——场景决定选择。
监控工具没有绝对的好坏，只有合不合适。Prometheus 是云原生的宠儿，Datadog 是 SaaS 的集大成者，CloudWatch 是 AWS 原住民，Zabbix 是传统运维的守护神。理解它们的差异，才能做出正确的选择。
整体对比
| 维度 | Prometheus | Datadog | CloudWatch | Zabbix |
|---|---|---|---|---|
| 部署模式 | 自托管 | SaaS（可选 Agent） | 云服务（AWS 原生） | 自托管 |
| 数据模型 | Pull（拉取） | Push（推送）+ Pull | Push（云自动采集） | Push（Agent 推送） |
| 指标存储 | 本地 TSDB | 云端（无限） | 云端（按量付费） | 本地 MySQL/PostgreSQL |
| 可扩展性 | Federation / Thanos | 自动扩展 | 自动扩展 | Proxy + Server |
| 告警 | AlertManager | 托管告警 | CloudWatch Alarms | 内置告警 |
| 可视化 | Grafana（集成） | 内置 Dashboard | 内置 Dashboard | 内置 + Grafana |
| 费用 | 开源免费 | 按主机/指标计费 | 按指标/查询计费 | 开源免费 |
| 适用场景 | K8s / 云原生 | 混合云 / 多云 | AWS 全家桶 | 传统 IT / 虚拟机 |
Prometheus：云原生监控王者
┌─────────────────────────────────────────────────────────────────┐
│ Prometheus 特点 │
│ │
│ 优势： │
│ ✓ 云原生友好（K8s 原生支持） │
│ ✓ 指标模型强大（多维标签 + PromQL） │
│ ✓ 生态丰富（Exporter 覆盖 90% 场景） │
│ ✓ 社区活跃（Prometheus Operator、Thanos） │
│ ✓ 成本低（自托管，硬件费用） │
│ │
│ 劣势： │
│ ✗ 需要额外配置实现长期存储（Thanos/Cortex） │
│ ✗ 高基数（Cardinality）挑战 │
│ ✗ 没有原生日志和链路追踪集成 │
│ ✗ 运维复杂度（对比 SaaS） │
└─────────────────────────────────────────────────────────────────┘适用场景
适合 Prometheus 的场景：
1. Kubernetes 集群监控（ServiceMonitor、PodMonitor 原生支持）
2. 微服务架构（多实例、多标签的聚合查询）
3. 预算有限但技术实力强的团队
4. 需要深度定制的监控（PromQL 灵活）
5. 多集群监控（Thanos Federation）
不适合 Prometheus 的场景：
1. 非技术人员自助监控（SaaS 更友好）
2. 需要监控 Windows（Exporter 支持弱）
3. 传统虚拟机为主（Ansible/Zabbix 更适合）
4. 只想快速上线，不想运维Datadog：SaaS 监控的全能选手
┌─────────────────────────────────────────────────────────────────┐
│ Datadog 特点 │
│ │
│ 优势： │
│ ✓ 开箱即用（无需运维） │
│ ✓ 一站式（指标 + 日志 + 链路 + APM） │
│ ✓ 集成丰富（200+ 集成） │
│ ✓ 无代理采集（Auto-instrumentation） │
│ ✓ 智能告警（异常检测、预测） │
│ ✓ 支持 Kubernetes、容器、Serverless │
│ │
│ 劣势： │
│ ✗ 费用高（按数据量计费，大流量项目费用惊人） │
│ ✗ 数据在云端（合规要求高的行业不适用） │
│ ✗ 定制化受限（比 Prometheus 灵活度低） │
│ ✗ 厂商锁定（迁移成本高） │
└─────────────────────────────────────────────────────────────────┘适用场景
适合 Datadog 的场景：
1. 多云/混合云环境（统一视图）
2. 快速迭代的团队（不想自己运维监控）
3. 需要 APM + 监控 + 日志联动（一体化体验）
4. 微服务 + 容器 + Serverless（Lambda 监控）
5. 合规要求不高（数据可放云端）
不适合 Datadog 的场景：
1. 预算有限（Datadog 费用可能超过基础设施本身）
2. 数据敏感（金融、医疗、政府）
3. 大规模 K8s（100+ 节点，Datadog 成本爆炸）
4. 定制化需求强（Prometheus + Grafana 更灵活）CloudWatch：AWS 原住民
┌─────────────────────────────────────────────────────────────────┐
│ CloudWatch 特点 │
│ │
│ 优势： │
│ ✓ AWS 原生集成（EC2、Lambda、RDS、ECS...） │
│ ✓ 无需部署（AWS 自动采集） │
│ ✓ Serverless 监控（Lambda 指标自动推送） │
│ ✓ 告警 + Auto Scaling 联动 │
│ ✓ 费用透明（按需付费） │
│ │
│ 劣势： │
│ ✗ 跨云困难（不擅长 GCP/Azure） │
│ ✗ 指标粒度粗（1 分钟最小，高级指标额外收费） │
│ ✗ 无 APM（需要 X-Ray 单独集成） │
│ ✗ Dashboard 功能弱（Grafana 更好用） │
│ ✗ 自定义指标费用高 │
└─────────────────────────────────────────────────────────────────┘适用场景
适合 CloudWatch 的场景：
1. AWS 全家桶（EC2 + Lambda + RDS + ECS）
2. Serverless 为主（Lambda 监控）
3. 快速搭建监控（不想运维）
4. AWS Auto Scaling + 告警联动
不适合 CloudWatch 的场景：
1. 多云或混合云（需要统一视图）
2. 细粒度监控（1 分钟粒度不够）
3. 大规模 Kubernetes（CloudWatch Container Insights 支持有限）
4. 深度 APM（需要 X-Ray 配合，不够原生）Zabbix：传统运维的守护神
┌─────────────────────────────────────────────────────────────────┐
│ Zabbix 特点 │
│ │
│ 优势： │
│ ✓ 企业级（15+ 年历史，大量生产案例） │
│ ✓ 功能全面（监控 + 告警 + 自动发现 + LLD） │
│ ✓ 支持网络设备（SNMP、IPMI） │
│ ✓ Windows 监控支持好 │
│ ✓ 模板丰富（开箱即用） │
│ ✓ 完全开源（无供应商锁定） │
│ │
│ 劣势： │
│ ✗ 不适合云原生（K8s 支持弱） │
│ ✗ 配置复杂（学习曲线陡） │
│ ✗ 性能有限（大规模场景需要分库分表） │
│ ✗ 没有现代 APM（指标 + 日志 + 链路分离） │
│ ✗ UI 古老（2020 年才改版） │
└─────────────────────────────────────────────────────────────────┘适用场景
适合 Zabbix 的场景：
1. 传统 IT（虚拟机、物理机、网络设备）
2. 混合架构（K8s + 物理机混合）
3. 需要 SNMP 监控（路由器、交换机、UPS）
4. 企业内部 IT 部门（合规要求高）
5. 预算有限但需要企业级功能
不适合 Zabbix 的场景：
1. 云原生为主（K8s 监控用 Prometheus）
2. 微服务架构（Zabbix 的服务发现不如 Prometheus）
3. 大规模 Kubernetes（超过 1000 个 Pod）
4. 需要 APM（Zabbix 不做链路追踪）选型决策树
┌─────────────────────────────────────────────────────────────────┐
│ 监控工具选型决策树 │
│ │
│ ┌─────────────────────┐ │
│ │ 你主要监控什么？ │ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌────────────────────┼────────────────────┐ │
│ │ │ │ │
│ ┌────▼────┐ ┌─────▼────┐ ┌─────▼────┐ │
│ │ K8s │ │ 虚拟机 │ │ 云服务 │ │
│ │ 为主 │ │ 为主 │ │ AWS 为主 │ │
│ └────┬────┘ └─────┬────┘ └─────┬────┘ │
│ │ │ │ │
│ ┌────▼────┐ ┌─────▼────┐ ┌─────▼────┐ │
│ │ 技术强？ │ │ Windows？ │ │ 多云？ │ │
│ └────┬────┘ └─────┬────┘ └─────┬────┘ │
│ │ │ │ │
│ ┌────▼────┐ ┌─────▼────┐ ┌─────▼────┐ │
│ │ 是 │ │ 是 │ │ 是 │ │
│ └────┬────┘ └─────┬────┘ └─────┬────┘ │
│ │ │ │ │
│ ┌────▼────┐ ┌─────▼────┐ ┌─────▼────┐ │
│ │Prometheus│ │ Zabbix │ │ Datadog │ │
│ │+Thanos │ │ │ │ │ │
│ └─────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────┘组合使用
常见组合：
1. Prometheus + Grafana + AlertManager（K8s 监控）
→ 云原生场景，免费开源
2. Datadog（监控 + APM + 日志）
→ 多云混合场景，一站式服务
3. Zabbix（基础设施）+ Prometheus（K8s）
→ 混合架构，传统 IT + 容器
4. CloudWatch + Grafana（Dashboard）
→ AWS 全家桶
5. Prometheus（K8s）+ Zabbix（VM）
→ 预算有限的多平台方案
推荐原则：
- K8s 用 Prometheus（原生支持好）
- 虚拟机用 Zabbix 或 Prometheus Node Exporter
- 云服务用对应云厂商的监控
- 混合云用 Datadog 或 Prometheus Federation面试追问方向
Prometheus 和 Datadog 的核心区别是什么？ 答：Prometheus 是 Pull 模型，自托管，指标存储在本地，需要额外配置长期存储；Datadog 是 SaaS，Push + Pull 模型，数据无限存储，开箱即用但费用高。Prometheus 灵活但运维重；Datadog 省心但贵且有厂商锁定风险。
为什么 Kubernetes 监控首选 Prometheus？ 答：Prometheus 的服务发现机制和 Kubernetes API 无缝集成，ServiceMonitor/PodMonitor 可以自动发现监控目标，Pod 漂移后自动更新配置。Prometheus Operator 进一步简化了配置管理。相比之下，Zabbix 的 K8s 支持需要手动维护，Datadog 费用在大规模集群场景下很高。
Prometheus 的 Federation 和 Thanos 有什么区别？ 答：Federation 是 Prometheus 官方方案，让全局 Prometheus 抓取多个子 Prometheus 的指标，实现跨集群聚合；Thanos 是第三方扩展，通过 Sidecar 将数据写入对象存储，实现无限历史存储和全局视图。Federation 适合简单场景；Thanos 适合大规模长期存储需求。
什么时候选择 Zabbix 而不是 Prometheus？ 答：当监控对象以虚拟机、物理机、网络设备为主时，Zabbix 的自动发现（LLD）和 SNMP 支持更成熟；当团队运维能力强且预算有限时，Zabbix 完全免费；当需要 Windows 监控时，Zabbix Agent 支持更好。
监控工具没有最好的，只有最合适的。理解每个工具的适用场景，才能做出不后悔的选择。