更新 metrics 内容

Observability/conclusion.md

@@ -8,4 +8,6 @@ https://github.com/cncf/tag-observability/blob/dec82aa5bd39a8834f58da0377d1e2b8f
 - 《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
+- https://medium.com/lightstephq/observability-will-never-replace-monitoring-because-it-shouldnt-eeea92c4c5c9
+
+- https://blog.devgenius.io/what-is-inverted-index-and-how-we-made-log-analysis-10-times-more-cost-effective-with-it-6afc6cc81d20

Observability/logging.md

@@ -1,34 +1,38 @@
 # 9.2.2 事件日志
 
-日志我们绝对不会陌生（绝大多数程序员生涯的第一行代码都是从打印 “hello world” 开始）。整个日志系统中最成熟的部分就是打印日志。尤其是本地日志打印，各式各样层出不穷的 logging Library，同步的异步的、有锁的无锁的、有上下文的无上下文的、高性能的低性能的，花活最多轮子也造的最多。
+作为最古老而又最具体的 Signal，日志是用来记录系统运行期间发生一系列离散的事件，特别是非预期的行为、异常情况。在缺乏有力的监控系统时，日志通常是工程师定位生产问题时最直接的手段。如果 Metrics 是告诉我们系统出现问题，那么日志就是告诉我们为什么会出现问题。
 
-作为最古老而又最具体的 Signal，日志记录的是系统运行期间发生的离散的事件，特别是非预期的行为、异常情况。大部分的时候都是基于可读性较好的文本。
-
-
-今天只要稍微复杂点的系统，已经很难只依靠 tail、grep、awk 来从日志中挖掘信息，对于日志的完整处理，除了打印，还包含着日志采集、日志传输、日志清洗、日志存储、分析与检索、告警与智能化响应一系列步骤。
+从程序员生涯的第一行代码打印 “hello world” 开始，再到从 Nginx 的 access.log 中通过 awk 挖掘信息，对于日志的生产和处理，相信程序员们绝对不会陌生。而今天只要稍微复杂点的系统，已经很难只依靠 tail、grep、awk 来从日志中挖掘信息。现在对日志的完整处理，除了打印，还包含着日志采集、日志传输、日志清洗、日志存储、分析与检索、告警与智能化响应一系列步骤。
 
+日志的处理和分析是典型的大数据分析场景之一，高吞吐写入、低成本海量存储、实时文本检索，业内通常以 ELK（倒排索引架构，消耗巨大的资源建立索引，巨大的存储成本）和 Grafana Loki（轻量索引，检索性能慢）为代表的两类权衡架构。
 
 ## ELK
 
 谈论实现一套完整的日志系统，相信用户或多或少都应该听说过这几个名词：Elasticsearch、ELK 或者 Elastic Stack。
 
-
 :::tip ELKB
 
 ELK 是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana。 Elasticsearch 是一个搜索和分析引擎。 Logstash 是服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如 Elasticsearch 等“存储库”中。Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。Beats 作为轻量级的数据搬运工，集合了多种单一用途数据采集器，将数据发送给 Logstash 或 ElasticSearch，其可扩展的框架及丰富的预置采集器将使工作事半功倍。
 :::
 
+总结起来， ELK 是一组开源组件组成的套件，组件之间作用不用，各司其事，可以像网络协议一样按分层来理解和归类，所以形成一个类似 TCP/IP Stack 类似的 ELK Stack，如下图所示。但明确的是 ELK 中的 Stack 肯定不是协议栈，跟协议没有任何区别。为严谨准确，我们把上面的所有名词简称为 Elastic。
+
 <div  align="center">
 	<img src="../assets/elk-stac.svg" width = "350"  align=center />
 	<p>Loki 架构：与 Prometheus、Grafana 密切集成</p>
 </div>
 
 ELK 中最核心的是 Elasticsearch，它是一个分布式搜索分析引擎，提供一种准实时搜索服务（生产环境中可以做到上报 10 秒后可搜，不惜成本万亿级日志秒级响应）。与 Elasticsearch 类似的产品还有商业公司 Splunk 和 Apache 开源的 Solr。事实上，Elasticsearch 和 Solr 都使用了著名的 Java 信息检索工具包 Lucene，Lucene 的作者就是大名鼎鼎的 Doug Cutting，如果你不知道谁是 Doug Cutting，那你一定听过他儿子玩具的名字 -- Hadoop。
 
-Elastic Stack 之所以流行的一个原因之一，可能是它的无侵入性。对于遗留系统的日志，它可以做到悄无声息地把处了上面打印日志之外的所有事情，全都给做了。
 
+Elasticsearch 在日志场景中的优势在于全文检索能力，能快速从海量的数据中检索出关键词匹配的日志，其底层核心技术是转置索引（Inverted index）。正常的索引是按 ID 查询详情，类似字典通过页码查询内容。转置索引反过来，将每一行文本进行分词，变成一个个词（Term），然后构建词（Term） -> 行号列表（Posting List） 的映射关系，将映射关系按照词进行排序存储。当需要查询某个词在哪些行出现的时候，先在 词 -> 行号列表 的有序映射关系中查找词对应的行号列表，然后用行号列表中的行号去取出对应行的内容。这样的查询方式，可以避免遍历对每一行数据进行扫描和匹配，只需要访问包含查找词的行，在海量数据下性能有数量级的提升。
 
+<div  align="center">
+	<img src="../assets/inverted-index.webp" width = "550"  align=center />
+	<p>inverted index</p>
+</div>
 
