图解 | 监控系统 Prometheus 的原理

本篇将会以图解的方式剖析 Prometheus 的原理。本文主要内容如下：

一、Prometheus 是什么？

ELK Stack 日志收集和检索平台想必大家应该比较熟悉，Elasticsearch + Filebeat + Logstash + Kibana。

ELK 架构

而 Prometheus 就相当于一整个 ELK，但是它其实并不是适合存储大量日志，也不适合长期存储（默认存储 15 天）。它的优势是查看最近的趋势数据，以及告警机制。下图是 Prometheus 架构图：

Prometheus architecture，来自官网

Prometheus 它是从应用程序中实时获取时间序列数据，然后通过功能强大的规则引擎，帮助你识别监控环境所需的信息。

Prometheus作为一个基于度量的系统，不适合存储事件或者日志等，它更多地展示的是趋势性的监控。如果用户需要数据的精准性，可以考虑ELK或其他日志架构。

Prometheus 特点

一款开源监控工具。
基于时间序列数据库TSDB存储，golang 实现
Soundcloud 公司研发，源于谷歌borgmon
多维度(标签)
使用拉模式(Pull-based) 获取数据
白盒&黑盒的监控都支持，DevOps友好
Metrics & Alert模式，不是 loggging/tracing
社区生态丰富(多语言，各种exporters)
单机性能
- 消费百万级时间序列
- 支持上千个 targets

Prometheus 的不足

Prometheus 主要针对性能和可用性监控，不适用于针对日志（Log）、事件（Event）、调用链（Tracing）等的监控。

关注的是近期的数据，默认存储 15 天的监控数据。

二、Prometheus 指标收集

下图是 Prometheus WebUI 界面，里面展示了 Targets 和 Endpoint，说明了当前哪些目标服务是可以被 Prometheus 抓取的。

Endpoint：端点，可以抓取的指标来源。
Target：目标，包含了端点地址，端口的状态等信息。

下面是 Prometheus 抓取目标的配置：

- job_name: mysqld
    static_configs:
      - targets: ['192.168.0.100:9104']
        labels:
          instance: mysql-exporter

Job：代表了一组相同角色或功能的目标。
Instance：在当前主机上运行的 exporter 监控程序被称为一个实例。

抓取到目标的指标数据后，会生成时间序列数据，然后存储在 Prometheus 服务器本地，也可以设置从服务器发送数据到外部存储器或其他时间序列数据库。

三、Prometheus 采集方式

Prometheus 抓取数据可以通过直接采集和间接采集两种。

直接采集和简介采集

直接采集就是埋点式的，比如你自己的应用程序用 Prometheus 客户端的代码自己去埋点。比如 etcd、kubenetes、docker 这种就是直接采集，它已经将埋点埋好了，把 metrics 断点暴露出来了。这些就是对 Prometheus 友好的，已经埋好点了，直接用 Prometheus 抓取就好了。

但是对于一些黑盒系统，比如操作系统、Redis、MySQL 这种，它们是成熟的产品，我们一般不会拿过来改，这种时候我们一般采用间接采集的方式。

四、Exporter 监控程序

当 Prometheus 使用间接采集的方式时，需要用到 Exporter，中文翻译过来就是出口商，我们可以理解为将数据从内部导出来。

Exporter 是 Prometheus 中的一个概念，类似一个边车或者 Agent，如下图所示。

间接采集方式中的 exporter

Exporter 它用来对黑盒系统进行采集，它会从黑盒中抓取数据，然后将 metrics 端点暴露出来供 Prometheus 抓取。Prometheus 就可以间接的通过 Exporter 抓取这些 target 上的数据。

Exporter本质上是将收集的数据转化为对应的文本格式，并提供 HTTP 接口，供 Prometheus 定期采集数据。

Exporter 有很多，比如针对操作系统的 Node-Exporter，对于 MySQL 的 mysql-exporter 等等

Linux 服务器内部部署了一个 node-exporter 服务，来收集 Linux 服务器上的磁盘、内存等数据。然后暴露了一个端口，Prometheus 通过这个端口来抓取数据。

而 MySQL 服务器上的 mysql-exporter 也是类似，mysql-exporter 其实不必部署到要监控的 MySQL 服务器上，可以独立部署到不同机器上。

从 Prometheus 的客户端界面上也可以看到正在抓取哪些 Targets，而这些 targets 都是通过 exporter 暴露端口的。

从这个官网链接中看到很多 Exporter

https://prometheus.io/docs/instrumenting/exporters/

五、PromQL

PromQL 看名字很 SQL 很像，它其实是另外一种查询语言。

Prometheus提供了一种功能强大的表达式语言 PromQL（Prometheus Query Language）。PromQL允许用户实时选择和汇聚时间序列数据，是 Prometheus 自己开发的数据查询 DSL（领域特定语言），使用这个查询语言能够进行各种聚合、分析和计算，使管理员能够根据指标更好地了解系统性能。

如下图所示，PromQL 内置在 Prometheus 中。通过 Prometheus WebUI、Grafana 和 API Clients 来进行查询。

下面是 Prometheus WebUI 界面：

下面是 Grafana 的界面，通常我们会配合 Grafana 一起来监控。

六、监控告警

发送告警

Prometheus 告警规则触发后，告警规则被触发后，才会将信息发送给独立组件 Alertmanager 上，经过对告警的处理后，最终通过接收器（如Email）通知用户。（告警规则是在 Prometheus server 端定义的）

告警的原理图

在 Prometheus 监控体系中，指标的采集存储与告警是分开的。
我们使用 Prometheus server 采集各类监控指标，然后基于PromQL对这些指标定义阈值告警规则（Rules）。
Prometheus server对告警规则周期性地进行计算，如果满足告警触发条件，便生成一条告警信息，并将其推送到Alertmanager组件。
收到告警信息后，Alertmanager会处理告警，进行分组（grouping）并将它们路由（routing）到正确的接收器（receiver），如Email、钉钉等，最终把异常事件的通知发送给接收者。

七、总结

通过图解的方式，分别介绍了 Prometheus 的优势和劣势、指标收集、采集方式、Exporter、PromQL、监控告警，希望能给大家云原生的监控之路上带来一些启发~