指标、Tracing 和基础设施监控回答“服务现在是否健康、请求慢在哪里、资源是否快耗尽”。本文不比较日志搜索、错误聚合和用户行为分析。
工具定位
| 方案 | 主要定位 | 适合场景 | 主要代价 |
|---|---|---|---|
| Prometheus | 指标采集与告警 | Kubernetes、服务发现和 PromQL | 长期存储与高可用要另行设计 |
| VictoriaMetrics | 高效指标存储 | 大规模指标、较低成本和长期保留 | 生态和运维模型需与现有 Prometheus 对接 |
| Grafana | 看板、查询和告警入口 | 组合多个指标、日志和链路后端 | 本身不是指标或日志存储 |
| Tempo | 分布式 Tracing 后端 | Grafana 生态和对象存储 | 深度分析依赖 Grafana 与采集链路 |
| Jaeger | 分布式 Tracing | OpenTelemetry、调用链排查和开发调试 | 长期存储与高可用需评估 |
| SigNoz | OpenTelemetry 一体化平台 | 日志、指标、Tracing 和应用性能统一观察 | ClickHouse 与平台运维有门槛 |
| Datadog | 托管基础设施与可观测性 | 不想维护多套监控后端 | 数据量、采样和套餐成本较高 |
Prometheus、VictoriaMetrics 与 Grafana
Prometheus 适合拉取服务指标、服务发现、PromQL 查询和规则告警，尤其适合 Kubernetes。它的本地存储并不是无限期指标仓库，生产环境要设计远端写入、保留周期、联邦或高可用方案。
VictoriaMetrics 主要解决高效指标存储和查询，可以作为 Prometheus 的远端存储或独立指标平台。它适合指标量较大、希望降低存储成本或延长保留周期的团队。
Grafana 负责看板、查询和告警编排，通常与 Prometheus、Loki、Tempo、Jaeger 或 VictoriaMetrics 组合。不要把 Grafana 单独当成完整监控后端。
Tempo 与 Jaeger：Tracing 后端
Tempo 更适合已经使用 Grafana、Loki 和 Prometheus 的团队，通常把 trace 放在对象存储中，并通过 trace ID 关联日志和指标。
Jaeger 是成熟的分布式 Tracing 系统，适合开发排障和 OpenTelemetry 接入。两者都需要提前设计采样、保留、敏感数据和高基数标签策略。
SigNoz 与 Datadog：一体化路线
SigNoz 以 OpenTelemetry 为主要采集路径，覆盖日志、指标、Tracing、查询、看板和告警，适合倾向自托管的团队，但要评估 ClickHouse、采集器资源和数据保留。
Datadog 把基础设施、指标、Tracing、日志和告警放在托管平台里，适合不想维护多套存储系统的团队。使用前要估算主机、容器、指标、日志、采样和保留周期成本。
怎么选
| 需求 | 优先考虑 |
|---|---|
| Kubernetes 指标、服务发现和规则告警 | Prometheus |
| 指标量大、希望降低长期存储成本 | VictoriaMetrics |
| 需要跨指标、日志和链路做看板 | Grafana |
| 已经采用 Grafana 生态并需要低成本 Tracing | Tempo |
| 需要成熟的调用链调试系统 | Jaeger |
| 希望自托管并统一 OpenTelemetry 信号 | SigNoz |
| 不想维护基础设施监控后端 | Datadog |
监控上线前检查
- 指标名称、标签和服务级别目标有统一约定；
- 高基数标签不会把时序数量推到不可控；
- Tracing 设置合理采样，并能与日志 request ID / trace ID 关联；
- 主机、容器、数据库和依赖服务有资源、错误率、延迟和饱和度指标；
- 告警包含影响范围、负责人、运行手册和恢复通知。
日志采集、全文检索和日志平台见日志采集与日志平台对比；错误堆栈、发布回归和 APM 见错误监控方案对比与应用性能监控方案对比。