更新可观测性内容

Observability/history.md

@@ -11,46 +11,60 @@ The information that you will use to determine whether an application is healthy
 遥测数据是指采样和汇总有关软件系统性能和行为的数据，这些数据（响应时间、错误率、资源消耗等）用于监控和了解系统的当前状态。
 :::
 
-事实上，我们进行可观测性，主要就是通过各类的遥测数据对分布式系统提供深⼊可⻅性，以此找到⼤量问题的根本原因并提⾼系统性能。学术界一般会将可观测性的遥测数据分解为三个更具体方向进行研究，它们分别是**事件日志、链路追踪和聚合度量**，总结对遥测数据的处理流程收集数据、存储（索引）、展示，再具体到事件日志、链路追踪和聚合度量这三个方向各有侧重，又不是完全独立，这三个流程之间有重合或者可以结合之处。2017 年的分布式追踪峰会结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》[^2]系统地阐述了这三者的定义、特征以及它们之间的关系与差异，受到了业界的广泛认可。
+遥测数据你不一定陌生，你或许看过中央电视台火箭发射的直播，发射指挥大厅内有条不紊的回响起一系列口令：“USB、雷达 跟踪正常，遥测信号正常”。遥测信号正常说明火箭运行的参数在理想的范围内。软件领域的可测性和系统遥测数据本质和火箭一样，主要就是通过收集系统内部各类的遥测数据来了解系统内部正在发生的事情，以此找到问题的根本原因并提⾼系统可用性，所以，本质上它就是一门数据收集和分析的科学。
 
-<div  align="center">
-	<img src="../assets/observability.png" width = "350"  align=center />
-</div>
+总结来说，软件领域的可测性能够帮助大家在 DevOps 中遇到的故障定位难、容量评估、链路梳理、性能分析等问题，提供一种所谓洞见的能力。所以从实际效果看，分布式系统的可观测性可以认为是生物学的显微镜、天文学的望远镜，我想这也是很多开源项目 Logo 中带有各种镜子的原因。
 
-其后，Cindy Sridharan 在其著作《Distributed Systems Observability》中，进一步讲到指标、追踪、日志是可观测性的三大支柱（three pillars）。
 
+## 可观测性与传统监控
 
-有了遥测数据的定义，那么只要是能分析应用程序性能、可用性，都是可观测的内容。最近，CNCF 又在官方《 Observability Whitepaper》中，提出了 Observability Signals 的概念，原来的三大支柱变成了 3 Primary Signals 以及 Profiles、Dumps。
+:::tip 可观测与监控
+监控告诉我们系统哪些部分是工作的，可观测性告诉我们那里为什么不工作了
 
+-- 《高性能 MySQL》作者 by Baron Schwartz 
+:::
 
+在过去，一个物理机器的状态确实可以通过几个监控指标描述，但是随着我们的系统越来越复杂，观测对象正渐渐的从 Infrastructure 转到 应用，观察行为本身从 Monitoring（监控）到 Observability（观测）。虽然看上去这两者只是文字上的差别，也确实容易引起误解，但是请仔细思考背后的含义。
 
-## 可观测性生态
+如下图所示，套用 Donald Rumsfeld 关于 Known、Unknowns 的名言[^3]，把系统的理解程度和可收集信息之间的关系进行象限化分析。
 
-可观测性的标准，已经基本统一，可见未来 OpenTelemetry，但基于标准化开发的产品，确很难出现一统天下的局面。在 CNCF Landscape 中，有个专门的可观测方案分类：Observability and Analysis，下面还有三个子分类：Montioring、Logging、Tracing，其中的产品加起来又上百个，可见其纷繁庞大。关键的是，这并不是全部不再 CNCF 范围内的商业产品更是不计其数。
 <div  align="center">
-	<img src="../assets/cncf-observability.png" width = "300"  align=center />
+	<img src="../assets/observability-knowns.png" width = "500"  align=center />
 </div>
 
-## 可观测性与监控
+X 轴的右侧称为 Known Knows（已知且理解）和 Known Unknowns（已知但不理解），这些信息通常是最基础的普适的事实，也就是在系统上线之前我们一定就能想到，一定能够监控起来的（CPU Load、内存、TPS、QPS 之类的指标）。我们过去已有的大多数运维监控都是围绕观察 Known Knows、处理 Known Unknowns 这些确定的东西。
 
