fix typo

Observability/conclusion.md

@@ -1,22 +1,6 @@
 # 9.5 小结
 
 
-从迈入云原生的那一刻起，业务弹性场景变化节奏加快，工作负载生命周期缩短、服务之间的链路关系更加复杂。在轻量、多变、短生命周期的云原生环境中，只有获取足够多的系统运行数据，才得以对事件的根因进行分析，对故障行为进行溯源，对未知威胁进行预测。
+可观测性（Observability）本质上，是通过系统的输出（如日志、指标和追踪）来推测系统内部的行为和状态。
 
-
-
-可以预见的未来，相信可观测领域将形成一定意义的标准化。
-
-首先是指标，Prometheus 作为云原生时代的指标数据标准已经形成共识。链路标准也随着 OpenTelemetry 的推行逐渐占据主流。在日志领域，虽然因数据结构化程度低，难以形成数据标准，但采集存储分析侧涌现出 Fluent、Loki 等开源新秀。另一方面，Grafana 作为可观测数据展示标准也基本明朗。
-
-最后，CNCF 孵化的 OpenTelemetry ，实现 Logs、Traces、Metrics 三种数据协议底层标准定义、采集大一统，建设可扩展/低成本/统一的可观测平台未来可期。
-
-参考文档：
-- 《Gorilla：快速、可扩展的内存时间序列数据库》https://blog.acolyer.org/2016/05/03/gorilla-a-fast-scalable-in-memory-time-series-database/
-- https://github.com/open-telemetry/docs-cn/blob/main/OT.md
-
-- https://medium.com/lightstephq/observability-will-never-replace-monitoring-because-it-shouldnt-eeea92c4c5c9
-
-- 《What is inverted index, and how we made log analysis 10 times more cost-effective with it?》https://blog.devgenius.io/what-is-inverted-index-and-how-we-made-log-analysis-10-times-more-cost-effective-with-it-6afc6cc81d20
-
-- 《从Opentracing、OpenCensus 到 OpenTelemetry，看可观测数据标准演进史》https://developer.aliyun.com/article/885649
+正如 Linus 所说，足够多的眼睛能让所有问题浮现。只要将足够的系统的输出（各类遥测数据）一致地收集、关联并进行统一的分析。那么，无论系统多么复杂，都能被彻底理解，即便是最难排查的“疑难杂症”，也无处遁形！

Observability/metrics.md

@@ -37,7 +37,7 @@ Prometheus 起源可以追溯到 Google 的内部监控系统 BorgMon。2012 年
 
 为了解决上述问题，Prometheus 设计了 Exporter 作为监控系统与被监控目标之间的“中介”，负责将不同来源的监控数据转换为 Prometheus 支持的格式。
 
-Exporter 通过 HTTP 协议将指标暴露在指定的端点（通常是 /metrics）上，供 Prometheus 定期抓取。如下所示，Prometheus 定期请求某个 Exporter，获取名称为 http_request_total、类型为 Counter 的指标。
+Exporter 可以作为独立服务运行，也可以与应用程序共享同一进程，只需集成 Prometheus 客户端库即可。Exporter 通过 HTTP 协议返回符合 Prometheus 格式的文本数据，Prometheus 服务端会定期拉取这些数据。以下是一个 Exporter 示例，它返回名为 http_request_total 的 Counter 类型指标。
 
 ```bash
 $ curl http://127.0.0.1:8080/metrics | grep http_request_total
@@ -46,10 +46,10 @@ $ curl http://127.0.0.1:8080/metrics | grep http_request_total
 http_request_total 5
 ```
 
-现今，Prometheus 社区涌现出大量用于不同场景的 Exporter，涵盖了基础设施、中间件和网络等各个领域。如表 9-1 所示，这些 Exporter 扩展了 Prometheus 的监控范围，几乎覆盖了用户关心的所有监控目标。
+得益于 Prometheus 良好的社区生态，现在已有大量用于不同场景的 Exporter，涵盖了基础设施、中间件和网络等各个领域。如表 9-1 所示，这些 Exporter 扩展了 Prometheus 的监控范围，几乎覆盖了用户关心的所有监控目标。
 
 :::center
-表 9-1 Prometheus 中常用 Exporter
+表 9-1 常用的 Exporter
 :::
 
 | 范围 | 常用 Exporter |
@@ -66,7 +66,9 @@ http_request_total 5
 
 ## 3. 存储指标
 
-存储数据本来是一项常规操作，但当面对存储指标类型的场景来说，必须换一种思路应对。举例来说，假设你负责管理一个小型集群，该集群有 10 个节点，运行着 30 个微服务系统。每个节点需要采集 CPU、内存、磁盘和网络等资源使用情况，而每个服务则需要采集业务相关和中间件相关的指标。假设这些加起来一共有 20 个指标，且按每 5 秒采集一次。那么，一天的数据规模将是：
+存储数据本来是一项常规操作，但当面对存储指标类型的场景来说，必须换一种思路应对。
+
+举一个例子，假设你负责管理一个小型集群，该集群有 10 个节点，运行着 30 个微服务系统。每个节点需要采集 CPU、内存、磁盘和网络等资源使用情况，而每个服务则需要采集业务相关和中间件相关的指标。假设这些加起来一共有 20 个指标，且按每 5 秒采集一次。那么，一天的数据规模将是：
 
 ```
 10（节点）* 30（服务）* 20 (指标) * (86400/5) （秒） = 103,680,000（记录）