浅析监控系统 Prometheus 的原理
你好，我是悟空。
最近公司正在往云原生进行转型，想拥有一套适合当前项目的监控系统，基于这个出发点，我们团队考虑使用 Prometheus 和 Grafana 组件。本篇将会以图解的方式剖析 Prometheus 的原理。
本文主要内容如下：
一、Prometheus 是什么？
ELK Stack 日志收集和检索平台想必大家应该比较熟悉，Elasticsearch Filebeat Logstash Kibana。
ELK 架构而 Prometheus 就相当于一整个 ELK，但是它其实并不是适合存储大量日志，也不适合长期存储（默认存储 15 天）。它的优势是查看最近的趋势数据，以及告警机制。下图是 Prometheus 架构图：
Prometheus architecture，来自官网Prometheus 它是从应用程序中实时获取时间序列数据，然后通过功能强大的规则引擎，帮助你识别监控环境所需的信息。
Prometheus作为一个基于度量的系统，不适合存储事件或者日志等，它更多地展示的是趋势性的监控。如果用户需要数据的精准性，可以考虑ELK或其他日志架构。另外，APM 更适用于链路追踪的场景。
Prometheus 特点
- 一款开源**监控工具**。
- 基于**时间序列数据库**TSDB存储，golang 实现
- **Soundcloud** 公司研发，源于谷歌**borgmon**
- **多维度**(标签)
- 使用**拉模式**(Pull-based) 获取数据
- **白盒&黑盒**的监控都支持，**DevOps**友好
- **Metrics & Alert**模式，不是 loggging/tracing
- **社区生态丰富**(多语言，各种exporters)
- **单机性能**
- 消费百万级时间序列
- 支持上千个 targets
Prometheus 的不足
Prometheus 主要针对性能和可用性监控，不适用于针对日志（Log）、事件（Event）、调用链（Tracing）等的监控。
关注的是近期的数据，默认存储 15 天的监控数据。
二、Prometheus 指标收集
- Endpoint：端点，可以抓取的指标来源。
- Target：目标，包含了端点地址，端口的状态等信息。
下面是 Prometheus 抓取目标的配置：
代码语言：shell复制 - job_name: prometheus
static_configs:
- targets: ['localhost:9090']
labels:
instance: prometheus- Job：代表了一组相同角色或功能的目标。
- Instance：在当前主机上运行的 exporter 监控程序被称为一个实例。
抓取到目标的指标数据后，会生成时间序列数据，然后存储在 Prometheus 服务器本地，也可以设置从服务器发送数据到外部存储器或其他时间序列数据库。
三、Prometheus 采集方式
Prometheus 抓取数据可以通过**直接采集**和**间接采集**两种。
直接采集和简介采集直接采集就是埋点式的，比如你自己的应用程序用 Prometheus 客户端的代码自己去埋点。比如 etcd、kubenetes、docker 这种就是直接采集，它已经将埋点埋好了，把 metrics 断点暴露出来了。这些就是对 Prometheus 友好的，已经埋好点了，直接用 Prometheus 抓取就好了。
但是对于一些黑盒系统，比如操作系统、Redis、MySQL 这种，它们是成熟的产品，我们一般不会拿过来改，这种时候我们一般采用间接采集的方式。
四、Exporter 监控程序
当 Prometheus 使用间接采集的方式时，需要用到 Exporter，中文翻译过来就是出口商，我们可以理解为将数据从内部导出来。
Exporter 是 Prometheus 中的一个概念，类似一个边车或者 Agent，如下图所示。
间接采集方式中的 exporterExporter 它用来对黑盒系统进行采集，它会从黑盒中抓取数据，然后将 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 暴露端口的。
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 的界面：
六、监控告警
发送告警
Prometheus 告警规则触发后，告警规则被触发后，才会将信息发送给独立组件 Alertmanager 上，经过对告警的处理后，最终通过接收器（如Email）通知用户。（告警规则是在 Prometheus server 端定义的）
告警的原理图- 在 Prometheus 监控体系中，指标的采集存储与告警是分开的。
- 我们使用 Prometheus server 采集各类监控指标，然后基于PromQL对这些指标定义阈值告警规则（Rules）。
- Prometheus server对告警规则周期性地进行计算，如果满足告警触发条件，便生成一条告警信息，并将其推送到Alertmanager组件。
- 收到告警信息后，Alertmanager会处理告警，进行分组（grouping）并将它们路由（routing）到正确的接收器（receiver），如Email、钉钉等，最终把异常事件的通知发送给接收者。
七、总结
通过图解的方式，分别介绍了 Prometheus 的优势和劣势、指标收集、采集方式、Exporter、PromQL、监控告警，希望能给大家云原生的监控之路上带来一些启发~