-可观测性与监控有很多相近之处，事实也确实如此，并很容易引起误解。关于这一点《高性能 MySQL》 作者有一个非常著名的见解，被大家广泛引用：
+但是还是有很多情况是这些基础信息很难描述和衡量的，例如这个坐标的左上角：Unknown Knowns（未知的已知，通俗解释可称假设）。举个例子：有经验的架构师为保证系统的可用性时，通常会增加限流、熔断的机制，假设在有突发压力的情况下，这些机制生效尽力保证可用性。注意在这个例子中，`假设`的事情（请求突然增大）并没有发生，如果日常压力不大，从已有的基础监控中，可能也很难看出任何问题。但是到出事的时候，这个未曾验证的发生的失误就会变了我们最不愿意看到的 Unknown Unkowns（没有任何线索、也不理解的意外）。
 
-:::tip 可观测与监控
-监控告诉我们系统哪些部分是工作的，可观测性告诉我们那里为什么不工作了
+有经验的架构师能通过种种的蛛丝马迹证实自己的推测，也从无数次翻车的事故分析总结中将 Unknown Unknowns 的查询范围变小。但是更合理的做法是透过系统输出的蛛丝马迹，以一个低门槛且形象的方式描绘系统更全面的状态，当发生 Unknown Unkowns 的情况时候，具象化的一步步找到根因。
 
--- by Baron Schwartz
-:::
 
-换句话解释就是监控可以发现问题，可观测性更好地定位问题。它们之间的关系有一个很有表达力的示意图，如下。
+在云原生和微服务的世界里，最近几年一个行业的大趋势是将系统的可观测性放在一个更高的位置，监控只是可观测性的一个子集，如下所示。
 
 <div  align="center">
 	<img src="../assets/Monitoring-vs-Observability.png" width = "450"  align=center />
 </div>
 
-但这并不意味着有可可观测性，就不需要监控了。监控室对系统的持续观察，检测异常行为并发出报警，要解决已知的未知问题。而可观测性透过系统的输出（指标、日志、追踪）了解系统的内部状态，告诉你发生了什么、为什么发生以及如何修复，解决未知的未知问题。
+## 可观测性数据分类
+
+工业界和学术界一般会将可观测性的遥测数据分解为三个更具体方向进行研究，它们分别是**事件日志（Logging）、链路追踪（Tracing）和聚合度量（Metrics）**。
 
-可观测性不能替代监控的讨论，有兴趣的读者可以阅读 《Observability will never replace Monitoring (because it shouldn’t)》[^1]，作者 Ben Sigelman 是 Google Dapper、时序数据库 Monarch 的共同创始人，也是可观测性领域最重要的两个标准 OpenTelemetry 和 OpenTracing 的共同创始人。
+2017 年的分布式追踪峰会结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》[^2]系统地阐述了这三者的定义、特征以及它们之间的关系与差异，受到了业界的广泛认可。
 
+<div  align="center">
+	<img src="../assets/observability.png" width = "350"  align=center />
+</div>
+
+来自于 Cindy Sridharan 的《Distributed Systems Observability》著作中进一步将这三个类型的数据称为可观测性的三大支柱（three pillars），不过将它们成为支柱容易让人产生误解，支柱就像一个房子的均匀受力支撑点，缺一不可。而事实上这三者都可以独立存在，系统中也往往只存在 Logging、Tracing。
+
+所以，在最新 CNCF 发布的可观测性白皮书中，将这些可观测的数据统一称为信号（Signals），主要的信号除了 Metrics、logs、traces 之外又额外增加了  Profiles 和 Dumps。
+
+## 可观测性生态
+
+可观测性的标准，已经基本统一，可见未来 OpenTelemetry，但基于标准化开发的产品，确很难出现一统天下的局面。在 CNCF Landscape 中，有个专门的可观测方案分类：Observability and Analysis，下面还有三个子分类：Montioring、Logging、Tracing，其中的产品加起来上百个，可见其纷繁庞大。关键的这并不是全部，不在 CNCF 范围内的商业产品更是不计其数。
+<div  align="center">
+	<img src="../assets/cncf-observability.png" width = "400"  align=center />
+</div>
 
 
 
