更新可观测内容

Observability/history.md

@@ -34,7 +34,7 @@ X 轴的右侧称为 Known Knows（已知且理解）和 Known Unknowns（已知
 
 但是还是有很多情况是这些基础信息很难描述和衡量的，例如这个坐标的左上角：Unknown Knowns（未知的已知，通俗解释可称假设）。举个例子：有经验的架构师为保证系统的可用性时，通常会增加限流、熔断的机制，假设在有突发压力的情况下，这些机制生效尽力保证可用性。注意在这个例子中，`假设`的事情（请求突然增大）并没有发生，如果日常压力不大，从已有的基础监控中，可能也很难看出任何问题。但是到出事的时候，这个未曾验证的发生的失误就会变了我们最不愿意看到的 Unknown Unkowns（没有任何线索、也不理解的意外）。
 
-有经验的架构师能通过种种的蛛丝马迹证实自己的推测，也从无数次翻车的事故分析总结中将 Unknown Unknowns 的查询范围变小。但是更合理的做法是透过系统输出的蛛丝马迹，以一个低门槛且形象的方式描绘系统更全面的状态，当发生 Unknown Unkowns 的情况时候，具象化的一步步找到根因。
+有经验的架构师能通过种种的蛛丝马迹证实自己的推测，也从无数次翻车的事故分析总结中将 Unknown Unknowns 的查询范围变小。但是更合理的做法是透过系统输出的蛛丝马迹，以一个低门槛且形象的方式描绘系统更全面的状态，当发生 Unknown Unkowns 的情况时候，具象化的一步步找到根因。这就是各种可观测系统所做的事情。
 
 在云原生和微服务的世界里，最近几年一个行业的大趋势是将系统的可观测性放在一个更高的位置，监控只是可观测性的一个子集，如下所示。
 

Observability/logging.md

@@ -1,4 +1,4 @@
-# 9.3 日志
+# 9.3 事件日志
 
 你可能不知道 Metrics、Tracing，但你一定了解点 logging。logging 系统中最成熟的部分就是打印日志。尤其是本地日志打印，各式各样层出不穷的 logging Library，同步的异步的、有锁的无锁的、有上下文的无上下文的、高性能的低性能的，花活最多轮子也造的最多。
 

Observability/metrics.md

@@ -1,12 +1,17 @@
-# 9.2 度量
+# 9.2 聚合指标
 
-作为传统监控和告警领域的代名词，Metrics 最广为人知，也被各类可观测系统支持的最丰富。可聚合性即是 Metrics 的特征，它们是一段时间内某个度量（计数器或者直方图）的原子或者是元数据，即是我们的度量元数据，可以进行简单的加法聚合，当持续了一段时间我们又可以建模为直方图。
+作为传统监控和告警领域的代名词，Metrics 最广为人知，也被各类可观测系统支持的最丰富。Metrics 一般是用来计算 Events 发生数量的数据集，例如服务 QPS、API 响应延迟、某个接口的失败数等。它们大部分都是以数字化指标出现，特征是可聚合性，在数据的处理上，Metrics 可以是实时的，也可能是区间范围的，是跟随着时间变化的时序数据。既能做常见的监控告警，也可以用来做趋势分析。
+
+- 实时监控和警报，Metrics 常见的用于是看板，并在系统在超过阈值或者行为异常时自动触发报警。
+- 趋势分析：Metrics 还用在趋势分析，同时还可以在事件发生后提供历史数据分析，修复或者监控以防止潜在问题再次发生。
+
+由于目前并没有 Metrics 采集的标准 API，所以不同的监控系统在收集 Metrics 数据时采取的手段也可能不一样，但大部分无非都是通过 PUSH 到中心 Collector 方式采集 Metrics（比如各种 Agent 采集器，Telegraf 等）； 又或者是中心 Collector 通过 PULL 的方式去主动获取 Metrics（比如 Prometheus）。
+
+
+Metrics 提供的信息可用于系统整体行为和监控状况的分析，它不一定能揭示问题根本原因，但可以作为发现问题的起点。一个典型例子是你收到一条告警”请求成功率跌到了 10%“，你意识到不妙，立即开始处理，然后结合其他 Signals 去找到 root cause，从而解决问题。
 
