Prometheus 简介

致谢

感谢广州迈创智能科技有限公司，以及所有的前同事们。

这是我在迈创实习期间的运维技术沉淀之一，感谢他们。

正文

Prometheus 是一个开源的系统监视和报警工具箱，Prometheus 受启发于 Google 的 Brogmon 监控系统（相似的 Kubernetes 是从 Google 的 Brog 系统演变而来。

Prometheus server 是服务的核心组件，用于收集和存储时间序列数据。

  • TSDB Time series database 时间序列数据库，将数据保存在硬盘上，使用 SSD 性能更优

  • Retrieval 采样模块，负责定时去暴露的目标页面上去抓取采样指标数据

  • HTTP server 提供http接口查询和面板，默认端口为9090

Jobs/exporters 负责收集目标对象性能数据，并通过 HTTP server 接口供 Prometheus Server 获取。

Short-lived jobs 瞬时任务场景，无法通过 pull 方式拉取，需要使用 push 方式，与 Pushgateway 搭配使用。

Pushgateway 是一个可选择的组件，主要用于短期 Jobs 。由于这类 jobs 存在时间较短，可能在 Prometheus 来 pull 之前就消失了。为此，这次 jobs 可以直接向 Prometheus server 端推送它们的 metrics。这种方式主要用于服务层面的 metrics，对于机器层面的 metrices，需要使用 node exporter。

Altermanager 从 Prometheus sever 接收到 alerts 之后，会进行去重、分组，并路由到对应的接收方式。

Services discovery 服务发现机制，通过第三方接口，Prometheus 查询到需要监控的 Target 列表，然后轮询这些 Target 获取监控数据。

Prometheus web UI 通过 PromQL 收集数据将 Prometheus Server 收集到的数据展示出来。

工作流程

  1. Prometheus server 定期从配置好的 jobs 或者 exporters 中拉 metrics，或者接收来自 Pushgateway 发过来的 metrics，或者从其他的 Prometheus server 中拉 metrics。

  2. Prometheus server 在本地储存收集到的 metrics ，并运行已经定义好的 alert.rules，记录新的时间序列或者向 Alertmanager 推送警报。

  3. Alertmanager 根据配置文件，对接收到的警报进行处理，发出告警。

  4. 在图形界面中可视化采集数据。

本地储存

本地储存模式

采用自定义格式储存在磁盘中，按照时间窗口，将时间窗口内产生的数据存储在一个块(Block)中，每一个块中包含该时间窗口内的所有样本数据(chunks)，元数据文件(meta.json)以及索引文件(index)。

当前时间窗口内正在收集的样本数据，Prometheus 则会直接将数据保存在内存当中。为了确保此期间如果 Prometheus 发生崩溃或者重启时能够恢复数据，Prometheus 启动时会从预写日志进行重播，从而恢复数据。此期间如果通过API删除时间序列，删除记录也会保存在单独的逻辑文件当中(tombstone)。

本地存储配置

用户可以通过命令行启动参数的方式修改本地存储的配置。

启动参数

默认值

含义

--storage.tsdb.path

data/

指标储存路径

--storage.tsdb.retention

15d

样本保留时间

--storage.tsdb.min-block-duration

2h

块文件打包的时间窗口

--storage.tsdb.max-block-duration

36h

The maximum timestamp range of compacted blocks,It's the minimum duration of any persisted block.

--storage.tsdb.no-lockfile

false

不要在数据文件夹中创建 lockfile

在一般情况下，Prometheus中存储的每一个样本大概占用1-2字节大小。如果需要对Prometheus Server的本地磁盘空间做容量规划时，可以通过以下公式计算：

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

从上面公式中可以看出在保留时间(retention_time_seconds)和样本大小(bytes_per_sample)不变的情况下，如果想减少本地磁盘的容量需求，只能通过减少每秒获取样本数(ingested_samples_per_second)的方式。因此有两种手段，一是减少时间序列的数量，二是增加采集样本的时间间隔。考虑到Prometheus会对时间序列进行压缩效率，减少时间序列的数量效果更明显。

远程存储

