更新可观测性日志

Observability/logging.md

@@ -5,76 +5,77 @@ Logs 作为最古老而又最具体的一个 Signal，大部分的时候都是
 可观测性白皮书中把日志分为5类：Application Logs、Security Log、System Log、Audit log、Infrastructure log。
 
 
-你可能不知道 Metrics、Tracing，但你一定了解点 logging。logging 系统中最成熟的部分就是打印日志。尤其是本地日志打印，各式各样层出不穷的 logging Library，同步的异步的、有锁的无锁的、有上下文的无上下文的、高性能的低性能的，花活最多轮子也造的最多。
+日志级别，不同的系统差别较大，但形成共识的级别为 ERROR、WARNING、INFO、DEBUG。生产环境用 ERROR，开发阶段用 DEBUG。
 
-日志最大的挑战是数据量大（PB 级别）
+其次是日志库，logging 系统中最成熟的部分就是打印日志。尤其是本地日志打印，各式各样层出不穷的 logging Library，同步的异步的、有锁的无锁的、有上下文的无上下文的、高性能的低性能的，花活最多轮子也造的最多。
 
-日志最出名的方案莫过于 ELK。
+
+或多或少都应该听说过这几个名词：Elasticsearch、ELKB、Elastic Stack
 
 :::tip ELKB
 
 ELK 是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana。 Elasticsearch 是一个搜索和分析引擎。 Logstash 是服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如 Elasticsearch 等“存储库”中。Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。Beats 作为轻量级的数据搬运工，集合了多种单一用途数据采集器，将数据发送给 Logstash 或 ElasticSearch，其可扩展的框架及丰富的预置采集器将使工作事半功倍。
 :::
 
+<div  align="center">
+	<img src="../assets/elk-stac.svg" width = "350"  align=center />
+	<p>Loki 架构：与 Prometheus、Grafana 密切集成</p>
+</div>
 
-ELK 中最核心的是 Elasticsearch，它是一个分布式搜索分析引擎，提供一种准实时（Near Real Time）搜索服务。与 Elasticsearch 类似的产品还有商业公司 Splunk 和 Apache 开源的 Solr。事实上，Elasticsearch 和 Solr 都使用了著名的 Java 信息检索工具包 Lucene，而且 Solr 还要更纯正一些，Lucene 的作者就是大名鼎鼎的 Doug Cutting，如果你不知道谁 Doug Cutting，那你一定听过他儿子玩具的名字 -- Hadoop，是不是比 MySQL 创始人分别用自己两个女儿的名字命名 MySQL 和 MariaDB 更牛逼？
-
+ELK 中最核心的是 Elasticsearch，它是一个分布式搜索分析引擎，提供一种准实时搜索服务（生产环境中可以做到上报 10 秒后可搜，不惜成本万亿级日志秒级响应）。与 Elasticsearch 类似的产品还有商业公司 Splunk 和 Apache 开源的 Solr。事实上，Elasticsearch 和 Solr 都使用了著名的 Java 信息检索工具包 Lucene，Lucene 的作者就是大名鼎鼎的 Doug Cutting，如果你不知道谁是 Doug Cutting，那你一定听过他儿子玩具的名字 -- Hadoop。
 
 Elastic Stack 之所以流行的一个原因之一，可能是它的无侵入性。对于遗留系统的日志，它可以做到悄无声息地把处了上面打印日志之外的所有事情，全都给做了。
 
+一个典型的日志系统，一般有以下几个部分组成：
+
+- 日志打印
+- 日志采集
+- 日志传输
+- 日志清洗
+- 日志存储
+- 分析与检索
+- 告警与智能化响应
+
+
 我们来看一个典型的 Elastic Stack 使用场景，大致系统架构如下（整合了消息队列和 Nginx 的架构）。
 
 <div  align="center">
 	<img src="../assets/ELK.png" width = "550"  align=center />
-	<p>Loki 架构：与 Prometheus、Grafana 密切集成</p>
+	<p>Elastic Stack 日志系统</p>
 </div>
 
-
 这个系统中，Beats 部署到日志所在地，用来收集原始数据，然后使用 MQ 做缓冲换取更好的吞吐，接着发给 logstash 做数据清洗，最后落地到 es 集群并进行索引，使用时通过 Kibana 来检索和分析，如果有必要挂上 Nginx 做各类访问控制。
 
