更新可观测内容

Observability/OpenTelemetry.md

@@ -1,4 +1,4 @@
-# 9.3 可观测性大统一 
+# 9.3 可观测性大一统
 
 建设完善的可观测体系，很可能会形成链路监控、日志监控、指标监控等多套不同的监控系统，要打通是相当困难的。不同的业务线间，日志规则不互通，要完全互通也很困难。系统一旦过多，相关维护以及故障排除的时间成本就会大幅增加。
 

Observability/conclusion.md

@@ -10,4 +10,4 @@ https://github.com/cncf/tag-observability/blob/dec82aa5bd39a8834f58da0377d1e2b8f
 
 - 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
+- 《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

Observability/metrics.md

@@ -2,8 +2,8 @@
 
 作为传统监控和告警领域的代名词，Metrics 最广为人知，也被各类可观测系统支持的最丰富。Metrics 一般是用来计算 Events 发生数量的数据集，例如服务 QPS、API 响应延迟、某个接口的失败数等。它们大部分都是以数字化指标出现，特征是可聚合性，在数据的处理上，Metrics 可以是实时的，也可能是区间范围的，是跟随着时间变化的时序数据。既能做常见的监控告警，也可以用来做趋势分析。
 
-- 实时监控和警报，Metrics 常见的用于是看板，并在系统在超过阈值或者行为异常时自动触发报警。
-- 趋势分析：Metrics 还用在趋势分析，同时还可以在事件发生后提供历史数据分析，修复或者监控以防止潜在问题再次发生。
+Metrics 提供的信息可用于系统整体行为和监控状况的分析，它不一定能揭示问题根本原因，但可以作为发现问题的起点。一个典型例子是你收到一条告警”请求成功率跌到了 10%“，你意识到不妙，立即开始处理，然后结合其他 Signals 去找到 root cause，从而解决问题。
+
 
 由于目前并没有 Metrics 采集的标准 API，所以不同的监控系统在收集 Metrics 数据时采取的手段也可能不一样，但大部分无非都是通过 PUSH 到中心 Collector 方式采集 Metrics（比如各种 Agent 采集器，Telegraf 等）； 又或者是中心 Collector 通过 PULL 的方式去主动获取 Metrics（比如 Prometheus）。
 
@@ -14,14 +14,48 @@
 - 怎么收集和存储指标
 - 怎么利用指标生成报表
 
+Prometheus 最初的定位是一个监控和报警系统。
+
+<div  align="center">
+	<img src="../assets/prometheus-alert.png" width = "500"  align=center />
+</div>
+
+为了实现这个功能，需要实现几个独立的子功能。检测指标、收集指标、存储指标、查询指标、警报指标。每个子功能独立实现，通过搭积木的方式，就可以形成一个功能强大的监控告警系统。
+
 <div  align="center">
 	<img src="../assets/prometheus-arch.png" width = "500"  align=center />
 </div>
 
-Exporter 用户采集费原生支持 prometheus 的第三方系统或者服务的指标数据，并将其转换为 prometheus 可以识别的格式。Exporter 运行为一个单独的服务，周期性的从目标系统中拉取原始指标，然后提供一个 HTTP 接口，使得 prometheus 可以从中抓取已经转换的指标数据。得益于 Prometheus 的良好社区生态，现在已经有大量各种用途的 Exporter，让 Prometheus 的监控范围几乎能涵盖所有用户所关心的目标。
+Prometheus 的架构设计中，Prometheus Server 主要任务负责数据的收集，存储并且对外提供数据查询支持，并不直接服务监控特定的目标。因此为了能够能够监控到某些东西，如主机的CPU使用率，我们需要使用到 Exporter。Prometheus 周期性的从Exporter（Exporter 实例称 target ）暴露的 HTTP 服务地址（通常是/metrics）拉取监控样本数据。
+
+<div  align="center">
+	<img src="../assets/prometheus-exporter.png" width = "500"  align=center />
+</div>
+
+从上面的描述中可以看出 Exporter 可以是一个相对开放的概念，其可以是一个独立运行的程序独立于监控目标以外，也可以是直接内置在监控目标中。只要能够向 Prometheus 提供标准格式的监控样本数据即可。得益于 Prometheus 的良好社区生态，现在已经有大量各种用途的 Exporter，涵盖了从基础设施、中间件以及网络等各个方面，让 Prometheus 的监控范围几乎能涵盖所有用户所关心的目标。
+
 
