Prometheus监控指标查询性能调优

本文分析了Prometheus监控查询性能瓶颈,发现指标基数过高是主要原因。通过详细排查,了解到查询时间范围、标签基数和计算操作影响查询耗时。采用记录规则优化查询语句,显著降低指标基数,提升图表加载速度。建议在指标设计阶段就考虑基数控制,以优化监控性能。
摘要由CSDN通过智能技术生成

01

   背景

在《SRE: Google运维解密》一书中作者指出,监控系统需要能够有效的支持白盒监控和黑盒监控。黑盒监控只在某个问题目前正在发生,并且造成了某个现象时才会发出紧急警报。“白盒监控则大量依赖对系统内部信息的检测,如系统日志、抓取提供指标信息的 HTTP 节点等。白盒监控系统因此可以检测到即将发生的问题及那些重试所掩盖的问题等”。为了完善系统的白盒监控,会员团队基于 Prometheus + Grafana 开源组件构建了监控告警平台。最近一段时间在查询监控指标时遇到了性能瓶颈,表现为一些监控页面的图表加载特别慢,查询近7天的监控数据就会失败,极大的降低了开发人员的工作效率。

02

  排查

初步排查

选取其中一个加载失败的监控页面,查询近7天的监控数据,通过浏览器的开发者工具观察到的指标数据查询接口响应耗时如下图所示:

fc0f4245c1efae3bdf1ee5076b5a449b.png

分析指标数据查询接口和监控图表的对应关系后发现,监控图表加载失败是查询接口超时所导致的。使用超时的指标查询语句直接查询 Prometheus,即便将采样步长调高到40分钟,查询响应耗时依然有48秒之多。说明查询的主要耗时都用在 Prometheus 的查询处理上。

Prometheus查询处理流程分析

想要继续弄清楚 Prometheus 的查询处理为什么需要耗时这么久,我们需要简单了解一下 Prometheus 的查询处理流程。Prometheus 使用了一个基于标签(label)、值和时间戳的简单数据模型,这些标签和样本一起构成了数据序列(series),每个样本都是由时间戳和值组成。

f6d82cc72ad7ba03587090510bbc82e2.pngPrometheus 将这些数据存储在其内部的时间序列数据库中(Prometheus 也支持外部存储系统)。Prometheus 的数据库被划分为基本的存储单元,称为 block,其中包含一定时间范围(默认2小时)的数据。block 的结构如下图所示:

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值