前言

Prometheus 作为第二个从 CNCF 毕业的顶级项目,其成熟程度是毋庸置疑的,甚至推出了另一个 CNCF 项目 OpenMetrics,希望将 Prometheus 的指标格式演进成为一个行业规范。

更新总览

在 Prometheus-v2.25.0 版本中更新一览:

1. [实验性功能]支持 remote_write 请求,默认不启用,启用需要启动参数指定--enable-feature = remote-write-receiver

2. [实验性功能]新增'@'修饰符,默认不启用,启用需要启动参数指定--enable-feature = promql-at-modifier

3. [增强]完善测试案例 testgroup 添加 name 属性

4. [增强]UI 界面上添加警告相关信息

5. [增强]加大压缩 Histogram 类型 metrics 的存储存储桶数,由 512 增大到 8192

6. [增强]允许设置自定义的 header 在远程写请求中

7. [增强]将 dashboard 和 config 的 libsonnet 中的 grafana 替换成了 grafanaPrometheus

8. [增强]kubernetes 服务发现中添加 ndponits labels 的 metadata

9. [增强]UI 界面添加显示 TSDB 标签对的总数数据

10. [增强]TSDB 每分钟加载块数据,如果检测到有更新就执行保留数据操作.(这个 PR 标记成了 #8243 应该是写错了,看了下这个 PR 和块数据没关系)

11. [BugFix]修复启动时 web.listen-address 参数没有传递端口报错问题

12. [BugFix]完善一个错误处理,打开 Mmap 文件时继续走逻辑而不是立刻返回错误

13. [BugFix]弃用未使用的参数--alertmanager.timeout

14. [BugFix]Mixins:支持在警报中的 v2.23 中重命名的远程写入指标

15. [BugFix]远程写请求写入错误日志修改为警告

16. [BugFix]启动时删除 2.21 之前版本的临时块数据

    
    

    17-20 …

总共是2个实验性功能8个增强10个BugFix

https://github.com/prometheus/prometheus/pull/8424本文会主要讲解两个实验性功能和两个增强和一个 BUGFIX

官方地址是:https://github.com/prometheus/prometheus/releases/tag/v2.25.0

实验性功能

默认关闭的功能列表在这里可以找到:https://github.com/prometheus/prometheus/blob/main/docs/disabled_features.md

在prometheus命令help中也可以找到:

      --enable-feature= ...      Comma separated feature names to enable. Valid options: 'promql-at-modifier' to enable the @                                 modifier, 'remote-write-receiver' to enable remote write receiver. See                                 https://prometheus.io/docs/prometheus/latest/disabled_features/ for more details.

prometheus 可以作为另一个 prometheus 的远程存储

也就是说可以支持 Prometheus 将拉取到的数据写入到另一个 Prometheus.

想象一下这样一个场景:监控中心的 Prometheus 部署在服务器 A,而业务程序部署在服务器 B 并且由于网络安全等问题服务器 B 不能开放 Exporter 端口或路径到外部访问,这时候一般会加一个 PushGateway,由业务程序主动将 Metrics 推送到 PushGateway,Prometheus 再从 PushGateway 拉取 Metrics.

但这种方式并不是很好,PushGateway 没有收到业务程序最新的 Metrics 了,但 Prometheus 依然能够从 PushGateway 拉取到数据,并且这还存在 PushGateway 单点问题.

现在 Prometheus 支持作为远程存储后可以怎么玩呢?在业务程序网络覆盖的范围内部署一个 Prometheus,再由这个 Prometheus 将数据远程存储到监控中心的 Prometheus.

这就是一个典型的 SideCar 模式.

这让我想到一个套娃的 Prometheus,比如现在有两个 Prometheus,他们都设置对方为远程存储,那么是不是就无限循环了呢?感兴趣的可以试试!

PR 地址:https://github.com/prometheus/prometheus/pull/8424

新增'@'修饰符

简单来说就是多了一个'@'的语法,在 v2.25.0 之前topk()只支持及时查询,也就是无法查询某段时间内的topk,当你使用topk查询图表时,会查询出不符合预期的结果,比如topk(2, rate(jvm_memory_used_bytes[10m]))希望查询出10分钟内jvm_memory_used_bytes指标的平均速率增长趋势最大的2个指标,但是查询的结果会多余预期的2个.

说明: Graph(图表)即某段时间范围内的结果,Table 即实时查询.可以看看下面两个图再进一步理解.

table

table

graph

graph

一起来看看下面的PromQL:

rate(jvm_memory_used_bytes[1m])and topk(2, rate(jvm_memory_used_bytes[30m] @ end())) 

rate(jvm_memory_used_bytes[1m])是希望查询的实际数据,topk(2, rate(jvm_memory_used_bytes[30m] @ end())) 意思是筛选出最近时间段内(如果是 Table 则是实时)30 分钟平均速率趋势最大的 2 个指标,然后展示他们在时间段内 1 分钟的平均速率数据.

相关 PR 有三个,分别是:#8121 #8436 #8425

增强

远程存储支持自定义 HTTP Header

只需要在remote_write的url配置下添加一个headers的参数即可,填充map类型内容,如果版本在v2.25以下时填写了 header 内容会报错

remote_write:  - url: http://192.168.3.75:9494/api/v1/write    headers:      key: value

当然了,一些 HTTP 自身的 Header 是不允许覆盖内容的,贴一下源码:

    unchangeableHeaders = map[string]struct{}{        // NOTE: authorization is checked specially,        // see RemoteWriteConfig.UnmarshalYAML.        // "authorization":                  {},        "host":                              {},        "content-encoding":                  {},        "content-type":                      {},        "x-prometheus-remote-write-version": {},        "user-agent":                        {},        "connection":                        {},        "keep-alive":                        {},        "proxy-authenticate":                {},        "proxy-authorization":               {},        "www-authenticate":                  {},    }

毕竟这是 HTTP 自带的 header,如果覆盖了会引起一些未知的错误.

PR 地址:https://github.com/prometheus/prometheus/pull/8273

在 UI 界面上添加 TSDB 标签对的总数

这算一个 TSDB 数据基本信息完善,把标签对总数数据显示了出来

add-label-pair

add-label-pair

BugFix

在启动时删除 2.21 以前版本的临时数据

这个 Issue 在https://github.com/prometheus/prometheus/issues/8180

是一位用户在 2.15.2 时遇到的一个问题,后来升级到了 2.22.1 版本.

在 Prometheus 压缩或保留失败时产生了一些*.tmp文件,例如01EQ0DZ14E04F7P51Q3NA1562G.tmp,而且 prometheus 永远也没有清理这些文件,导致这些临时文件越来越多.如果你已经在生产环境看到了一些 tmp 文件并且越来越多的话,是时候升级 prometheus 了,否则这些临时文件会越来越多,直到磁盘空间满载.

PR 地址:https://github.com/prometheus/prometheus/pull/8353

总结

prometheus 社区非常活跃,v2.25.0 到 v2.26.0 只用了一个半月,并且更新点也不少.偶尔关注一下新版本的一些更新点还是很有用的,可以了解社区发展方向的同时也可以看看社区的活跃程度.当然,官方推出的更新内容说明都是英文的,也可以等待本系列文章,发布中文版本说明.

系列文章

将会持续发布 prometheus 版本发布中文说明,欢迎关注系列文章目录https://liangyuanpeng.com/post/prometheus-replease-log/