+采用全文检索对日志进行索引，优点是功能丰富，允许各类的复杂的操作。但是，如上的方案也明显透漏出架构复杂、维护困难、资源占用高。日志的大多数查询只关注一定时间范围和一些简单的参数（例如 host、service 等），很多功能往往用不上，ELK 方案像是杀鸡用牛刀。
 
-采用全文检索对日志进行索引，优点是功能丰富，允许复杂的操作。但是，这些方案往往规模复杂，资源占用高，很多功能往往用不上，大多数查询只关注一定时间范围和一些简单的参数（如：host、service 等），使用这些解决方案难免感觉杀鸡用牛刀。
+如果只是需求只是把日志集中起来，最多用来告警或者排查问题，那么我们可以把目光转向 Loki。
 
 ## 低成本方案 Loki
 
-如果只是需求只是把日志集中起来，最多用来排查问题，且对成本敏感。那么久不得不提日志领域的另外一个方案，Grafana Labs 公司推出 Loki，官方的项目介绍是 like Prometheus, but for logs，类似于 Prometheus 的日志系统。
+Loki 是 Grafana Labs 公司推出的类似于 Prometheus 的日志系统（官方的项目介绍是 like Prometheus，but for logs）。
+
+Loki 一个明显的特点是非常经济，Loki 不再根据日志的原始内容建立大量的全文索引，而是借鉴了 Prometheus 核心的思想，使用标签去对日志进行特征标记，然后归集统计。Loki 只索引与日志相关的元数据标签，而日志内容则以压缩方式存储于对象存储中，不做任何索引，这样的话，能避免大量的内存资源占用，转向廉价的硬盘存储。相较于 ES 这种全文索引的系统，数据可在十倍量级上降低，加上使用对象存储，最终存储成本可降低数十倍甚至更低。
 
 <div  align="center">
 	<img src="../assets/loki-arc.png" width = "550"  align=center />
 	<p>Loki 架构：与 Prometheus、Grafana 密切集成</p>
 </div>
 
-
-Loki 一个明显的特点是非常经济，Loki 不再根据日志的原始内容建立大量的全文索引，而是借鉴了 Prometheus 核心的思想，使用标签去对日志进行特征标记，然后归集统计。Loki 只索引与日志相关的元数据标签，而日志内容则以压缩方式存储于对象存储中, 不做任何索引，这样的话，能避免大量的内存资源占用，转向廉价的硬盘存储。相较于 ES 这种全文索引的系统，数据可在十倍量级上降低，加上使用对象存储，最终存储成本可降低数十倍甚至更低。
-
-
-Loki 使用与 Prometheus 相同的服务发现和标签重新标记库，编写了 Pormtail，在 Kubernetes 中 Promtail 以 DaemonSet 方式运行在每个节点中，通过 Kubernetes API 得到日志的正确元数据，并将它们发送到 Loki。
-
-也正是因为这个原因，通过这些标签，既可以查询日志的内容，也可以查询到监控的内容，这两种查询被很好的兼容，节省了分别存储相关日志和监控数据的成本，也减少了查询的切换成本。
-
+不难看出，Loki 的架构非常简单，使用了和 prometheus 一样的标签来作为索引，也正是因为这个原因，通过这些标签，既可以查询日志的内容，也可以查询到监控的内容，这两种查询被很好的兼容，节省了分别存储相关日志和监控数据的成本，也减少了查询的切换成本。
 
 说白了，Loki 吸引人的地方就在于拥有和 Prometheus 类似机制的时序数据库以及方便拓展的硬盘资源。
 
-数据由标签、时间戳、内容组成
 
-```
-{
-  "stream": { 
-    "label1": "value1",
-    "label1": "value2"
-  }, # 标签
-  "values": [
-    ["<timestamp nanoseconds>","log content"], # 时间戳，内容
-    ["<timestamp nanoseconds>","log content"]
-  ]
-}
-```
+Promtail（日志收集代理）以 DaemonSet 方式运行在每个节点中，负责收集日志并将其发送给 Loki。
 
