diff --git a/Observability/OpenTelemetry.md b/Observability/OpenTelemetry.md index cdd7d31f..8acd8d5f 100644 --- a/Observability/OpenTelemetry.md +++ b/Observability/OpenTelemetry.md @@ -1,4 +1,4 @@ -# 9.3 可观测性大统一 +# 9.3 可观测性大一统 建设完善的可观测体系，很可能会形成链路监控、日志监控、指标监控等多套不同的监控系统，要打通是相当困难的。不同的业务线间，日志规则不互通，要完全互通也很困难。系统一旦过多，相关维护以及故障排除的时间成本就会大幅增加。 diff --git a/Observability/conclusion.md b/Observability/conclusion.md index aa496a56..f4d2a1a5 100644 --- a/Observability/conclusion.md +++ b/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 \ No newline at end of file +- 《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 \ No newline at end of file diff --git a/Observability/metrics.md b/Observability/metrics.md index f0957d24..c2299c57 100644 --- a/Observability/metrics.md +++ b/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 最初的定位是一个监控和报警系统。 + +
+ +
+ +为了实现这个功能，需要实现几个独立的子功能。检测指标、收集指标、存储指标、查询指标、警报指标。每个子功能独立实现，通过搭积木的方式，就可以形成一个功能强大的监控告警系统。 +
-Exporter 用户采集费原生支持 prometheus 的第三方系统或者服务的指标数据，并将其转换为 prometheus 可以识别的格式。Exporter 运行为一个单独的服务，周期性的从目标系统中拉取原始指标，然后提供一个 HTTP 接口，使得 prometheus 可以从中抓取已经转换的指标数据。得益于 Prometheus 的良好社区生态，现在已经有大量各种用途的 Exporter，让 Prometheus 的监控范围几乎能涵盖所有用户所关心的目标。 +Prometheus 的架构设计中，Prometheus Server 主要任务负责数据的收集，存储并且对外提供数据查询支持，并不直接服务监控特定的目标。因此为了能够能够监控到某些东西，如主机的CPU使用率，我们需要使用到 Exporter。Prometheus 周期性的从Exporter（Exporter 实例称 target ）暴露的 HTTP 服务地址（通常是/metrics）拉取监控样本数据。 + +
+ +
+ +从上面的描述中可以看出 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查询需要可视化的数据： + +
+ +
+ [^1]: 参见 https://last9.io/blog/prometheus-vs-victoriametrics/ \ No newline at end of file diff --git a/assets/first_grafana_dashboard.png b/assets/first_grafana_dashboard.png new file mode 100644 index 00000000..3e44e234 Binary files /dev/null and b/assets/first_grafana_dashboard.png differ diff --git a/assets/prometheus-alert.png b/assets/prometheus-alert.png new file mode 100644 index 00000000..2373140f Binary files /dev/null and b/assets/prometheus-alert.png differ diff --git a/assets/prometheus-exporter.png b/assets/prometheus-exporter.png new file mode 100644 index 00000000..baaa5e1f Binary files /dev/null and b/assets/prometheus-exporter.png differ