为了保持 Prometheus 的简单性，Prometheus 并没有尝试在自身中解决以上问题，而是通过定义两个标准接口(remote_write/remote_read)，让用户可以基于这两个接口对接将数据保存到任意第三方的存储服务中，这种方式在 Promthues 中称为 Remote Storage 。

联邦集群

如上图所示，在每个数据中心部署单独的 Prometheus Server，用于采集当前数据中心监控数据。并由一个中心的 Prometheus Server 负责聚合多个数据中心的监控数据。这一特性在 Promthues 中称为联邦集群。

HA 方案

Prometheus HA

+主备HA 解决可用性问题

用户只需要部署多套 Prometheus Server 实例，并且采集相同的 Exporter 目标即可。

+远程储存 解决数据持久化问题

Remote Storage，通过定义两个标准接口(remote_write/remote_read)，让用户可以基于这两个接口对接将数据保存到任意第三方的存储服务中。

+联邦集群 解决水平扩展问题

这种模式也适合与多数据中心的情况，当 Promthues Server 无法直接与数据中心中的 Exporter 进行通讯时，在每一个数据中部署一个单独的 Promthues Server 负责当前数据中心的采集任务是一个不错的方式。这样可以避免用户进行大量的网络配置，只需要确保主 Promthues Server 实例能够与当前数据中心的 Prometheus Server 通讯即可。 中心 Promthues Server 负责实现对多数据中心数据的聚合。

Alertmanager HA

+主备HA

使用 Gossip 机制解决通信问题，防止同一告警多次触发。

  1. 在第一个阶段 Silence 中，Alertmanager 会判断当前通知是否匹配到任何的静默规则，如果没有则进入下一个阶段，否则则中断流水线不发送通知。

  2. 在第二个阶段 Wait 中，Alertmanager 会根据当前 Alertmanager 在集群中所在的顺序(index)等待index * 5s的时间。

  3. 当前 Alertmanager 等待阶段结束后，Dedup 阶段则会判断当前 Alertmanager 数据库中该通知是否已经发送，如果已经发送则中断流水线，不发送告警，否则则进入下一阶段 Send 对外发送告警通知。

  4. 告警发送完成后该 Alertmanager 进入最后一个阶段 Gossip，Gossip 会通知其他 Alertmanager 实例当前告警已经发送。其他实例接收到 Gossip 消息后，则会在自己的数据库中保存该通知已发送的记录。

Silence设置同步：Alertmanager 启动阶段基于 Pull-based 从集群其它节点同步Silence 状态，当有新的 Silence 产生时使用 Push-based 方式在集群中传播Gossip 信息。

通知发送状态同步：告警通知发送完成后，基于 Push-based 同步告警发送状态。Wait 阶段可以确保集群状态一致。

Alertmanager 基于 Gossip 实现的集群机制虽然不能保证所有实例上的数据时刻保持一致，但是实现了 CAP 理论中的 AP 系统，即可用性和分区容错性。

使用方法

样本

<--------------- metric ---------------------><-timestamp -><-value->
http_request_total{status="200",method="GET"}@1434417560938 => 94355

http_request_total{status="404",method="GET"}@1434417561287 => 38544

http_request_total{status="200",method="POST"}@1434417560938 => 4748

指标

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

Counter：只增不减的计数器

Counter类型的指标其工作方式和计数器一样，只增不减（除非系统发生重置）。常见的监控指标，如http_requests_total，node_cpu都是Counter类型的监控指标。 一般在定义Counter类型指标的名称时推荐使用_total作为后缀。

rate(http_requests_total[5m])//通过rate()函数获取HTTP请求量的增长率

topk(10, http_requests_total)//查询当前系统中，访问量前10的HTTP地址

Gauge：可增可减的仪表盘

Gauge 类型的指标侧重于反应系统的当前状态。因此这类指标的样本数据可增可减。

delta(cpu_temp_celsius{host="zeus"}[2h])//计算CPU温度在两个小时内的差异

predict_linear(node_filesystem_free{job="node"}[1h], 4 * 3600)//预测系统磁盘空间在4个小时之后的剩余情况