-总体而言，Loki和ELK都是优秀的日志解决方案，适合不同的使用场景。Loki相对轻量级，具有较高的可扩展性和简化的存储架构，但需要额外的组件和有一定的学习曲线。ELK则具有丰富的可视化选项和插件库，易于学习，但相对重量级，需要复杂的存储架构和较高的硬件要求，部署和管理也比较复杂。
 
+<div  align="center">
+	<img src="../assets/loki-dashboard.jpeg" width = "550"  align=center />
+	<p>Loki Grafana </p>
+</div>
 
-具体如何选择取决于具体场景，若是数据量适中，数据属于时序类，如应用程序日志和基础设施指标，并且应用使用kubernetes Pod形式部署，则选择Loki比较合适；而ELK则适合更大的数据集和更复杂的数据处理需求，以及更多其他组件的日志收集场景。
 
+总体而言，Loki 和 ELK 都是优秀的日志解决方案，具体如何选择取决于具体场景。 Loki 相对轻量，具有较高的可扩展性和简化的存储架构，若是数据的处理不那么复杂，且有时序属性，如应用程序日志和基础设施指标，并且应用使用 kubernetes Pod 形式部署，则选择 Loki 比较合适。ELK 则相对重量，需要复杂的存储架构和较高的硬件要求，部署和管理也比较复杂，适合更大的数据集和更复杂的数据处理需求。
 
 ## 日志展示
 

Observability/metrics.md

@@ -23,7 +23,7 @@ TSDB 是专门用来存储随时间变化的数据，如股票价格、传感器
 - 时序的唯一性：某一个时刻的某个指标只有一条数据（或点），即时出现多条数据也会被认为是同一条数据（或点）
 - 单条数据并不重要
 
-
+## 存储
 
 回到我们的主角 Prometheus， 它会将所有采集到的样本（sample）数据以时间序列（time-series）的方式保存在内存数据库中，并且定时保存到硬盘上。时间序列是按照时间戳和值的序列顺序存放的，每条time-series通过指标名称（metrics name）和一组标签集（labelset）命名。
 
@@ -50,4 +50,6 @@ prometheus-vs-victoriametrics[^1]
 
 https://db-engines.com/en/ranking/time+series+dbms
 
+## 告警
+
 [^1]: 参见 https://last9.io/blog/prometheus-vs-victoriametrics/

Observability/signals.md

@@ -2,9 +2,9 @@
 
 工业界和学术界一般会将可观测性的遥测数据分解为三个更具体方向进行研究，它们分别是**事件日志（Logging）、链路追踪（Tracing）和聚合度量（Metrics）**。
 
-- Metrics（聚合度量），一般用来计算事件发生数量的数据集，这些数据通常具有原子性、且可以聚合。从操作系统到应用程序，任何事物都会产生 Metrics 数据，这些数据可以用来度量操作系统或者应用是否健康。
-- Logging（事件日志），描述一系列离散的事件，在缺乏有力的监控系统时，Logging 数据通常是工程师在定位问题时最直接的手段。如果说 Metrics 告诉你应用程序出现问题，那么 Logging 就告诉你为什么出现问题。
-- Tracing（链路追踪），分布式系统中多个服务之间或多或少存在依赖，Tracing 通过有向无环图的方式记录分布式系统依赖中发生事件之间的因果关系。
+- Metrics（聚合度量）：一般用来计算事件发生数量的数据集，这些数据通常具有原子性、且可以聚合。从操作系统到应用程序，任何事物都会产生 Metrics 数据，这些数据可以用来度量操作系统或者应用是否健康。
+- Logging（事件日志）：描述一系列离散的事件，在缺乏有力的监控系统时，Logging 数据通常是工程师在定位问题时最直接的手段。如果说 Metrics 告诉你应用程序出现问题，那么 Logging 就告诉你为什么出现问题。
+- Tracing（链路追踪）：分布式系统中多个服务之间或多或少存在依赖，Tracing 通过有向无环图的方式记录分布式系统依赖中发生事件之间的因果关系。
 
 
 2017 年的分布式追踪峰会结束后，Peter Bourgon 撰写了总结文章《Metrics, Tracing, and Logging》[^1]系统地阐述了这三者的定义、特征以及它们之间的关系与差异，受到了业界的广泛认可。