1. 全书概览
一句话总结：这本书从腾讯云微服务平台 TSF 的实战经验出发，系统拆解了云原生可观测系统的设计方法论——覆盖日志、链路追踪、指标监控、事件和诊断五大支柱，给出可以直接落地的开源架构方案和大规模数据处理策略。
全书结构：
| 章节 | 主题 | 一句话概括 | |------|------|-----------| | 第1章 | 可观测性概述 | 从单体到微服务的演进，讲清楚"监控"和"可观测性"到底有什么区别 | | 第2章 | 开源架构设计 | 三套完整方案（Grafana+Prometheus+Tempo+Loki、Elastic Stack、大规模优化），直接照着搭 | | 第3章 | 日志系统 | Elasticsearch 全文检索 + ClickHouse 列式存储的双引擎实战，索引和分片策略讲得很透 | | 第4章 | 链路追踪 | 分布式系统的"显微镜"，从 OTLP 协议到采样策略到根因定位 | | 第5章 | 监控系统 | 指标的采集、存储、告警全链路，业务指标和系统指标的分层设计 | | 第6章 | 事件系统 | 事件驱动的可观测性补充，告警关联和事件编排 | | 第7章 | 诊断系统 | 从"发现问题"到"定位问题"再到"解决问题"的闭环 | | 第8章 | 实践案例 | 真实业务场景下的可观测系统落地经验 |
2. 逐章要点
第1章：可观测性概述
这一章回答了一个很多人搞混的问题：可观测性和监控到底是不是一回事？书里的观点很明确——监控是可观测性的子集。监控告诉你"系统挂了"，可观测性告诉你"为什么挂了、挂在哪里、影响范围多大"。
书里把可观测技术的演进分了三个阶段：感知系统状态 → 追踪问题位置 → 定位问题根因。这个分层思路很实在，大部分团队其实还卡在第一阶段，只会看 CPU 和内存的仪表盘。
可观测系统存在的三大不足：覆盖不全、不同数据无法关联、计算存储分析海量数据难度大。
书里还提了一个容易被忽略的视角：从业务角度看可观测性。不是所有指标都有用，关键是业务指标（订单数、订单成功率、支付延迟），而不是大而全无目的的系统指标。高并发分布式系统中通常会运行成百上千个微服务，每个微服务又有几个到几百个不等的实例——如果缺乏好的可观测性，排查一个线上问题可能要翻几十个服务的日志。
| 关键概念 | 说明 | |---------|------| | 可观测性 vs 监控 | 监控关注"是什么"，可观测性关注"为什么" | | 三大支柱 | 指标(Metrics)、日志(Logs)、链路(Traces) | | 业务可观测性 | 从用户视角定义关键业务指标，而非技术视角 | | 数据生命周期 | 采集 → 处理 → 分析 → 存储 → 展示 → 告警 |
行动清单：
- [ ] 梳理当前系统的可观测性成熟度，判断处于哪个阶段
- [ ] 区分"监控指标"和"业务指标"，列出前 5 个关键业务指标
- [ ] 评估现有可观测系统的覆盖盲区
第2章：开源架构设计
这是全书最实用的章节之一，直接给了三套可以落地的架构方案。
第一套方案基于 Grafana + Prometheus + Tempo + Loki，是目前云原生社区最主流的组合。Prometheus 负责指标采集和存储，Loki 做日志聚合（轻量级，和 Prometheus 共用标签体系），Tempo 做链路追踪存储，Grafana 统一可视化。这套方案的优点是组件之间标签体系统一，关联查询非常方便。
第二套方案基于 Elastic Stack（Elasticsearch + Logstash + Kibana），优势是全文检索能力强，日志查询灵活度更高，但对存储资源的要求也更大。
第三套方案专门解决大规模数据计算问题——当数据量达到 PB 级别，前面两套方案都会遇到瓶颈。书里给出了分片策略、冷热数据分离、预计算等优化手段。
统一的可观测架构需要做到三点：统一的数据语义、统一的数据处理平台、统一的可视化系统。
| 方案 | 适用场景 | 优势 | 劣势 | |------|---------|------|------| | Grafana+Prometheus+Tempo+Loki | 中小规模、云原生原生 | 标签统一、资源占用低 | 全文检索能力弱 | | Elastic Stack | 日志分析需求强 | 全文检索强大、生态成熟 | 存储成本高 | | 大规模优化方案 | PB 级数据量 | 水平扩展能力强 | 架构复杂度高 |
行动清单：
- [ ] 评估当前团队规模和数据量，选择合适的架构方案
- [ ] 搭建一套 Grafana+Prometheus+Tempo+Loki 的测试环境
- [ ] 制定统一的标签规范（Label Convention）
第3章：日志系统
日志是最古老也最被低估的可观测性数据源。书里花了大量篇幅讲日志系统的工程实践，而不是停留在"打个 log 就行"的层面。
存储引擎的选择是核心问题。Elasticsearch 适合全文检索场景，书里详细讲了索引模块、Shard 和 Segment 的配置策略——多少分片、多大 Segment、什么时候做 merge，这些直接决定了查询性能和存储成本。ClickHouse 作为新生代列式存储，在聚合统计场景下表现更好，写入吞吐量和压缩比都有优势。
日志不是越多越好。没有结构化的日志就是电子垃圾，只会浪费存储空间和查询时间。
书里还强调了日志结构化的重要性：统一的 JSON 格式、规范的字段命名、合理的日志级别。很多团队的日志系统之所以不好用，根本原因是日志本身质量太差。
| 存储引擎 | 适用场景 | 查询特点 | 存储特点 | |---------|---------|---------|---------| | Elasticsearch | 全文检索、复杂查询 | 灵活但较慢 | 存储膨胀大（约 3-5 倍） | | ClickHouse | 聚合统计、时序分析 | 列式扫描快 | 压缩比高（约 10 倍） |
行动清单：
- [ ] 制定日志格式规范，统一 JSON 结构和字段命名
- [ ] 根据查询模式选择存储引擎（全文检索 → ES，聚合统计 → ClickHouse）
- [ ] 建立日志采样策略，非核心业务日志按比例采集
第4章：链路追踪
链路追踪是分布式系统的"显微镜"。一个请求从前端发起到数据库返回，中间可能经过 API 网关、认证服务、业务服务、缓存、消息队列等十几个节点，没有链路追踪，根本不知道时间花在了哪里。
书里讲了多种链路采集协议：OTLP（OpenTelemetry Protocol）是当前的标准，SkyWalking 在 Java 生态里用得多，Zipkin 和 Jaeger 是老牌方案，Spring Cloud Sleuth 适合 Spring Boot 项目直接集成。
采样策略是链路追踪工程实践中的难点。100% 采样在大流量场景下不现实——一个日活百万的应用，每秒可能产生上万条链路数据。书里讨论了多种采样策略：固定比例采样、自适应采样（基于错误率和延迟动态调整）、尾部采样（先缓存再决定是否保留）。
链路追踪的核心价值不是"看到调用链"，而是"快速定位问题发生在哪一层"。
行动清单：
- [ ] 引入 OpenTelemetry SDK，统一链路追踪的接入标准
- [ ] 设计采样策略，正常流量按比例采样，错误流量全量采集
- [ ] 建立链路追踪与日志的关联机制（通过 TraceID）
第5章：监控系统
监控系统的老生常谈，但书里的视角不只是 Prometheus 怎么配，而是从"指标设计"的角度出发。
书里把指标分成了几个层次：基础设施层（CPU、内存、磁盘、网络）、中间件层（Redis 命中率、MySQL 连接数、Kafka Lag）、应用层（QPS、错误率、P99 延迟）、业务层（订单量、支付成功率）。这个分层思路值得每个团队参考——大部分团队只有第一层和第三层，缺了中间件层和业务层。
告警设计也是重点。书里批评了"告警风暴"的问题：一条线上故障触发几百条告警，值班人员根本看不过来。解决方案包括告警聚合、告警抑制、告警分级（P0-P3）、告警升级机制。
好的告警系统应该让值班人员看到告警就能行动，而不是看到告警还要去查文档才知道怎么办。
行动清单：
- [ ] 梳理四个层次的监控指标，补齐中间件层和业务层
- [ ] 制定告警分级标准（P0 立即响应、P1 30 分钟内、P2 当天、P3 下次迭代）
- [ ] 每条告警附带 Runbook（处理手册），不允许"裸告警"
第6章：事件系统
事件是可观测性三大支柱之外的补充维度。指标告诉你"系统有多慢"，日志告诉你"哪里出了错"，事件告诉你"发生了什么变更"。
书里把事件分为几类：部署事件（发布、回滚）、配置变更事件、基础设施事件（扩缩容、节点故障）、业务事件（促销开始、流量突增）。这些事件往往和故障直接相关——很多线上问题不是系统 bug，而是某次变更引发的。
事件系统的设计要点：事件的时间线展示、事件与告警的关联、事件的自动化响应。比如检测到某次发布后错误率飙升，系统自动触发回滚。
80% 的线上故障和变更有关。如果不对变更进行追踪，事故分析就是瞎猜。
行动清单：
- [ ] 建立变更事件追踪机制，所有发布和配置变更自动记录
- [ ] 实现事件与告警的时间线关联
- [ ] 制定关键变更的审批和回滚流程
第7章：诊断系统
诊断是可观测性的最终目标——从"发现问题"到"定位问题"再到"解决问题"。前几章讲的是数据采集和展示，这一章讲的是怎么用这些数据来诊断问题。
书里提出了诊断的几个关键能力：根因分析（RCA）、影响面评估、自动化修复建议。根因分析不是简单的"看日志找异常"，而是需要把指标、日志、链路、事件四类数据关联起来，才能还原故障的完整链条。
诊断系统的成熟度决定了 MTTR（平均故障恢复时间）。好的诊断系统能把 MTTR 从小时级降到分钟级。
行动清单：
- [ ] 建立故障复盘模板，每次事故都产出 RCA 报告
- [ ] 设计根因分析的数据关联查询（TraceID + 错误日志 + 变更事件）
- [ ] 定义 MTTR 目标，定期回顾诊断效率
第8章：实践案例
最后一章是真实业务场景的落地经验，把前面讲的理论和方法串联起来。包括微服务架构下的可观测性建设、多集群环境的统一监控、混合云场景下的数据采集等。
这些案例最大的价值在于"踩坑记录"——哪些方案看起来美好但落地困难、哪些组件在大规模下有性能瓶颈、哪些设计决策事后证明是错的。这些经验比理论更有参考价值。
行动清单：
- [ ] 参考案例中的架构图，对照自身系统找差距
- [ ] 关注案例中提到的性能瓶颈点，提前做压测
- [ ] 建立可观测性建设的阶段目标，分步推进
3. 关键概念速查
| 概念 | 定义 | 一句话理解 | |------|------|-----------| | 可观测性 (Observability) | 从系统的外部输出推断系统内部状态的能力 | 不需要进黑盒就能知道里面发生了什么 | | 三大支柱 (Three Pillars) | 指标(Metrics)、日志(Logs)、链路追踪(Traces) | 可观测性的三种基本数据类型 | | OTLP | OpenTelemetry Protocol，可观测性数据的标准传输协议 | 让不同厂商的采集器和后端能互相通信 | | 尾部采样 (Tail Sampling) | 先缓存完整链路数据，再根据规则决定是否保留 | 用少量计算换取更精准的采样（比如全保留错误链路） | | SLI/SLO/SLA | 服务质量指标/目标/协议 | 从"用户感知"角度定义系统应该有多可靠 | | MTTR | Mean Time To Recovery，平均故障恢复时间 | 衡量可观测性系统价值的终极指标 | | 告警疲劳 (Alert Fatigue) | 告警太多导致值班人员麻木 | 告警系统设计不好比没有告警更糟 | | eBPF | Extended Berkeley Packet Filter，内核级可观测技术 | 不改代码、不加 Agent 就能采集系统行为数据 | | RED 方法 | Rate(请求率)、Errors(错误率)、Duration(延迟) | 面向请求的服务健康度评估三要素 | | USE 方法 | Utilization(使用率)、Saturation(饱和度)、Errors(错误) | 面向资源的基础设施健康度评估三要素 |
4. 核心框架/模型
可观测性成熟度模型
Level 4: 预测与自愈
↑ 系统能预测故障并自动修复
|
Level 3: 智能诊断
↑ 自动根因分析，MTTR < 5min
|
Level 2: 全链路关联
↑ 指标+日志+链路+事件四维关联
|
Level 1: 基础监控
↑ 有仪表盘和告警，但数据孤立
|
Level 0: 黑盒状态
出了问题靠猜
统一可观测架构（Grafana 生态）
┌─────────────────────────────────────────────────┐
│ 应用层 │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Service│ │Service│ │Service│ │Service│ │
│ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │
│ │ │ │ │ │
│ ┌──┴──────────┴──────────┴──────────┴──┐ │
│ │ OpenTelemetry Collector │ │
│ └────────┬──────────┬──────────┬────────┘ │
│ │ │ │ │
│ ┌─────┴───┐ ┌────┴───┐ ┌───┴────┐ │
│ │Prometheus│ │ Loki │ │ Tempo │ │
│ │ (指标) │ │ (日志) │ │ (链路) │ │
│ └────┬────┘ └───┬────┘ └───┬────┘ │
│ │ │ │ │
│ ┌────┴───────────┴──────────┴────┐ │
│ │ Grafana (统一可视化) │ │
│ └───────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
指标分层体系
| 层次 | 示例指标 | 负责人 | 告警级别 | |------|---------|--------|---------| | 业务层 | 订单量、支付成功率、DAU | 产品 + 研发 | P0 | | 应用层 | QPS、P99 延迟、错误率 | 研发 | P1 | | 中间件层 | Redis 命中率、MySQL 慢查询、Kafka Lag | 研发 + DBA | P1-P2 | | 基础设施层 | CPU、内存、磁盘、网络 | 运维 | P2 |
5. 金句摘录
监控告诉你系统出了什么问题，可观测性告诉你为什么会出这个问题。
80% 的线上故障和变更有关。如果不对变更进行追踪，事故分析就是瞎猜。
没有结构化的日志就是电子垃圾，只会浪费存储空间和查询时间。
好的告警系统应该让值班人员看到告警就能行动，而不是看到告警还要去查文档才知道怎么办。
可观测性不是一个技术问题，而是一个组织问题。它需要开发、运维、产品三个角色共同参与。
诊断系统的成熟度决定了 MTTR。好的诊断系统能把故障恢复时间从小时级降到分钟级。
不要试图一次性建设完整的可观测系统。从最痛的问题开始，逐步覆盖。
6. 行动清单
每天
- [ ] 检查核心业务指标（订单量、错误率、P99 延迟）的仪表盘，确认没有异常波动
- [ ] 审查昨日新增的告警规则，清理误报和低价值告警
每周
- [ ] 分析告警趋势，识别告警频率最高的 Top 5 告警，优化或消除
- [ ] 检查日志采样率和存储成本，确保没有非结构化日志混入
- [ ] Review 一次链路追踪的慢请求，确认是否需要优化
每月
- [ ] 更新 SLI/SLO 目标，对比上月实际达成情况
- [ ] 做一次故障复盘（如果有），产出 RCA 报告并更新 Runbook
- [ ] 评估可观测性系统的覆盖盲区，制定下月补齐计划
- [ ] 回顾 MTTR 趋势，评估诊断效率是否在提升
7. 一句话总结
可观测性不是工具堆砌，而是从"出了问题靠猜"进化到"出了问题秒定位"的系统工程——先搞清楚你要观测什么，再选工具，最后才是搭架构。
8. 读者热议
@驴得水（豆瓣，2024-03）
"可观测技术发展阶段：感知系统状态、追踪问题位置、定位问题根因。可观测系统存在的不足：覆盖不全、不同数据无法关联、计算存储分析海量数据难度大。从业务角度看：关键业务指标（订单数、订单成功率）区别于大而全无目的的监控。"
认同度：⭐⭐⭐⭐⭐ 说到了痛点。大部分团队的可观测性建设确实停留在"感知系统状态"阶段，把 Prometheus + Grafana 搭起来就觉得完事了，根本没做到"不同数据之间关联分析"。业务指标这个视角也很关键——技术指标再全，如果和业务脱节，就是自嗨。
@CSDN 博主（2024 年评论）
"传统监控与可观测性的本质差异在于：监控是静态的仪表盘，可观测性是动态的探索过程。可观测性通过日志、链路追踪、指标、事件等多维度数据的关联与上下文传递，让工程师能够在不停机的情况下理解系统内部行为。"
认同度：⭐⭐⭐⭐ 方向对，但"动态的探索过程"这个说法有点虚。实际工作中，可观测性更像是"出了问题能快速找到原因的能力"，不需要过度包装。多维度数据关联确实是核心价值。
@华为云社区博主
"在云原生中，可观测性的实现依赖于监控度量（Metrics）、事件日志（Logs）和链路追踪（Traces）三种数据。这三种数据各有侧重，但又不是完全独立的。"
认同度：⭐⭐⭐⭐ 三大支柱的说法已经成了行业共识。补充一点：事件（Events）应该被列为第四支柱，很多故障的根因是变更事件而不是系统异常，光靠 Metrics + Logs + Traces 是找不到原因的。本书第 6 章专门讲事件系统，这个视角很超前。
笔记生成：2026-04-28 by 喵喵 🐈
相关笔记
同作者仅有此篇 同主题：