适用读者：要把"能排障"变成"可持续排障"的架构师/技术负责人。
前置：S16-J04、S17（分布式）、S15（容量与成本）。
覆盖旧文：A-560 → 270 点（什么时候适合/不够、单体是否需要、最大价值、局限、面试口径、Zipkin 与 SkyWalking 选型）。
扩展点：E-S16-009（采样与保留策略矩阵）。
上一篇：S16-J04 · 排障实战：从告警到根因的四步
下一篇：S16-A02 · 质量门禁与发布。
1. 一句话结论
可观测性的架构问题不是"采集什么"，而是"在哪一层丢弃什么"。 全量采集在业务量增长后必然崩：先是存储成本，然后是采集链路成为故障源。采样与保留策略是架构决策，不是运维配置。
| 决策 | 不决策的后果 |
|---|---|
| 采样率与采样点（头部/尾部） | 存储成本随流量线性上涨，最终砍掉追踪 |
| 保留期分层（热/温/冷） | 排障时查不到 7 天前的链路 |
| 采集侧故障隔离 | Collector 挂掉拖慢业务 |
2. 适用与局限：什么该上、什么不该上（§2）
原文的判断（任务版整理）：
| 场景 | 结论 |
|---|---|
| 微服务调用多 | ✅ 强烈建议上 |
| 团队正在学分布式追踪 | ✅ Zipkin + 两个服务足够 |
| 只需要链路追踪 | ✅ Zipkin/Micrometer 即可，不必上 APM |
| 已有 Micrometer/Brave/OTel | ✅ 复用现有埋点，只加后端 |
| 单体 + 单库 | ❌ 结构化日志 + 指标足够；追踪收益 < 维护成本 |
| 只在做"技术栈升级" | ❌ 追踪解决"跨进程因果"，不解决代码质量 |
局限（必须写在方案里）：
| 局限 | 说明 |
|---|---|
| 采样会丢数据 | 低频错误可能永远看不到（除非尾部采样） |
| 追踪不等于 profiling | 方法级热点要靠 async-profiler / JFR |
| 埋点本身是代码 | 自研 RPC/私有协议需要手工传播上下文 |
| 存储是新的运维面 | ES 集群也要容量规划、快照、恢复演练 |
| 成本不可忽略 | 见 §3 估算 |
3. 容量与成本估算（1 亿 span/天，可直接套）
假设：单 span 平均 500 B（含标签），日 1 亿 span。
| 项 | 计算 | 结果 |
|---|---|---|
| 原始日增 | 1e8 × 500 B | 50 GB/天 |
| 压缩后（ES 约 0.4–0.6×） | 50 × 0.5 | 25 GB/天 |
| 副本 ×2 | 25 × 2 | 50 GB/天 |
| 保留 7 天 | 50 × 7 | 350 GB |
| 保留 30 天 | 50 × 30 | 1.5 TB |
采样到 5% 后：原始日增 2.5 GB，7 天 ≈ 17.5 GB（含副本 35 GB）——成本降为 1/20，定位能力基本不变（错误链路强制采样补齐）。
判据：先算"一天有多少条错误链路"，再定采样率——错误链路必须 100% 保留，正常链路才适合采样。
4. 采样与保留策略矩阵（E-S16-009）
| 流量特征 | 采样策略 | 保留期 | 备注 |
|---|---|---|---|
| < 100 QPS | 100% 头部采样 | 热 7 天 | 数据量小，别省 |
| 100–5k QPS | 5–10% 头部 + 错误强制 | 热 7 / 冷 30 天 | 主流选择 |
| > 5k QPS | 1% 头部 + 尾部采样（错误/慢/关键业务 100%） | 热 3 / 冷 30 天 | 需 Collector 缓冲 |
| 合规/审计要求 | 关键链路 100%，其余 0.1% | 冷 180 天+ | 冷存用对象存储 |
| 成本敏感 | 只留指标 + 错误链路 | 热 3 天 | 放弃"事后回看正常请求" |
尾部采样的两个前提：① 有缓冲（否则决定时 trace 已丢）；② 接受"决定延迟"（几秒到几十秒后才落库）。
5. 故障域：可观测性系统自己会坏
| 故障 | 表现 | 隔离手段 |
|---|---|---|
| Collector/OAP 挂 | 应用继续跑，但无数据 | 应用侧异步上报 + 有界队列，满了丢弃而非阻塞 |
| 存储打满 | 写入失败，UI 空白 | 保留期 + 水位告警 + 只读降级 |
| Agent 拖慢业务 | 接入后 P95 上升 | 压测前后对比；只对核心服务开启；开关可动态关闭 |
| 采样配置错误 | 关键期无数据 | 配置变更走评审；采样率纳入变更记录 |
| 时钟漂移 | span 时间倒挂、树错乱 | NTP 强制同步；UI 侧容忍乱序 |
架构原则：可观测性链路必须"故障时静默"——它不能成为业务的依赖。任何"上报阻塞业务线程"的实现都是设计缺陷。
6. 选型：Zipkin / SkyWalking / OTel 后端（§3）
| 维度 | Zipkin | SkyWalking | OTel + 后端（Tempo/Jaeger） |
|---|---|---|---|
| 能力 | 纯追踪 | APM 全家桶 | 追踪为主，指标日志可分流 |
| 接入 | 依赖（Micrometer） | Agent（零代码） | SDK/Agent |
| 拓扑 | ❌ | ✅ | 需后端支持 |
| 运维 | 低 | 中 | 中高（多组件） |
| 迁移成本 | 低 | 中（Agent 版本绑定） | 中（标准协议，易换后端） |
| 适合 | 中小/学习 | 中大型微服务 | 多语言、想避免厂商锁定 |
选型判据（三条，按顺序问）：
- 是否需要"服务拓扑 + 多信号统一"？ 是 → SkyWalking 或 OTel+APM 后端；否 → Zipkin 足够。
- 是否多语言/多团队？ 是 → 优先 OTel（标准协议，后端可换）。
- 团队有没有人维护 ES/OAP？ 没有 → 用托管服务，不要自建。
"两者能不能一起用"（原文 §23 的问题）：可以，但不要双份埋点——用 OTel 作为唯一埋点层，同时导出到两个后端；双 Agent 会重复上报并放大开销。
7. 面试口径（§4）
被问"你怎么做可观测性"时，按决策顺序答，而不是罗列工具：
目标：把 MTTR 从 X 分钟降到 Y 分钟
信号：指标（发现问题）→ 链路（定位哪一跳）→ 日志（解释原因）
采样：头部 5% + 错误/慢请求 100%，尾部采样兜底
成本：日增 2.5GB，7 天热存 + 30 天冷存，约 N 元/月
故障域：上报异步、队列有界、满了丢弃；存储水位告警
验收：抽 10 条历史告警，能否在 10 分钟内定位到具体 span
这条口径的价值：它把"我用了 SkyWalking"变成"我做了可验证的取舍"。
8. 常见误区
| 误区 | 纠正 |
|---|---|
| "先全量采集，以后再优化" | 成本随流量线性上涨，优化时已积压历史数据 |
| "采样会漏问题" | 错误链路强制采样可补；全量反而因成本被整体关掉 |
| "可观测性越全越好" | 信号越多，维护面越大；先解决 MTTR 最大的一块 |
| "自建 ES 更可控" | 没有专职运维时，自建 ES 是最常见的"可观测性故障源" |
9. 自测
- 用 §3 的表算出你现在的日增与月成本；如果流量涨 5 倍，还撑得住吗？
- 你的采样策略里，错误链路是 100% 吗？
- 画一张故障域图：Collector 挂了，业务会不会受影响？
10. 下一篇
S16-A02 · 质量门禁与发布：测试策略、灰度与回滚验收 —— 把前面的测试与观测能力接进发布流程，回答"什么条件下允许发、失败怎么退"。