选一个能打开的望远镜

三大类后端

Jaeger:开源 trace 老牌

• Uber 开源,CNCF Graduated
• Trace 存储可选 Cassandra / Elasticsearch / ClickHouse / Badger(本地)
• V2 架构直接基于 OTel Collector,天然兼容 OTLP
• UI 简单够用,但面板自定义弱
• 适合:只要 trace、成本敏感、小到中规模

# 10秒起一个 all-in-one(仅开发/测试)
docker run -d --name jaeger \
  -p 16686:16686 -p 4317:4317 -p 4318:4318 \
  jaegertracing/all-in-one:latest

浏览器打开 localhost:16686——就这么简单。生产环境要用 Jaeger Collector + Query 拆分部署。

Tempo:Grafana 的 trace 后端

• Grafana Labs 开源,专门为 OTel 设计
• 存储只用对象存储(S3 / GCS / Azure Blob)——便宜到离谱
• 不建索引,靠 trace_id 直查 + TraceQL 查询语言(2.0+)
• 和 Grafana + Loki + Mimir 原生联动,三向跳转丝滑
• 适合:已在 Grafana 生态,想降低 trace 存储成本

Prometheus:Metric 事实标准

• CNCF Graduated,生态大到不可逾越
• OTLP receiver 在 Prometheus 3.0+ 内置——可直接接 OTel SDK
• 长期存储(> 7 天)需要 Mimir / Thanos / Cortex / VictoriaMetrics
• 高基数是老大难,OTel Metrics 的 attribute 滥用立刻爆炸
• 适合:所有场景——几乎是 metric 的默认选

Mimir:Grafana 的长保留 Prom

Mimir = 水平扩展的 Prometheus。多租户、对象存储、千万级 series。接 OTel 的方式是 Collector 用 prometheusremotewriteexporter。

Loki:轻量日志

• Grafana Labs 出品,设计理念「像 Prom 一样对日志标签索引,不索引正文」
• 成本只有 Elasticsearch 的 1/10
• 查询语法 LogQL,和 PromQL 同源
• 弱点:全文检索能力有限(但够用),高基数标签同样要小心

Grafana LGTM stack

L oki      — Logs
G rafana   — UI
T empo     — Traces
M imir     — Metrics

官方推的自建开源组合,加上 OTel Collector 做接入层——全开源 + 成本可控 + 三向跳转原生支持。GitOps 化部署在 K8s 里 Helm chart 很成熟。

Elasticsearch / OpenSearch

• 老牌日志方案,OpenSearch 是 AWS 分叉版
• Collector 的 elasticsearch exporter 直接能发
• 全文检索 + 聚合能力最强
• 运维重、成本高、存储吃紧——但全文搜索不可替代

SigNoz / Uptrace:后起之秀

两个开源的"三合一"方案——ClickHouse 做存储,trace+metric+log 一个 UI,特点:

• 原生 OTLP 接入,不像 Jaeger+Prom+Loki 要拼三个
• ClickHouse 存储,高压缩比,成本低
• UI 更现代,有 service map、anomaly detection 等商业级功能
• 适合「不想用 Grafana,想要一站式开源」

Datadog:商业之王

• 行业事实标准 SaaS,APM / Metric / Log / Profiling / RUM 一应俱全
• 原生接收 OTLP(Collector 的 datadog exporter 或直接 HTTP)
• UI 和面板是最好的之一——AI 辅助根因分析 "Watchdog"
• 贵——host based 定价,100 台机器 $2000/月 起步;custom metric 再另收
• 适合:规模大、愿意花钱、不想养 SRE 团队

New Relic

• 老牌 APM,近年全面拥抱 OTel
• 按数据量计费(GB 为单位),对突发流量友好
• UI 有一点学习曲线,但完备
• 适合:预算比 Datadog 紧一档

Honeycomb

• 高基数观测性的扛旗者,Charity Majors 推动
• 数据模型就是宽表 event,查询超快
• BubbleUp(自动找异常维度)体验一流
• 完全 OTel-native(公司自己用 OTel)
• 适合:高基数场景(大量不同 user.id 的 attribute),愿付更高单价换查询体验

Dynatrace / Splunk Observability

企业级选型——Dynatrace 以 AI 自动根因分析著称,Splunk 以海量日志 + SIEM 见长。都原生支持 OTLP,价格不透明,适合已有商业合作的大厂。

对比矩阵

	覆盖	成本	UI	运维	适合
Jaeger+Prom+Loki	基础三合一	$	Grafana	重	成熟 K8s 团队
Grafana LGTM	完整	$	Grafana ⭐	中	开源一站式
SigNoz / Uptrace	完整	$	专属 UI	轻	不想自己拼
Datadog	完整 + 更多	$$$	⭐⭐⭐	零	大厂土豪
New Relic	完整	$$	⭐⭐	零	中大厂
Honeycomb	trace 为主	$$	⭐⭐⭐	零	高基数场景
Grafana Cloud	LGTM + 托管	$ → $$	Grafana ⭐	零	中小团队

切换后端:成本几何?

OTel 的核心卖点:代码零改动,只改 Collector exporter 配置:

# 昨天:发 Datadog
exporters:
  datadog:
    api:
      key: ${env:DD_API_KEY}
service:
  pipelines:
    traces:
      exporters: [datadog]

# 今天:换 Honeycomb(应用一行代码没改)
exporters:
  otlp/honeycomb:
    endpoint: api.honeycomb.io:443
    headers:
      x-honeycomb-team: ${env:HC_KEY}
service:
  pipelines:
    traces:
      exporters: [otlp/honeycomb]

# 或者:同时发俩做对比
    traces:
      exporters: [datadog, otlp/honeycomb]

双发一段时间再下决定——这是 OTel 的最大 POC 优势。

成本控制技巧

混合模式

自建 vs SaaS 决策框架

维度	偏自建	偏 SaaS
数据规模	> 10TB/月 日志	< 1TB/月
SRE 人力	>= 3 人专职	< 1 人
合规	数据不能出公司	允许送云
迭代速度	愿等 3-6 月搭稳	明天就要看
成本曲线	初投大,边际低	初投小,线性涨

Grafana 三向跳转配置

Trace(Tempo)→ 点 span → Logs(Loki):按 trace_id 过滤
Logs(Loki)→ 点 trace_id → Trace(Tempo):打开这条 trace
Metric(Mimir)→ 点 Exemplar → Trace(Tempo):这一点的原始 trace

前提:
- 三路数据都有 service.name + trace_id + span_id
- Grafana 数据源里配好 derivedFields(Loki 认识 trace_id 格式)
- Exemplar 在 Prom 3.0+ 默认开启,SDK 侧启用 exemplar filter

本章小结