fix typo

Observability/What-is-Observability.md

@@ -11,6 +11,6 @@ Google Cloud 在介绍可观测标准项目 OpenTelemetry 时提到一个概念
 
 “遥测数据”看起来陌生，但你肯定无意间听过。观看火箭发射的直播时，你应该听到过类似的指令：“东风光学 USB 雷达跟踪正常，遥测信号正常” 。随着火箭升空，直播画面还会特意切换到一个看起来“高大上”仪表控制台。
 
-事实上，软件领域的可观测性与火箭发射系统的遥测概念并无本质区别，皆为**全方位收集系统各方面的运行数据（遥测数据），来了解系统内部的运作情况**。因此，可观测性本质上是一门数据收集、分析的科学，帮助人们解决复杂系统的故障检测、性能优化以及风险预警等问题。
+实际上，软件领域的观测与上述火箭发射系统相似，都是通过全面收集系统运行数据（遥测数据），以了解内部状态。因此，观测**本质上是一种数据收集与分析的科学，旨在帮助解决复杂系统中的故障检测、性能优化和风险预警等问题**。
 
 [^1]: 参见 https://cloud.google.com/learn/what-is-opentelemetry

Observability/conclusion.md

@@ -1,6 +1,5 @@
 # 9.5 小结
 
+通过本章内容，你应该已经理解观测与监控的区别。监控并没有被取代，它是可观测性能力的子集，而可观测性通过收集和分析多维数据，全面展现系统状态，不仅检测已知问题，还能帮助预防未知问题。
 
-可观测性（Observability）本质上，是通过系统的输出（如日志、指标和追踪）来推测系统内部的行为和状态。
-
-正如 Linus 所说，足够多的眼睛能让所有问题浮现。只要将足够的系统的输出（各类遥测数据）一致地收集、关联并进行统一的分析。那么，无论系统多么复杂，都能被彻底理解，即便是最难排查的“疑难杂症”，也无处遁形！
+正如 Linus 所言，“足够多的眼睛能让所有问题浮现”。只要收集、关联并统一分析系统的遥测数据（如日志、指标和追踪），即使是最复杂的系统也能被彻底理解，所有“疑难杂症”都能找到根源。

Observability/logging.md

@@ -2,7 +2,7 @@
 
 处理日志本来是件稀松平常的事情，但随着数据规模的增长，量变引发质变，高吞吐写入（GB/s）、低成本海量存储（PB 级别）以及亿级数据的实时检索（1 秒内），已成为软件工程领域最具挑战性的难题之一。
 
-本节将从日志存储与分析的角度出发，介绍三种业内应对海量数据挑战的方案。
+本节将从日志索引和存储的角度出发，介绍三种业内应对海量数据挑战的方案。
 
 ## 1. 全文索引 Elastic Stack
 

Observability/metrics.md

@@ -1,16 +1,15 @@
 # 9.3.1 指标的处理
 
-提到指标，就不得不提 Prometheus 系统。
+提到指标，就不得不提 Prometheus 系统。Prometheus 是继 Kubernetes 之后，云原生计算基金会（CNCF）的第二个正式项目。该项目发展至今，已成为云原生系统中处理指标监控的事实标准。
 
-Prometheus 起源可以追溯到 Google 的内部监控系统 BorgMon。2012 年，前 Google 工程师 Julius Volz 加入 SoundCloud，他受到 BorgMon 启发，设计了 Prometheus，以满足 SoundCloud 对监控和告警的需求。2016 年 5 月，Prometheus 继 Kubernetes 之后成为云原生计算基金会（CNCF）的第二个正式项目。如今，Prometheus 已成为云原生系统中处理指标的事实标准。
-
-本节，我们将分析 Prometheus 系统的设计，了解指标的收集、存储和使用过程。
-
-我们先对 Prometheus 的架构有个总体性的认识。如图 9-3 所示，Prometheus 是一个高度模块化的系统，主要的组件有：服务发现（Service Discovery）自动发现监控目标，Exporter 将监控目标的指标转换为 Prometheus 可理解的格式，Pushgateway 处理短期任务的指标，Prometheus Server 负责指标的存储和查询，Alertmanager 负责触发告警。
+:::tip 额外知识
+有趣的是，像 Kubernetes 一样，Prometheus 也源自 Google 的 Borg 体系，其原型是与 Borg 同期诞生的内部监控系统 BorgMon。Prometheus 的发起原因与 Kubernetes 类似，都是希望以更好的方式将 Google 内部系统的设计理念传递给外部开发者。
+:::
 
