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

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

• Prologue — “可观测性不是保险，而是产品”
• 第 1 章 · 三大信号 + α
  • 1.1 基本三种
  • 1.2 扩展信号
  • 1.3 关联（Correlation）
• 第 2 章 · OpenTelemetry — 标准的成熟
  • 2.1 它是什么
  • 2.2 结构
  • 2.3 为什么重要
  • 2.4 落地难度
• 第 3 章 · Grafana 技术栈（开源）
  • 3.1 组成
  • 3.2 Grafana Cloud
  • 3.3 优势
  • 3.4 局限
• 第 4 章 · Datadog、New Relic、Splunk、Dynatrace — SaaS 巨头
  • 4.1 Datadog
  • 4.2 New Relic
  • 4.3 Splunk
  • 4.4 Dynatrace
  • 4.5 对比
• 第 5 章 · 新世代 — Honeycomb、SigNoz、Axiom、Tinybird
  • 5.1 Honeycomb
  • 5.2 SigNoz
  • 5.3 Axiom
  • 5.4 Tinybird
  • 5.5 OpenObserve
  • 5.6 共同点
• 第 6 章 · Logs、Metrics、Traces 的落地实践
  • 6.1 Metric 设计
  • 6.2 Log 设计
  • 6.3 Trace 设计
  • 6.4 RUM
  • 6.5 Synthetic
• 第 7 章 · SLO、SLI、Error Budget
  • 7.1 概念
  • 7.2 为什么重要
  • 7.3 实战指标
  • 7.4 Error Budget 政策
  • 7.5 工具
• 第 8 章 · LLM Observability（Ep 6 的延长）
  • 8.1 追加的信号
  • 8.2 主要工具
  • 8.3 OpenLLMetry
  • 8.4 运营模式
• 第 9 章 · 混沌工程与韧性
  • 9.1 哲学
  • 9.2 工具
  • 9.3 实战
  • 9.4 在数据管道上的应用
  • 9.5 2025 趋势
• 第 10 章 · 告警、值班、事故响应
  • 10.1 告警设计
  • 10.2 值班文化
  • 10.3 事故响应
  • 10.4 Postmortem
  • 10.5 工具
• 第 11 章 · 成本优化
  • 11.1 日志成本
  • 11.2 Metric 成本
  • 11.3 Trace 成本
  • 11.4 SaaS 成本
  • 11.5 现实目标
• 第 12 章 · 韩国企业的可观测性
  • 12.1 现状
  • 12.2 LLM 可观测性的落地
  • 12.3 韩国的特殊性
  • 12.4 参考案例
• 第 13 章 · 十大反模式
  • 13.1 “上线之后再加可观测性”
  • 13.2 所有日志都打 DEBUG
  • 13.3 告警刷屏
  • 13.4 没有 SLO 的运营
  • 13.5 没有 Trace 就分析故障
  • 13.6 高基数的 Metric 标签
  • 13.7 日志里放敏感信息
  • 13.8 没有 Postmortem，同样的事故反复发生
  • 13.9 放着 SaaS 成本不管
  • 13.10 LLM 可观测性为零
• 第 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 对比

第 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 项

• 基于 OpenTelemetry 的埋点（SDK + Collector）
• 三大信号 + RUM + Synthetic
• 结构化日志 + Trace ID 串联
• SLO/SLI 的定义与仪表盘
• Error budget 政策
• 值班轮换 + Runbook
• 严重度与告警设计（Symptom-based）
• Postmortem 流程（Blameless）
• LLM 可观测性（提示词、token、反馈）
• 成本仪表盘 + 复盘周期
• 混沌工程与韧性演练
• 安全与个人信息指南

第 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 文化融合起来，而下一篇要讲的，是做出这份可观测性的 数据团队与人。