@@ -59,3 +73,4 @@ The information that you will use to determine whether an application is healthy
 
 [^1]: 参见 https://cloud.google.com/learn/what-is-opentelemetry
 [^2]: 参见 https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html
+[^3]: 参见 https://blog.sciencenet.cn/blog-829-1271882.html

architecture/background.md

@@ -9,7 +9,6 @@ Mark Andreessen 是风险投资公司 Andreessen-Horowitz 的联合创始人和
 	<p>图1-7 Software is Eating The World —— by Mark Andreessen, in 2011</p>
 </div>
 
-
 2011 年 8 月 20 日华尔街日报上，Mark Andreessen 发表了名为 “Why Software Is Eating the World” 的文章，文章阐述了软件如何影响各个行业，援引原文部分内容：
 
 :::tip <i></i>
@@ -29,7 +28,7 @@ Mark Andreessen 是风险投资公司 Andreessen-Horowitz 的联合创始人和
 
 文中列出了被重塑的产业，具体有：最大的书店 Amazon、最多人订阅的 Video service Netflix、最大的音乐公司 iTunes、Spotify and Pandora 等、成长最快的娱乐领域 videogame、最好的电影制片厂 Pixar、最大的行销平台 Google、Groupon、Facebook 等、成长最快的电信公司 Skype 、成长最快招聘公司 LinkedIn。
 
-文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，感触更加深刻。
+文章发表于 2011 年，2023 年再来回顾，互联网冲击已经无所不在，感触更加深刻。（十多年后的今天，我想它更好的演绎应该是“云原生正在吞噬世界，万物皆可上云”。）
 
 ## 1.2.2 移动互联网在加剧变化
 
@@ -68,7 +67,7 @@ Mark Andreessen 是风险投资公司 Andreessen-Horowitz 的联合创始人和
 
 ## 1.2.4 总结
 
-前面谈到了软件对各行各业的渗透和对世界的改变，以及移动互联网时代巨大的用户基数下快速变更和不断创新的需求对软件开发方式带来的巨大推动力，1.1 节描述的过去二十年间云计算的发展演进和软件上云的趋势，我们可以清晰的看到这样一个波澜壮阔的技术浪潮：
+前面谈到了软件对各行各业的渗透和对世界的改变，以及移动互联网时代巨大的用户基数下快速变更和不断创新的需求对软件开发方式带来的巨大推动力，1.1 节描述的过去二十年间云计算的发展演进和软件上云的趋势，我们可以清晰地看到如此波澜壮阔的技术浪潮：
 
 - 软件正在改变世界。
 - 移动互联网让这个变革影响到每一个人。

container/conclusion.md

@@ -1,2 +1,6 @@
 # 小结
 
+参考 
+
+- k8s 基于 cgroup 的资源限额 https://arthurchiao.art/blog/k8s-cgroup-zh
+- 《凤凰架构》资源与调度

container/resource-limit.md

@@ -1,18 +1,9 @@
 # 7.7 资源与调度
 
-调度是编排系统最重要的功能之一。对于 Kubernetes 这个编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，Kuberntes 调度的职责便是实现两者之间最恰当的撮合，撮合的关键在于容器编排系统。
-
-想要实现资源恰当的撮合，管理以及分配集群节点的资源，至少要清楚这么几个问题：资源模型的抽象（有哪些种类的资源，如何表示这些资源）、
-- 资源模型的抽象
-	- 有哪些种类的资源，例如，CPU、内存等；
-	- 如何用数据结构表示这些资源
-- 资源的调度
-	- 如何描述一个 workload 的资源申请（spec），例如，“该容器需要 4 核和 12GB~16GB 内存”；
-	- 如何描述一台 node 当前的资源分配状态，例如已分配/未分配资源量，是否支持超分等
-	- 调度算法：如何根据 workload spec 为它挑选最合适的 node
-- 资源的限额
-	- 如何确保 workload 使用的资源量不超出预设范围
-	- 如何确保 workload 和系统/基础服务的限额，使二者互不影响
+调度是编排系统最重要的功能之一。对于 Kubernetes 这个编排系统而言，Node 是资源的提供者，Pod 是资源的使用者，Kuberntes 调度的职责便是实现两者之间最恰当的撮合。想要实现资源恰当的撮合，那么管理以及分配集群节点的资源，至少要清楚这么几个问题：
+- **资源模型的抽象**有哪些种类的资源，如何表示这些资源。
+- **资源的调度**如何描述一个 workload 的资源申请、如何描述一台 node 当前的资源分配状态，例如已分配/未分配资源量。
+- **资源的限额**如何确保 workload 使用的资源量不超出预设范围、如何确保 workload 和系统/基础服务的限额，使二者互不影响。
 
 ## 资源模型的抽象
 
