Prometheus组件详解

Prometheus简介

Prometheus的主要特征有：

1. 多维度数据模型
2. 灵活的查询语言
3. 不依赖分布式存储，单个服务器节点是自主的
4. 以HTTP方式，通过pull模型拉去时间序列数据
5. 也通过中间网关支持push模型
6. 通过服务发现或者静态配置，来发现目标服务对象
7. 支持多种多样的图表和界面展示，grafana也支持它

核心组件

Prometheus生态包括了很多组件，它们中的一些是可选的：

1. 主服务Prometheus Server负责抓取(pull)和存储时间序列数据
2. 客户库负责检测应用程序代码
3. 支持短生命周期的PUSH网关
4. 基于Rails/SQL仪表盘构建器的GUI
5. 多种导出工具，可以支持Prometheus存储数据转化为HAProxy、StatsD、Graphite等工具所需要的数据存储格式
6. 警告管理器
7. 命令行查询工具
8. 其他各种支撑工具

Prometheus基础架构

多数Prometheus组件是Go语言写的，这使得这些组件很容易编译和部署。

Prometheus服务，可以直接通过目标拉取数据，或者间接地通过中间网关拉取数据。它在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中，PromQL和其他API可视化地展示收集的数据。

1. Prometheus Server

Prometheus Server是Prometheus组件中的核心部分，负责实现对监控数据的获取，存储以及查询。 Prometheus Server可以通过静态配置管理监控目标，也可以配合使用Service Discovery的方式动态管理监控目标，并从这些监控目标中获取数据。其次Prometheus Server需要对采集到的监控数据进行存储，Prometheus Server本身就是一个时序数据库，将采集到的监控数据按照时间序列的方式存储在本地磁盘当中。最后Prometheus Server对外提供了自定义的PromQL语言，实现对数据的查询以及分析。
Prometheus Server内置的Express Browser UI，通过这个UI可以直接通过PromQL实现数据的查询以及可视化。
Prometheus Server的联邦集群能力可以使其从其他的Prometheus Server实例中获取数据，因此在大规模监控的情况下，可以通过联邦集群以及功能分区的方式对Prometheus Server进行扩展。

2. Exporters

Prometheus 基本原理是通过 HTTP 协议周期性抓取被监控组件的状态，而输出这些被监控的组件的 Http 接口为 Exporter。Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。

一般来说可以将Exporter分为两类：

直接采集：这一类Exporter直接内置了对Prometheus监控的支持，比如cAdvisor，Kubernetes，Etcd，Gokit等，都直接内置了用于向Prometheus暴露监控数据的端点。
间接采集：间接采集，原有监控目标并不直接支持Prometheus，因此我们需要通过Prometheus提供的Client Library编写该监控目标的监控采集程序。例如： Mysql Exporter，JMX Exporter，Consul Exporter等。

3. AlertManager

在Prometheus Server中支持基于PromQL创建告警规则，如果满足PromQL定义的规则，则会产生一条告警，而告警的后续处理流程则由AlertManager进行管理。在AlertManager中我们可以与邮件，Slack等等内置的通知方式进行集成，也可以通过Webhook自定义告警处理方式。AlertManager即Prometheus体系中的告警处理中心。

4. PushGateway

由于Prometheus数据采集基于Pull模型进行设计，因此在网络环境的配置上必须要让Prometheus Server能够直接与Exporter进行通信。 当这种网络需求无法直接满足时，就可以利用PushGateway来进行中转。可以通过PushGateway将内部网络的监控数据主动Push到Gateway当中。而Prometheus Server则可以采用同样Pull的方式从PushGateway中获取到监控数据。

Prometheus支持通过三种类型的途径从目标上"抓取"指标数据：

Exporters
Instrumentation(应用程序内置了prometheus支持格式的测量系统)
Pushgateway，适用于短生命周期的任务或者批处理任务

TSDB，时序数据库

Pull和Push的差别

Prometheus同其它TSDB相比有一个非常典型的特性：它主动从各Target上 拉取(pull) 数据，而非等待被监控端的 推送(push)。

两个方式各有优劣，其中，Pull模型的优势在于：

集中控制：有利于将配置集在 Prometheus Server上完成，包括指标及采取速率等；
Prometheus的根本目标在于收集在Target上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统。

Prometheus的生态组件

Prometheus负责时序型指标数据的采集及存储，但数据的分析、聚合及直观展示以及告警等功能并非由Prometheus Server所负责；

Prometheus 生态圈中包含了多个组件，其中部分组件可选

Prometheus Server: 收集和存储时间序列数据
Client Library: 客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径
Push Gateway: 接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作
Exporters: 用于暴露现有应用程序或服务（不支持Instrumentation）的指标给Prometheus Server
Alertmanager: 从Prometheus Server接收到“告警通知”后，通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送
Data Visualization：Prometheus Web UI （Prometheus Server内建），及Grafana等
Service Discovery：动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用；该组件目前由Prometheus Server内建支持；