+作为监控系统，Prometheus 的基本原理如图 9-3 所示，通过 pull（拉取）方式收集被监控对象的指标数据，并将其存储在 TSDB（时序数据库）中。其他组件（如 Grafana 和 Alertmanager）配合这一机制，实现指标数据可视化和预警功能。
 :::center
   ![](../assets/prometheus-arch.png)<br/>
-  图 9-3 Prometheus 的架构
+  图 9-3 Prometheus 的工作原理
 :::
 
 ## 1. 定义指标的类型

Observability/summary.md

@@ -12,7 +12,7 @@ given enough eyeballs, all bugs are shallow.
 
 复杂性失控问题在工业领域同样出现过。19 世纪末起，电气工程的细分领域迅速发展，尤其是 20 世纪 50 年代的航空领域，研发效率要求越来越高、运行环境越来越多样化，系统日益复杂对稳定性提出了巨大挑战。在这一背景下，匈牙利裔工程师 Rudolf Emil Kálmán 提出了“可观测性”概念，其理念的核心是“通过分析系统向外部输出的信号，判断工作状态并定位缺陷的根因”。
 
-借鉴电气系统的观测理念，我们也可以通过系统输出各类信息，实现软件系统的可观测性。2018 年，CNCF 率先将“可观测性”概念引入 IT 领域，强调它是云原生时代的必备能力！从生产所需到概念发声，加之 Google 在内的众多大厂一拥而上，“可观测性”逐渐取代“监控”，成为云原生领域最热门的话题之一。
+借鉴电气系统的观测理念，我们也可以通过系统输出各类信息，实现软件系统的可观测。2018 年，CNCF 率先将“可观测性”概念引入 IT 领域，强调它是云原生时代软件的必备能力！从生产所需到概念发声，加之 Google 在内的众多大厂一拥而上，“可观测性”逐渐取代“监控”，成为云原生领域最热门的话题之一。
 
 :::center
   ![](../assets/observability.png)<br/>

ServiceMesh/summary.md

@@ -7,9 +7,9 @@
 —— by David Wheeler[^1]
 :::
 
-Kubernetes 的崛起意味着虚拟化的基础设施，开始解决分布式系统软件层面的问题。Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，其实把构建分布式应用最迫切的需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中。但 Kubernetes 解决问题的最细粒度只能到达容器层次，在此粒度之下的技术问题（服务发现、负载均衡、限流、熔断、加密等服务间通信治理问题）仍然需要业务工程师亲自解决。
+Kubernetes 的崛起意味着虚拟化的基础设施，开始解决分布式系统软件层面的问题。Kubernetes 最早提供的应用副本管理、服务发现和分布式协同能力，实质上将构建分布式应用的核心需求，利用 Replication Controller、kube-proxy 和 etcd “下沉”到基础设施中。然而，Kubernetes 解决问题的粒度通常局限于容器层面，容器以下的服务间通信治理（如服务发现、负载均衡、限流、熔断和加密等问题）仍需业务工程师手动处理。
 
-在传统分布式时代，解决上述问题时，通常依赖微服务治理框架（如 Spring Cloud 或 Apache Dubbo），将解决方案与业务逻辑混合编写。在云原生时代，解决上述问题时，在 Pod 内注入辅助功能的 Sidecar 容器。业务对此完全无感知，显然是最“Kubernetes Native”的方式。Sidecar 将非业务逻辑从应用程序中剥离，服务间的通信治理由此开启了全新的进化，并最终演化出一层全新基础设施层 —— 服务网格（ServiceMesh）。
+在传统分布式系统中，解决上述问题通常依赖于微服务治理框架（如 Spring Cloud 或 Apache Dubbo），这类框架将业务逻辑和技术方案紧密耦合。而在云原生时代，解决这些问题时，在 Pod 内注入辅助功能的边车代理（Sidecar） ，业务对此完全无感知，显然是最“Kubernetes Native”的方式。边车代理将非业务逻辑从应用程序中剥离，服务间的通信治理由此开启了全新的进化，并最终演化出一层全新基础设施层 —— 服务网格（ServiceMesh）。
 
 本章，我们将回顾服务间通信的演化历程，从中理解服务网格出现的背景、以及它所解决的问题。然后解读服务网格数据面和控制面的分离设计，了解服务网格领域的产品生态（主要介绍 Linkerd 和 Istio）。最后，我们直面服务网格的缺陷（网络延迟和资源占用问题），讨论如何解决，并展望服务网格的未来。本章内容组织如图 8-0 所示。