Prometheus作为第二个从CNCF毕业的顶级项目,其成熟程度是毋庸置疑的,甚至推出了另一个CNCF项目OpenMetrics,希望将Prometheus的指标格式演进成为一个行业规范。
在Prometheus-v2.25.0版本中更新一览:
总共是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部署在服务器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即实时查询.可以看看下面两个图再进一步理解.
一起来看看下面的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分钟的平均速率数据.
只需要在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
这算一个TSDB数据基本信息完善,把标签对总数数据显示了出来
这个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版本发布中文说明,欢迎关注系列文章目录
始发于 四颗咖啡豆 发布!
关注公众号->四颗咖啡豆 获取最新内容
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。