概述

prometheus是由SoundCloud开发的开源监控告警系统并且自带时序数据库，基于Go语言。Prometheus根据配置的任务（job）以周期性pull的方式获取指定目标（target）上的指标（metric）。

组件

Prometheus 生态圈中包含了多个组件:

Prometheus Server: 根据配置完成数据采集， 服务发现以及数据存储。

Push Gateway : 为应对部分push场景提供的插件，监控数据先推送到 Push Gateway 上，然后再由 Prometheus Server 端采集 pull 。用于存在时间较短，可能在 Prometheus 来 pull 之前就消失了的 jobs （若 Prometheus Server 采集间隔期间，Push Gateway 上的数据没有变化， Prometheus Server 将采集到2次相同的数据，仅时间戳不同）

Exporters（探针）: 是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据，并将其转化为Prometheus支持的格式。与传统的数据采集组件不同的是，它并不向中央服务器发送数据，而是等待中央服务器主动前来抓取。

Alertmanager: Prometheus server 主要负责根据基于PromQL的告警规则分析数据，如果满足PromQL定义的规则，则会产生一条告警，并发送告警信息到Alertmanager，Alertmanager则是根据配置处理告警信息并发送。常见的接收方式有：电子邮件，webhook 等。Alertmanager三种处理告警信息的方式：分组，抑制，静默。

优点

1、提供多维度数据模型和灵活的查询方式，通过将监控指标关联多个Tag，来将监控数据进行任意维度的组合；提供HTTP查询接口；可以很方便的结合Grafana等组件展示数据。

2、在不依赖外部存储的情况下，支持服务器节点的本地存储，通过prometheus自带的时序数据库，可以完成每秒千万级的数据存储。不仅如此，在保存大量历史数据的场景中，prometheus还可以对接第三方时序数据库如OpenTSDB等。

3、定义了开放指标数据标准，以基于HTTP的Pull方式采集时序数据，只有实现了prometheus监控数据格式的监控数据才可以被prometheus采集；并支持以Push方式向中间网关推送时序数据，能更灵活地应对各种监控场景。

4、支持通过静态文件配置和动态发现机制发现监控对象，自动完成数据采集。prometheus目前已经支持Kubernetes、Consul等多种服务发现机制，可以减少运维人员的手动配置环节。

指标定义

prometheus的所有监控指标被统一定义为：

<metric name>{<label name>=<label value>,...}

时间序列数据通过 metric 名和键值对来区分。 标签可以体现指标的维度特征，用于过滤和聚合。它通过标签名和标签值这种键值对的形成多种维度。

指标的某些标签是以_开头的，这些标签是在prometheus系统内部使用的。

prometheus指标分类

1、Counter
计数器类型，只增不减，如机器的启动时间，HTTP访问量等。机器重启不会置零，在使用这种指标类型时，通常会结合rate()方法获取该指标在某个时间段的变化率。

2、Gauge
仪表盘，可增可减，如CPU使用率，大部分监控数据都是这种类型的。

3、Summary 客户端定义
Summary，Histogram都属于高级指标，用于凸显数据的分布情况。

{quantile=“0.9”}也不是随便就能用的，需要指标里本来就有quantile这个标签。

Prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"}  0.014
表示有90%的同步时间是低于0.014s的

Summary计算的指标不能再获取平均数，一般适用于独立的监控指标，例如垃圾回收时间等。

4、Histogram 服务端定义，相比Summary性能更好
反应了某个区间内的样本数

prometheus_local_storage_series_chunks_persisted{le="1.6382e+06"}
260

小于1.6382e+06个chunk的序列有260个(这个指标表示prometheus每个本地存储序列保存的chunk数量)

数据采集

prometheus采用pull方式采集监控数据，时间戳为ms。采用统一的restful api方式获取数据。根据配置周期性的采集指定目标上的指标。

Push和Pull方式的对比：

1、实时性

Push方式实时性更好

2、状态保存

Push方式通常在采集完成后立即上报，本地不会保存采集数据。Pull方式正好相反，Agent本身需要有一定的数据存储能力。

3、控制能力

采用Push方式，控制方为Agent。采用Pull方式，Master更主动，可以实现集中配置

4、配置的复杂性

采用Push方式，通常每个Agent都需要配置Master的地址。采用Pull方式，通常通过批量配置或自动发现来获取所有采集点，可以做到与Agent解耦，Agent不用感知Master存在。

数据处理

prometheus支持数据处理，主要包括relabel、replace、keep、drop等操作，提供过滤数据或修改样本维度信息等功能。

通过replace或者labelmap的方式针对这些内部使用的标签进行重命名或者将多个标签的内容进行组合。

如果设置了keep机制，则会保留所有匹配标签的数据，如果设置了drop机制，则会丢弃匹配标签的数据，从而完成数据过滤。

数据查询

和关系型数据库实现sql解析一样，prometheus实现了一套自己的数据库语言（promsql）解析器。promsql和sql的最大差别就是promsql只支持查询。

prometheus支持grafana等开源显示面板，通过自定义promsql可以制作丰富的监控视图。prometheus本身也提供了一个简单的web查询控制台。web控制台主要包括：graph指标查询，alerts高经查询和status状态查询。

数据规范

prometheus在面对繁杂的监控对象时并没有采用逐一适配的方式，而是制定了一套独特的监控数据规范，符合这套规范的监控数据都可以被prometheus统一采集，分析和展现。

prometheus会周期性地调用这些exporter数据接口来获取数据。接口数据以文本形式组织，这和大多数基于json的数据组织形式不同，采用文本形式更加灵活。

但是，调用prometheus rest接口时，返回的指标value是由一个64位的浮点值和一个精确到毫秒级的时间戳组成。

our_company_blob_storage_ops_queued 496

在很多流行的监控系统中都已经实现了prometheus接口，例如etcd，kubernetes，他们可以直接被prometheus监控，但大多数监控对象都没法直接提供监控接口（安全性考虑或者不支持http接口，如硬件性能指标）。

exporter主要通过被监控对象提供的监控相关的接口来获取监控数据。即exporter将不同规范和格式的监控指标进行转化，输出prometheus能够识别的监控数据格式，极大扩展了prometheus的数据采集能力。