技术实践｜开门见山谈Prometheus
本文作者围绕开源监控报警系统Prometheus，简明扼要地介绍了其背景、原理、架构及核心组件、工作流程和告警功能等，希望可以与各位技术同仁共享共进。
一、简介
Prometheus是一个开源的监控报警系统，它最初由SoundCloud开发。
2016年，Prometheus被纳入了由谷歌发起的Linux基金会旗下的云原生基金会（Cloud Native Computing Foundation），并成为仅次于Kubernetes的第二大开源项目。自此，它成为了一个独立的开源项目，独立于任何公司进行维护。
Prometheus拥有非常活跃的开发人员和用户社区，目前在GitHub上已拥有四万多的Star。
二、原理
Prometheus的基本原理是通过HTTP协议周期性抓取（Pull）被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控，不需要任何SDK或者其他的集成过程。
Pull方式的优势是能够自动进行上游监控和水平监控，配置更少、更容易扩展、更灵活、更容易实现高可用。Push模式中很容易出现因为向监控系统推送数据失败而导致被监控系统瘫痪的问题，而Pull方式，被采集端无需感知监控系统的存在，整个数据的采集完全由监控系统控制。
三、架构及核心组件
■ Prometheus Server
Prometheus Server是Prometheus的核心组件，负责实现对监控数据的获取（Retrieval），存储（Storage）及查询（PromQL）。Prometheus Server可以通过静态配置和服务发现的方式监控目标，获取数据。Prometheus Server本身包含一个时序数据库，获取的数据存储按照时间序列的方式存储在本地磁盘中，但是本地存储的容量毕竟有限，因此Prometheus也支持远程存储，适用于存储大量监控数据。另外Prometheus Server对外提供自定义的PromQL语言，实现对数据的查询和分析。
Prometheus Server内置了Express Browser UI，这个UI可以直接通过PromQL实现数据的查询以及可视化。
另外，Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据。因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。
■ Exporters
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。Exporter分为直接采集（cAdvisor、Kubernetes、etcd）和间接采集（MySQL Exporter、Service Exporter）两类。
■ AlertManager
Prometheus支持通过PromQL来创建告警规则，如果满足规则则创建一条告警，后续的告警流程就交给AlertManager，其提供了多种告警方式包括Email，Webhook等方式。
■ PushGateway
PushGateway类似于一个中转站，Prometheus的Server端只会使用Pull方式拉取数据，但是某些节点因为某些原因只能使用Push方式推送数据，PushGateway就是用来接收Push而来的数据并暴露给Prometheus的Server拉取的中转站。在以下情况可以考虑使用PushGateway：
● Prometheus的Pull模式对网络环境有一定要求，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转；
● 在监控业务数据的时候，需要将不同数据汇总，由Prometheus统一收集。
当然PushGateway也存在以下弊端：
● 当采用PushGateway获取监控数据时，PushGateway即会成为单点以及潜在的性能瓶颈；
● 丧失了Prometheus的实例健康检查功能；
● 除非手动删除Pushgateway的数据，否则Pushgateway会在一段时间内一直保留所有采集到的数据并且提供给Prometheus。（原理：为了解决Pushgateway重启后没有数据的问题，给它添加了一个临时存储，存储数据指标，且默认5分钟后被删除。）
四、工作流程
Prometheus的工作流程大致如下：
● Pormetheus Server定期从配置好的jobs或者exporters中拉metrics，或者从Pushgateway中拉取被Push的metrics，或者从其他的Prometheus Server中拉metrics；
● Prometheus Server在本地存储收集到的metrics，并运行已定义好的alert.rules，记录新的时间序列或者向AlertManager推送警报；
● AlertManager根据配置文件，对接收到的警报进行处理，发出告警；
● 在图形界面中，将采集的数据进行可视化展示。
五、告警功能
告警能力在Prometheus的架构中被划分成两个独立的部分。如下图所示，通过在Prometheus中定义AlertRule（告警规则），Prometheus会周期性的对告警规则进行计算，如果满足告警触发条件就会向AlertManager发送告警信息。
UI中“Alerts”页面展示Prometheus中配置的所有规则。
一条告警规则主要由以下几部分组成：
● alert：告警规则的名称。
● expr：基于PromQL表达式告警触发条件，用于计算是否有时间序列满足该条件。
● for：评估等待时间，可选参数。用于表示只有当触发条件持续一段时间后才发送告警。
● labels：自定义标签，允许用户指定要附加到告警上的一组附加标签。
● annotations：用于指定一组附加信息，比如用于描述告警详细信息的文字等，annotations的内容在告警产生时会一同作为参数发送到AlertManager。
告警的状态如下，对应界面中红色为firing状态的告警，黄色为pending状态告警，绿色为inactive告警：
● firing：满足expr表达式，且持续时间>评估等待时间。
● pending：满足expr表达式，且持续时间<评估等待时间。
● inactive：不满足expr表达式。