@@ -27,8 +18,20 @@
 ```
 注意 Mebibyte 和 Megabyte 的区分，123 Mi = `123*1024*1024B` 、123 M = `1*1000*1000 B`。1M < 1Mi，显然使用带小 i 的更准确。
 
+
+由于每台 node 上会运行 kubelet/docker/containerd 等 k8s 相关基础服务，因此并不是一台 node 的所有资源都能给 k8s 创建 pod 用。 所以，k8s 在资源管理和调度时，需要把这些基础服务的资源使用量和 enforcement 单独拎出来。
+
+为此，k8s 提出了 Node Allocatable Resources 提案。
+
+
+- SystemReserved：操作系统的基础服务，例如 systemd、journald 等，k8s 不能管理这些资源的分配，但是能管理这些资源的限额。
+- KubeReserved：预留 k8s 基础设施服务，包括 kubelet/docker/containerd 等等使用的资源。
+- Allocatable：可供 k8s 创建 pod 使用的资源
+
 ## 资源申请及限制
 
+百闻不如一见，百见不如一干，如何描述一台 node 当前的资源分配状态。
+
 Kubernetes 抽象了两个概念 requests 和 limits 用以描述容器资源的分配。
 
 - **requests** 容器需要的最小资源量。举例来讲，对于一个 Spring Boot 业务容器，这里的 requests 必须是容器镜像中 JVM 虚拟机需要占用的最少资源。

http/protobuf.md

@@ -91,18 +91,14 @@ Varint 是一种使用一个或多个字节序列化整数的方法，会把整
 
 ### 3.2 Message 结构
 
-Protobuf 还有个很重要的特性：向后兼容。
-
-想搞明白 Protocol buffer 如何做到向后兼容，得解析 message 的结构设计。如图 2-11 所示，Protobuf 的 message 是一系列键值对，message 的二进制版本只是使用字段号(field's number 和 wire_type) 作为 key。每个字段的名称和声明类型只能在解码端通过引用消息类型的定义（即 .proto 文件）来确定，这一点也是人们常常说的 protocol buffer 比 JSON，XML 安全一点的原因，如果没有数据结构描述 .proto 文件，拿到数据以后无法解释成正常的数据。
+Protobuf 还有个很重要的特性：向后兼容。想搞明白 Protocol buffer 如何做到向后兼容，得先明白 message 的结构设计。如图 2-11 所示，Protobuf 的 message 是一系列键值对，message 的二进制版本只是使用字段号(field's number 和 wire_type) 作为 key。每个字段的名称和声明类型只能在解码端通过引用消息类型的定义（即 .proto 文件）来确定，如果没有数据结构描述 .proto 文件，拿到数据以后无法解释成正常的数据。这也是人们常说的 protocol buffer 比 JSON、XML 安全的原因，
 
 <div  align="center">
 	<img src="../assets/protobuf_example.png" width = "550"  align=center />
 	<p>图2-11 Message 结构</p>
 </div> 
 
-由于采用了 tag-value 的形式，所以 option 类型的字段如果有，就存在这个 message buffer 中，如果没有，就不会在这里，这一点也算是压缩了 message 的大小了。当消息编码时，键和值被连接成一个字节流，当消息被解码时，解析器需要能够跳过它无法识别的字段。这样，就可以将新字段添加到消息中，而不会破坏不知道它们的旧程序。
-
-这就是 Protobuf “向后”兼容特性的原理。
+由于采用了 tag-value 的形式，所以 option 类型的字段如果有，就存在这个 message buffer 中，如果没有，就不会在这里，这一点也算是压缩了 message 的大小了。当消息编码时，键和值被连接成一个字节流，当消息被解码时，解析器需要能够跳过它无法识别的字段。这样，就可以将新字段添加到消息中，而不会破坏不知道它们的旧程序，继而实现向后兼容特性。
 
 
 [^1]: 参见 https://github.com/protocolbuffers/protobuf