使用 Histogram 和 Summary 分析数据分布情况

Histogram

# HELP prometheus_tsdb_compaction_chunk_range Final time range of chunks on their first compaction
# TYPE prometheus_tsdb_compaction_chunk_range histogram
prometheus_tsdb_compaction_chunk_range_bucket{le="100"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="6400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="25600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="102400"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="409600"} 0
prometheus_tsdb_compaction_chunk_range_bucket{le="1.6384e+06"} 260
prometheus_tsdb_compaction_chunk_range_bucket{le="6.5536e+06"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="2.62144e+07"} 780
prometheus_tsdb_compaction_chunk_range_bucket{le="+Inf"} 780
prometheus_tsdb_compaction_chunk_range_sum 1.1540798e+09
prometheus_tsdb_compaction_chunk_range_count 780

​ 度量指标名称: [basename]的柱状图, 上面三类的作用度量指标名称

​ 显示为[basename]_bucket{le="上边界"}

​ [basename]_sum，是指所有观察值的总和

​ [basename]_count，是指已观察到的事件计数值

Summary

# HELP prometheus_tsdb_wal_fsync_duration_seconds Duration of WAL fsync.
# TYPE prometheus_tsdb_wal_fsync_duration_seconds summary
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216

显示为[basename]{分位数="[φ]"}

[basename]_sum，是指所有观察值的总和

[basename]_count，是指已观察到的事件计数值

PromQL

  • 使用label=value和label!=value进行完全匹配。

  • 使用label=~regx以及label!~regx进行正则匹配。

http_requests_total{environment=~"staging|testing|development",method!="GET"}

  • 使用[time]区间向量表达式进行查询。

单位有s - 秒 / m - 分钟 / h - 小时 / d - 天 / w - 周 / y - 年。

昨天一天的区间内的样本数据：

http_request_total{}[1d] offset 1d

  • 使用数学表达式

+ - * / % ^

  • 使用布尔运算

== != > < >= <=

  • 使用集合运算

and or unless

  • 使用聚合操作

sum min max avg stddev标准差 stdvar标准方差 count计数 count_values对value计数 bottomk后n条时序 topk前n条时序 quantile分位数

语法规则<aggr-op>([parameter,] <vector expression>) [without|by (<label list>)]

使用内置函数

Counter

increase 函数获取区间向量中的第一个后最后一个样本并返回其增长量。

increase(node_cpu[2m]) / 120 //node_cpu样本在最近两分钟的平均增长率

rate 函数可以直接计算区间向量v在时间窗口内平均增长速率。

rate(node_cpu[2m]) //node_cpu样本在最近两分钟的平均增长率

irate 函数是通过区间向量中最后两个样本数据来计算区间向量的增长速率。这种方式可以避免在时间窗口范围内的“长尾问题”，并且体现出更好的灵敏度，通过irate函数绘制的图标能够更好的反应样本数据的瞬时变化状态。

irate(node_cpu[2m]) //node_cpu样本在最近两分钟的平均增长率

rate 和 irate 适用场景？

Gauge

predict_linear函数可以预测时间序列v在t秒后的值。它基于简单线性回归的方式，对时间窗口内的样本数据进行统计，从而可以对时间序列的变化趋势做出预测。

predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0 //基于2小时的样本数据，来预测主机可用磁盘空间的是否在4个小时候被占满

Alertmanager 配置

集成钉钉/方法

RED方法

RED方法是Weave Cloud在基于Google的“4个黄金指标”的原则下结合Prometheus以及Kubernetes容器实践，细化和总结的方法论，特别适合于云原生应用以及微服务架构应用的监控和度量。主要关注以下三种关键指标：

  • (请求)速率：服务每秒接收的请求数。

  • (请求)错误：每秒失败的请求数。

  • (请求)耗时：每个请求的耗时。

在“4大黄金信号”的原则下，RED方法可以有效的帮助用户衡量云原生以及微服务应用下的用户体验问题。

搭建实践

上一页Erlang 开发环境配置下一页Whys-the-design 笔记

最后更新于