+转置索引为 ES 带来 快速检索能力的同时，也付出了写入吞出率低和存储占用高的代价。由于数据写入转置索引时需要进行分词、词典排序、构建排序表等 CPU 和内存密集型操作，导致写入吞出率大幅下降。而从存储的成本角度考虑，ES 会存储原始数据和转置索引，为了加速分析可能还需要存储一份列存数据。3份的冗余数据导致更高的存储空间占用。
 
 我们来看一个典型的 Elastic Stack 使用场景，大致系统架构如下（整合了消息队列和 Nginx 的架构）。
 
@@ -41,7 +45,7 @@ Elastic Stack 之所以流行的一个原因之一，可能是它的无侵入性
 
 采用全文检索对日志进行索引，优点是功能丰富，允许各类的复杂的操作。但是，如上的方案也明显透漏出架构复杂、维护困难、资源占用高。日志的大多数查询只关注一定时间范围和一些简单的参数（例如 host、service 等），很多功能往往用不上，ELK 方案像是杀鸡用牛刀。
 
-如果只是需求只是把日志集中起来，最多用来告警或者排查问题，那么我们可以把目光转向 Loki。
+如果只是需求只是把日志集中起来，操作多是近期范围内的查询，最多用来告警或者排查问题，那就没必要做成全文索引。那么我们可以把目光转向 Loki。
 
 ## Loki 
 
@@ -64,7 +68,6 @@ Loki 对 Kubernetes 友好，Promtail（日志收集代理）以 DaemonSet 方
 	<p>Loki Grafana </p>
 </div>
 
-
 总体而言，Loki 和 ELK 都是优秀的日志解决方案，具体如何选择取决于具体场景。 Loki 相对轻量，具有较高的可扩展性和简化的存储架构，若是数据的处理不那么复杂，且有时序属性，如应用程序日志和基础设施指标，并且应用使用 kubernetes Pod 形式部署，则选择 Loki 比较合适。ELK 则相对重量，需要复杂的存储架构和较高的硬件要求，部署和管理也比较复杂，适合更大的数据集和更复杂的数据处理需求。
 
 ## 日志展示

Observability/metrics.md

@@ -1,4 +1,4 @@
-# 9.2.1 聚合指标
+# 9.2.1 聚合度量
 
 作为传统监控和告警领域的代名词，Metrics 最广为人知，也被各类可观测系统支持的最丰富。Metrics 一般是用来计算 Events 发生数量的数据集，例如服务 QPS、API 响应延迟、某个接口的失败数等。它们大部分都是以数字化指标出现，特征是可聚合性，在数据的处理上，Metrics 可以是实时的，也可能是区间范围的，是跟随着时间变化的时序数据。既能做常见的监控告警，也可以用来做趋势分析。
 
@@ -8,6 +8,18 @@
 由于目前并没有 Metrics 采集的标准 API，所以不同的监控系统在收集 Metrics 数据时采取的手段也可能不一样，但大部分无非都是通过 PUSH 到中心 Collector 方式采集 Metrics（比如各种 Agent 采集器，Telegraf 等）； 又或者是中心 Collector 通过 PULL 的方式去主动获取 Metrics（比如 Prometheus）。
 
 
+对于一个监控系统而言，核心要解决的问题其实就三个：
+
+- 监控指标用什么形式表示
+- 怎么收集和存储指标
+- 怎么利用指标生成报表
+
+## Metrics 类型
+
+- 计数（counter）：一个只能增加或重置的度量值（即该值只能比之前多）
+
+Prometheus 最早由 SoundCloud 开发，后来捐赠到开源社区。在2016年，加入 CNCF，是仅次于 Kubernetes 的第二个项目。
+
 时序数据库
 
 TSDB 是专门用来存储随时间变化的数据，如股票价格、传感器数据等。时间序列（time-series）的是某个变量随时间变化的所有历史，而样本 （sample）指的是历史中该变量的瞬时值。

Observability/summary.md

@@ -1,13 +1,3 @@
 # 第九章：系统可观测性
 
-可观测性（Observability）一词最早出现在控制论领域，有着几十年的历史。随着云原生时代的到来，2018 年，CNCF 率先将可观测性的概念引入 IT 领域，并称可观测性是云原生时代必须具备的能力（哎，又诞生一个得系统学习的领域）。从生产所需到概念发声，加之包括 Google 在内的众多大厂一拥而上。至此，”可观测性“逐渐取代”监控“，成为云原生技术领域最热门的话题之一。
-
-:::tip 额外知识
-
-控制理论中的可观察性（observability）是指系统可以由其外部输出推断其内部状态的程度。可观察性最早是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念，若以信号流图来看，若所有的内部状态都可以输出到输出信号，此系统即有可观察性。
-
-<div  align="center">
-	<img src="../assets/State_transition_SFG.svg.png" width = "350"  align=center />
-</div>
-
-:::
+可观测性（Observability）一词最早出现在控制论领域（最早是匈牙利裔工程师鲁 Rudolf E. Kálmán 针对线性动态系统提出的概念），有着几十年的历史。随着云原生时代的到来，2018 年，CNCF 率先将可观测性的概念引入 IT 领域，并称可观测性是云原生时代必须具备的能力，从生产所需到概念发声，加之包括 Google 在内的众多大厂一拥而上。至此，”可观测性“逐渐取代”监控“，成为云原生技术领域最热门的话题之一。