Observability 2025 完全指南：OpenTelemetry、Grafana / Datadog / Honeycomb / SigNoz、SLO 与 Error Budget、LLM 可观测性（2025）

Season 5 Ep 8 — 如果说治理是“管理”，那么可观测性就是 “把握现实”。2025 年的 Observability 不止步于 Log、Metric、Trace，还把 LLM、数据管道、用户体验 一并纳入。

Prologue — “可观测性不是保险，而是产品”
第 1 章 · 三大信号 + α
第 2 章 · OpenTelemetry — 标准的成熟
第 3 章 · Grafana 技术栈（开源）
第 4 章 · Datadog、New Relic、Splunk、Dynatrace — SaaS 巨头
第 5 章 · 新世代 — Honeycomb、SigNoz、Axiom、Tinybird
第 6 章 · Logs、Metrics、Traces 的落地实践
第 7 章 · SLO、SLI、Error Budget
第 8 章 · LLM Observability（Ep 6 的延长）
第 9 章 · 混沌工程与韧性
第 10 章 · 告警、值班、事故响应
第 11 章 · 成本优化
第 12 章 · 韩国企业的可观测性
第 13 章 · 十大反模式
第 14 章 · 检查清单 — 可观测性上线前的 12 项
第 15 章 · 下期预告 — Season 5 Ep 9：“数据团队的组织与职业发展”

Prologue — “可观测性不是保险，而是产品”

2015–2020 年，很多团队把可观测性当成“事故响应用的保险”。2025 年不一样了：

抢先发现用户的问题 = 竞争优势
基于 SLO 的运营 = 开发速度与稳定性兼得
观测数据本身就是 产品决策的依据
对 LLM 产品来说，“产出是否正确”本身成了观测对象

“可观测性是成本”的时代结束了。“可观测性是产品质量的一部分”才是 2025 年的标准。

第 1 章 · 三大信号 + α

1.1 基本三种

Metric：时序数值（CPU、QPS、延迟）
Log：事件文本
Trace：分布式请求的路径

1.2 扩展信号

Profile：CPU、内存的剖析（continuous profiling）
Event：业务、部署、发布事件
RUM (Real User Monitoring)：浏览器与移动端用户的体感
Synthetic：周期性的虚拟请求
LLM 事件：提示词、回答、token、成本、反馈

1.3 关联（Correlation）

Metric 出现尖峰时，跳到该时刻的 Trace 与 Log
User session → Trace → Log 的串联
这是 2025 年各家工具的基本 UX

第 2 章 · OpenTelemetry — 标准的成熟

2.1 它是什么

2019 年的 CNCF 项目（OpenCensus + OpenTracing 合并）
Metric、Trace、Log、Profile（2024）的标准
厂商中立的采集管道

2.2 结构

SDK：分语言（Python/Go/JS/Java/Rust 等）
Collector：采集、处理、路由
OTLP 协议：gRPC/HTTP
Exporter：Prometheus、Datadog、Grafana、New Relic 等

2.3 为什么重要

去除厂商锁定：代码是 OTel，后端可以更换
2024–2025 年大多数可观测性厂商都原生接纳了 OTel
用 Semantic Conventions 标准化元数据（HTTP、DB、消息）

2.4 落地难度

基础采集很简单，但是
Semantic Conventions、Sampling、成本调优需要专业性
整合过去碎片化的 Metric/Log 体系才是难题

第 3 章 · Grafana 技术栈（开源）

3.1 组成

Prometheus（Metric）：标准方案，大规模时用 Mimir/Thanos/VictoriaMetrics
Loki（Log）：“只给元数据建索引”的设计，成本低
Tempo（Trace）：支持 OTel，存储便宜
Grafana（UI）：统一仪表盘
Pyroscope（Profile）：2023 年收购，持续剖析

3.2 Grafana Cloud

上述技术栈的托管 SaaS
有 Free tier，付费按用量计费
中型企业性价比不错的选择

3.3 优势

开源的自由度 + 统一的 UX
成本高效（日志与追踪的存储）
社区规模大

3.4 局限

自运维需要管理多个组件，负担不小
达不到 Datadog 那种“all-in-one”的体验

第 4 章 · Datadog、New Relic、Splunk、Dynatrace — SaaS 巨头

4.1 Datadog

业界第一，600 多个集成
Infrastructure、APM、Logs、RUM、Security、LLM Observability 全都有
成本是最大的抱怨（同时也是它营收增长的来源）

4.2 New Relic

2020 年重新设计（NRDB）以统一信号
2022 年变更定价模型（按数据 → 按用户）
对 Kubernetes 与 OTel 友好

4.3 Splunk

日志与安全的强者，2023 年被 Cisco 收购
面向企业与安全场景
正在整合 Observability Cloud（AppD、SignalFx）