Prometheus数据模型

Prometheus仅用于以“键值”形式存储时序式的聚合数据，它并不支持存储文本信息：

其中的"键"称为指标（Metric)，它通常意味着CPU速率、内存使用率或分区空闲比例等
同一指标可能会适配到多个目标或设备，因而它使用"标签"作为元数据，从而为Metric添加更多的信息描述纬度
这些标签还可以作为过滤器进行指标过滤及聚合运算

指标类型（Metric Types）

Prometheus使用4种方法来描述监视的指标

Counter：计数器，用于保存单调递增型的数据，例如站点访问次数等；不能为负值，也不支持减少，但可以重置回0
Gauge：仪表盘，用于存储有着起伏特征的指标数据，例如内存空闲大小等
Gauge是Counter的超集；但存在指标数据丢失的可能性时，
Counter能让用户确切了解指标随时间的变化状态，而Gauge则可能随时间流逝而精准度越来越低
Histogram：直方图，它会在一段时间范围内对数据进行采样，并将其计入可配置的bucket之中；Histogram能够存储更多的信息，包括样本值分布在每个bucket（bucket自身的可配置）中的数量、所有样本值之和以及总的样本数量，从而Prometheus能够使用内置的函数进行如下操作
3.1）计算样本平均值：以值的总和除以值的数量；
3.2）计算样本分位值：分位数有助于了解符合特定标准的数据个数；例如评估响应时长超过1秒钟的请求比例，若超过20%即发送告警等
Summary：摘要，Histogram的扩展类型，但它是直接由被监测端自行聚合计算出分位数；
并将计算结果响应给Prometheus Server的样本采集请求；因而，其分位数计算是由监控端完成

作业（Job）和实例（Instance）

Instance：能够接收Prometheus Server数据Scrape操作的每个网络端点（endpoint），即为一个Instance（实例）
Job：通常，具有类似功能的Instance的集合称为一个Job，例如一个MySQL主从复制集群中的所有MySQL进程

PromQL

Prometheus提供了内置的数据查询语言PromQL（全称为Prometheus Query Language），支持用户进行实时的数据查询及聚合操作；

PromQL支持处理两种向量，并内置提供了一组用于数据处理的函数

即时向量：最近一次的时间戳上跟踪的数据指标
时间范围向量：指定时间范围内的所有时间戳上的数据指标

Instrumentation（程序仪表）

任何能够支持Scrape指标数据的应用程序都首先要具有一个测量系统

在Prometheus的语境中，Instrumentation是指附加到应用程序中的那些用于暴露程序指标数据的客户端库
程序员借助于这些客户端库编写代码生成可暴露的指标数据

Exporters

对于那些未内建Instrumentation，且也不便于自行添加该类组件以暴露指标数据的应用程序来说，常用的办法是于待监控的目标应用程序外部运行一个独立指标暴露程序，该类型的程序即统称为Exporter

换句话说，Exporter负责从目标应用程序上采集和聚合原始格式的数据，并转换或聚合为Prometheus格式的指标向外暴露，Prometheus站点上提供了大量的Exporter

Alerts

抓取到异常值后，Prometheus支持通过"告警（Alert）"机制向用户发送反馈或警示，以触发用户能够及时采取应对措施

Prometheus Server仅负责生成告警指示，具体的告警行为由另一个独立的应用程序AlertManager负责
告警指示由Prometheus Server基于用户提供的"告警规则"周期性计算生成
Alertmanager接收到Prometheus Server 发来的告警指示后，基于用户定义的告警路由（route）向告警接收人（receivers）发送告警信息

Prometheus工作模式

Prometheus Server基于服务发现（Service Discovery）机制或静态配置获取要监视的目标（ Target），并通过每个目标上的指标exporter来采集（Scrape）指标数据
Prometheus Server内置了一个基于文件的时间序列存储来持久存储指标数据，用户可使用PromDash或PromQL接口来检索数据，也能够按需将告警需求发往Alertmanager完成告警内容发送
一些短期运行的作业的生命周期过短，难以有效地将必要的指标数据供给到Server端，它们一般会采用推送（Push）方式输出指标数据，Prometheus借助于Pushgateway接收这些推送的数据，进而由Server端进行抓取

Prometheus的局限性

Prometheus是一款指标监控系统，不适合存储事件及日志等；它更多地展示的是趋势性的监控，而非精准数据
Prometheus认为只有最近的监控数据才有查询的需要，其本地存储的设计初衷只是保存短期（例如一个月）数据，因而不支持针对大量的历史数据进行存储（若需要存储长期的历史数据，建议基于远端存储机制将数据保存于 InfluxDB 或 OpenTSDB 等系统中）
Prometheus的集群机制成熟度不高，即便基于Thanos亦是如此