一、核心优势
1. 原生适配云原生、容器 / K8s
- 内置多种服务发现：Kubernetes、DNS、Consul、文件、静态配置，容器扩缩容自动识别监控目标，不用手动维护主机列表。
- 标签（Label）多维数据模型，区分集群、命名空间、实例、接口，适合微服务多环境拆分统计。
2. 架构轻量化、部署简单
- 单二进制文件运行，自带时序数据库，无需依赖 MySQL、PostgreSQL 等外部数据库，单机开箱即用。
- 无复杂中间件，资源占用低，中小集群单实例即可支撑。
3. Pull 拉取模型，分布式友好
- 监控服务主动拉取指标，被监控端只暴露
/metricsHTTP 接口，业务侵入极小。 - 服务宕机、网络隔离时 Prometheus 仅采集失败，不会影响业务程序运行。
- 配合 PushGateway 兼容一次性任务、批处理脚本场景。
4. 强大灵活的 PromQL 查询语言
- 内置速率、聚合、分位数、环比、阈值判断函数，不用写复杂 SQL 就能计算错误率、P95/P99 延迟、CPU 使用率。
- 支持瞬时查询、区间查询，同时满足告警规则与 Grafana 绘图需求。
5. 完善生态，几乎全覆盖监控对象
官方 / 社区大量 Exporter：服务器、数据库、中间件、网关、硬件、API 拨测； 各语言官方埋点 SDK（Go/Java/Python/JS），业务代码轻松自定义业务指标。
6. 独立告警体系，能力成熟
AlertManager 单独解耦告警逻辑，支持告警分组、抑制、静默、路由分流，对接钉钉、企业微信、短信、邮件等。
7. CNCF 毕业项目，社区活跃
行业事实标准，文档、教程、开源大盘模板极多，企业生产广泛落地，人才储备充足。
8. 高可用拓展方案成熟
搭配 Thanos / Mimir 实现集群、长期存储、分片、全局查询，可支撑大规模上万节点集群。
二、明显劣势 & 局限性
1. 只适合指标（Metrics），不处理日志、链路追踪
- 仅存储数值型时序指标，不能收集日志，日志需要搭配 ELK/Loki；
- 无分布式追踪能力，链路追踪要配合 Jaeger、Zipkin，完整可观测需要三套组件组合。
2. 本地存储有短板，长期存储成本高
- 单机内置存储默认仅保留 15 天～90 天 数据，不适合数年长期留存；
- 原生不支持集群分片、远程持久化，做大容量历史数据必须额外部署 Thanos/Mimir，增加运维复杂度。
3. Pull 模型有场景短板
- 跨防火墙、内网隔离、边缘设备很难直接拉取，需要中转网关；
- 短生命周期临时 Pod、一次性脚本原生不友好，必须依赖 PushGateway。
4. 不擅长高基数标签场景
标签维度爆炸（上万不同 value）会导致内存暴涨、查询卡顿，极易引发 OOM，需要提前做指标裁剪、聚合。
5. 自带可视化简陋，依赖第三方 Grafana
Prometheus 自带 WebUI 仅用于调试查询，没有仪表盘、图表、权限管理，生产必须配套 Grafana，多一套组件维护。
6. 告警功能存在短板
- 无内置告警图表、告警趋势分析；
- 缺少复杂业务关联告警能力，无法基于多指标联动做复杂判断；
- AlertManager 不支持告警工单、自动修复，需要对接外部系统。
7. 无内置资产、拓扑、自动巡检
不像 Zabbix 自带主机管理、自动发现硬件、模板监控；Prometheus 只负责采集存储，资产管理、拓扑图需自行开发或搭配其他工具。
8. 高并发写入性能有上限
单实例 Prometheus 抓取上万 targets 时，CPU、内存压力陡增，必须分片拆分多实例，架构复杂度上升。
9. 不适合事件、文本类监控数据
只存数字，无法存储报错详情、文本事件，异常文本信息要交给日志系统。
三、简明对比总结（快速记忆）
适合选用 Prometheus
- Kubernetes、微服务、云原生环境
- 服务器、中间件、业务性能指标监控
- 需要灵活自定义业务指标、精细化告警
- 中小集群、轻量化快速部署场景
不适合单独只用 Prometheus
- 传统机房大量物理机、需要一体化资产运维
- 长期存储数年监控数据且不想额外部署组件
- 需求统一收集日志、链路追踪、指标三合一
- 大量边缘隔离设备、一次性短任务为主的场景
Prometheus + Grafana + Loki 完整可观测架构部署方案。