4.4 Dynatrace

基于自动化与 AI（Davis）
面向企业级、大规模复杂系统

4.5 对比

工具	优势	劣势
Datadog	一体化	成本
New Relic	价格透明	功能分散
Splunk	日志与安全	成本与复杂度
Dynatrace	自动化	学习曲线
Grafana Cloud	性价比	一体化体验

第 5 章 · 新世代 — Honeycomb、SigNoz、Axiom、Tinybird

5.1 Honeycomb

引领 high-cardinality 与探索型观测
BubbleUp（自动相关性分析）
对工程文化影响很大（Charity Majors）

5.2 SigNoz

开源的 Datadog 替代品
基于 ClickHouse
自托管以降低成本

5.3 Axiom

无服务器日志，极低成本的存储
以事件与分析为中心
在社区和个人项目里很受欢迎

5.4 Tinybird

ClickHouse 的 API-first
实时分析与面向用户的指标
并非专门做可观测性，但工作负载类似

5.5 OpenObserve

开源的全栈方案
成本上基于 ClickHouse

5.6 共同点

支持 OTel
基于 ClickHouse/Parquet 的低成本存储
支持 Kafka、Kinesis

第 6 章 · Logs、Metrics、Traces 的落地实践

6.1 Metric 设计

RED（Rate、Errors、Duration）for services
USE（Utilization、Saturation、Errors）for resources
Golden signals（Latency、Traffic、Errors、Saturation）
注意高基数标签（Prometheus 会失控）

6.2 Log 设计

结构化日志（JSON）
包含 Trace ID、Span ID、User ID
等级（DEBUG/INFO/WARN/ERROR）保持一致
敏感信息脱敏

6.3 Trace 设计

每个 Service boundary 都打 span
自动埋点 DB 与外部 API 调用
用 Sampling（Head、Tail）管理成本
包含 Business attribute（org、plan）

6.4 RUM

浏览器：Web Vitals（LCP、CLS、INP）
移动端：启动时间、崩溃、网络
关联用户 ID、版本、设备

6.5 Synthetic

主要路径 1–5 分钟一次
按区域做检查
验证多步骤工作流（登录→支付）

第 7 章 · SLO、SLI、Error Budget

7.1 概念

SLI（Service Level Indicator）：测量指标（可用性、延迟）
SLO（Service Level Objective）：目标（99.9% 可用性）
Error Budget：允许的失败量（每月 43 分钟）

7.2 为什么重要

100% 既不可能也不经济
在发新功能与稳定性之间做科学的平衡
团队之间的共同语言

7.3 实战指标

可用性：成功请求 / 总请求
延迟：落在 p95/p99 阈值内的比例
正确性：结果错误率
新鲜度：数据延迟时间
LLM 质量：评测集分数（Ep 6）

7.4 Error Budget 政策

预算耗尽就冻结功能发布 → 转做稳定性工作
预算有富余就积极发布、积极实验

7.5 工具

Grafana SLO、Datadog SLO、Nobl9、Blameless
Prometheus + Sloth（OSS）
月度与季度复盘是必需的

第 8 章 · LLM Observability（Ep 6 的延长）

8.1 追加的信号

提示词与回答的文本
token 与成本
Latency 与 TTFT（Time to First Token）
评测集分数与用户反馈
工具调用与智能体的 step

8.2 主要工具

LangFuse（开源 + SaaS）
LangSmith（LangChain）
Phoenix/Arize
Helicone
Weights & Biases Weave
Traceloop（基于 OpenLLMetry）
Datadog LLM Observability（2024）

8.3 OpenLLMetry

作为 OpenTelemetry 的扩展，标准化 LLM 的语义约定
2024 年由 Traceloop 主导启动 → 2025 年 OTel 标准化的讨论很活跃

8.4 运营模式

提示词 A/B 与 Canary（Ep 11）
评测集定期执行 + 回归告警
把用户反馈接回来的闭环
成本与 token 的仪表盘

第 9 章 · 混沌工程与韧性

9.1 哲学

故障不可避免 → 主动制造出来去学习
起源于 2010 年 Netflix 的 Chaos Monkey

9.2 工具

Gremlin、LitmusChaos（K8s）、Steadybit
AWS Fault Injection Service
Chaos Toolkit

9.3 实战

Game Day（一个团队复现故障，其余团队负责响应）
Runbook 测试
验证恢复机制（熔断、重试、降级）

9.4 在数据管道上的应用

Kafka 分区中断时
DB 故障切换时
一个引擎宕机时

9.5 2025 趋势

Resilience as code：把混沌场景用代码来管理
CI 集成：发布前先做恢复测试

第 10 章 · 告警、值班、事故响应

10.1 告警设计