+| 范围 | 常用 Exporter |
+|:--|:--|
+ | 数据库 |  MySQL Exporter、Redis Exporter、MongoDB Exporter、MSSQL Exporter 等 | 
+ | 硬件 | Apcupsd Exporter、IoT Edison Exporter、IPMI Exporter、Node Exporter 等 | 
+ | 消息队列 |  Beanstalkd Exporter、Kafka Exporter、NSQ Exporter、RabbitMQ Exporter 等 |
+ | 存储 | Ceph Exporter、Gluster Exporter、HDFS Exporter、ScaleIO Exporter 等 | 
+ | HTTP服务 | Apache Exporter、HAProxy Exporter、Nginx Exporter 等 |
+ | API服务 | AWS ECS Exporter、Docker Cloud Exporter、Docker Hub Exporter、GitHub Exporter 等 | 
+ | 日志 | Fluentd Exporter、Grok Exporter 等 | 
+ | 监控系统 |  Collectd Exporter、Graphite Exporter、InfluxDB Exporter、Nagios Exporter、SNMP Exporter 等 |
+ | 其它 | Blockbox Exporter、JIRA Exporter、Jenkins Exporter、Confluence Exporter 等|
 
 
+Prometheus 的数据是典型的时序数据，Prometheus 本身会将。要注意的是，本地存储不可复制，无法构建集群，如果本地磁盘或节点出现故障，存储将无法扩展和建议。因此，一般只能把本地存储视为近期数据的短暂滑动窗口。
+
+Prometheus 的作者及社区核心开发者都秉承一个理念：Prometheus 只聚焦核心的功能，扩展性的功能留给社区解决，所以 Prometheus 自诞生至今都是单实例不可扩展的。
+
+
+尽管单实例的 Prometheus 已经足够强大，但还是存在部分需求是其无法满足的，如跨集群聚合、更长时间的存储等。为了扩展 Prometheus，社区给出了多种方案。
+
+2017 年，Prometheus 加⼊ Remote Read/Write API，自此之后社区涌现出大量长期存储的方案，如 Thanos、Grafana Cortex/Mimir、VictoriaMetrics、Wavefront、Splunk、Sysdig、SignalFx、InfluxDB、Graphite 等。
 
 ## Metrics 类型
 
@@ -52,8 +86,6 @@ TSDB 是专门用来存储随时间变化的数据，如股票价格、传感器
 为了追求极致性能和极致成本，大家都在针对海量数据和使用场景，持续改进和优化数据的存储结构设计、各种高效索引机制、和查询效率。从单点技术或者关键技术上来讲，有趋同性和同质化的大趋势
 
 
-Metrics 提供的信息可用于系统整体行为和监控状况的分析，它不一定能揭示问题根本原因，但可以作为发现问题的起点。一个典型例子是你收到一条告警”请求成功率跌到了 10%“，你意识到不妙，立即开始处理，然后结合其他 Signals 去找到 root cause，从而解决问题。
-
 prometheus-vs-victoriametrics[^1]
 
 ||Prometheus| VictoriaMetrics | 
@@ -71,6 +103,15 @@ prometheus-vs-victoriametrics[^1]
 
 https://db-engines.com/en/ranking/time+series+dbms
 
-## 告警
+## 生成报表
+
+Prometheus 定义了功能强大的 promQL，可以满足各种复杂的查询场景。
+
+Grafana提供了对PromQL的完整支持，如下所示，通过Grafana添加Dashboard并且为该Dashboard添加一个类型为“Graph”的面板。 并在该面板的“Metrics”选项下通过PromQL查询需要可视化的数据：
+
+<div  align="center">
+	<img src="../assets/first_grafana_dashboard.png" width = "500"  align=center />
+</div>
+
 
 [^1]: 参见 https://last9.io/blog/prometheus-vs-victoriametrics/