-大部分时候，Metrics 都是以数字化指标出现，例如请求数、成功率。例如服务 QPS、API 响应延迟、某个接口的失败数等，
 
-在数据的处理上，Metrics 可以是实时的，也可能是区间范围的，既能做常见的监控告警，也可以用来做趋势分析。
 
-一个典型的场景是你收到一条告警”请求成功率跌到了 10%“，你马上意识到大事不妙，立即开始处理，然后结合其他 Signals 去找到 root cause，从而解决问题。
 
 
 时序数据库排名

Observability/profiles.md

@@ -8,15 +8,25 @@
 
 :::
 
-可以看出，Profiling 是一个关于动态程序分析的术语，很多编程语言或框架也提供了丰富的 Profiling Tools，熟悉 Go 语言的朋友一定了解 pprof，当运行异常时，通过 pprof CPU profiling 或者 Memory profiling 分析函数耗时以及内存占用情况，展示形式以 Flame Graph 火焰图表达。其他语言也有 pprof 的实现，例如 Rust 的 pprof-rs。
+可以看出，Profiling 是一个关于动态程序分析的术语，很多编程语言或框架也提供了丰富的 Profiling Tools，熟悉 Go 语言的朋友一定了解 pprof，当运行异常时，通过 pprof CPU profiling 或者 Memory profiling 分析函数耗时以及内存占用情况，展示形式以 Flame Graph（火焰图）表达。2021年国内某站崩溃 [^1]，工程师们使用火焰图观察到到某一处 Lua 代码存在异常时，才找到问题的源头。
+
+<div  align="center">
+	<img src="../assets/lua-cpu-flame-graph.webp" width = "500"  align=center />
+	<p>Lua 级别的 CPU 火焰图</p>
+</div>
 
 可观测中的 Profiles 聚焦在理解资源是如何在系统中被分配的，一般包括：
 
-- CPU Profilers
-- Heap Profilers
-- GPU Profilers
-- Mutex Profilers
-- IO Profilers
-- Language-specific Profilers（e.g. JVM Profiler）
+- CPU Profilers （CPU 分析器）
+- Heap Profilers（堆分析器）
+- GPU Profilers （GPU 分析器）
+- Mutex Profilers （互斥锁分析器）
+- IO Profilers （IO 分析器）
+- Language-specific Profilers（特定于语言的分析器 JVM Profiler）
+
+传统上，这些分析器并不适合在产生环境中运行（开销很大），不过由于采样分析变得越来越可行（只增加了百分之几的开销），这使得临时在生产环境中添加分析器，尽可能地观察到一段时间内的全局 Profiles 数据成为可能。
 
 Traces 让我们了解延迟问题是分布式系统的的哪个部分导致的，而 Profiles 则使我们进一步定位到具体的函数具体的代码，更加深入挖掘并理解那些导致延迟问题存在的原因，是回答从“是什么”到“为什么”的重要数据。
+
+
+[^1] 参见：《2021.07.13 我们是这样崩的》https://www.bilibili.com/read/cv17521097/

container/resource-limit.md

@@ -1,6 +1,7 @@
 # 7.7 资源与调度
 
-调度是编排系统最重要的功能之一。对于 Kubernetes 这个编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，Kuberntes 调度的职责便是实现两者之间最恰当的撮合。想要实现资源恰当的撮合，那么管理以及分配集群节点的资源，至少要清楚这么几个问题：
+对于 Kubernetes 这个编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，编排调度的职责便是实现两者之间最恰当的撮合。想要实现这个目标，那么管理以及分配集群节点的资源，至少要清楚这么几个问题：
+
 - **资源模型的抽象**有哪些种类的资源，如何表示这些资源。
 - **资源的调度**如何描述一个 workload 的资源申请、如何描述一台 node 当前的资源分配状态，例如已分配/未分配资源量。
 - **资源的限额**如何确保 workload 使用的资源量不超出预设范围、如何确保 workload 和系统/基础服务的限额，使二者互不影响。