Symptom-based：基于用户影响（5XX 上升）
避免 Cause-based：给每个原因都配告警只会变成噪音
Severity（P1/P2/P3）
限流与抑制

10.2 值班文化

轮换以周为单位
Primary 与 Secondary
补偿与休息政策

10.3 事故响应

Detect → Triage → Mitigate → Resolve → Learn
沟通渠道（专用的 Slack 房间）
客户沟通（Status page）

10.4 Postmortem

Blameless
Timeline、Root cause、Action items
公开（内部）与归档保存

10.5 工具

PagerDuty、Incident.io、FireHydrant、Rootly
Slack、MS Teams 集成
关联 Jira、Linear（追踪行动项）

第 11 章 · 成本优化

11.1 日志成本

通过结构化与字段分类来挑选要存的内容
低价存储（ClickHouse、Loki）
长期归档（S3 Glacier）
敏感信息已经脱敏

11.2 Metric 成本

管理标签基数
优化 Scrape interval
Aggregation rules

11.3 Trace 成本

Head sampling 取 1–10%
Tail sampling（优先保留错误与慢请求）
自动 dropping（排除 health check）

11.4 SaaS 成本

注意按用量计费模型的暴涨
月度复盘 + 预算告警
考虑开源替代方案

11.5 现实目标

可观测性成本 / 基础设施成本 = 5–15% 比较常见
超过 20% 就是需要优化的信号

第 12 章 · 韩国企业的可观测性

12.1 现状

大企业：Datadog、Dynatrace、Splunk + 自建
互联网公司：Grafana 技术栈、自运维 Prometheus + 部分 SaaS
创业公司：Grafana Cloud、Datadog、Axiom 混用
金融与公共部门：本地部署的 Elastic、Splunk、Prometheus

12.2 LLM 可观测性的落地

2024 年开始，2025 年急剧扩大
自托管开源的 LangFuse
自建的案例（Toss、Kakao、Naver）

12.3 韩国的特殊性

网络隔离环境下要求全量本地部署
韩语的日志与告警文案
节假日与周末的值守文化
金融监督院的审计要求

12.4 参考案例

Coupang：自研可观测性平台 + 开源混用
Naver：大规模 Elastic + 自研 APM
三星、LG、SK：企业级工具 + SI 实施
Toss：引领基于 SLO 的运营文化

第 13 章 · 十大反模式

13.1 “上线之后再加可观测性”

从一开始就埋点才有价值。

13.2 所有日志都打 DEBUG

成本暴涨，重要信号被淹没。

13.3 告警刷屏

每个错误都告警 → 告警无视综合症。

13.4 没有 SLO 的运营

变成“开发 vs 稳定性”的政治纷争。

13.5 没有 Trace 就分析故障

花掉好几个小时，还是不知道原因。

13.6 高基数的 Metric 标签

Prometheus 会失控。

13.7 日志里放敏感信息

审计问题与泄露事故。

13.8 没有 Postmortem，同样的事故反复发生

缺少学习闭环。

13.9 放着 SaaS 成本不管

月底账单惊魂。

13.10 LLM 可观测性为零

幻觉、拒答、成本暴涨都察觉不到。

第 14 章 · 检查清单 — 可观测性上线前的 12 项

第 15 章 · 下期预告 — Season 5 Ep 9：“数据团队的组织与职业发展”

技术、治理、可观测性都堆起来了，接下来轮到 做出这一切的人。Ep 9 讲数据与 AI 团队的组织和职业发展。

数据工程师 vs 分析工程师 vs 平台工程师 vs 科学家
ML Engineer 与 AI Engineer 的崛起
Central vs Embedded vs Mesh 的组织模型
创业公司与大企业的团队规模与角色
值班与知识共享的文化
领导路径（管理者 vs IC）
全球远程与国内的特殊性
2025 年的薪酬与激励体系
招聘与面试趋势
学习与职业策略

“比工具更重要的是团队” — 2025 年数据组织的现状。

下一篇文章见。

总结：2025 年的可观测性扩展成了 “三大信号 + α”（Metric、Log、Trace + Profile、RUM、Synthetic、LLM 事件），随着 OpenTelemetry 成为采集标准，厂商锁定正在快速瓦解。Grafana 技术栈胜在开源与性价比，Datadog、New Relic、Splunk、Dynatrace 胜在一体化与企业级，Honeycomb、SigNoz、Axiom 则是低成本、高探索性的新世代。SLO 与 Error Budget 成了平衡开发与稳定性的语言，LLM 可观测性（LangFuse、Phoenix、Helicone、Datadog LLM）作为 Ep 6 的延长线走向主流。“可观测性不是保险，而是产品质量”这一宣言就是 2025 年的默认值。韩国企业正在把网络隔离、韩语、SLO 文化融合起来，而下一篇要讲的，是做出这份可观测性的 数据团队与人。