01
背景
在《SRE: Google运维解密》一书中作者指出,监控系统需要能够有效的支持白盒监控和黑盒监控。黑盒监控只在某个问题目前正在发生,并且造成了某个现象时才会发出紧急警报。“白盒监控则大量依赖对系统内部信息的检测,如系统日志、抓取提供指标信息的 HTTP 节点等。白盒监控系统因此可以检测到即将发生的问题及那些重试所掩盖的问题等”。为了完善系统的白盒监控,会员团队基于 Prometheus + Grafana 开源组件构建了监控告警平台。最近一段时间在查询监控指标时遇到了性能瓶颈,表现为一些监控页面的图表加载特别慢,查询近7天的监控数据就会失败,极大的降低了开发人员的工作效率。
02
排查
初步排查
选取其中一个加载失败的监控页面,查询近7天的监控数据,通过浏览器的开发者工具观察到的指标数据查询接口响应耗时如下图所示:
分析指标数据查询接口和监控图表的对应关系后发现,监控图表加载失败是查询接口超时所导致的。使用超时的指标查询语句直接查询 Prometheus,即便将采样步长调高到40分钟,查询响应耗时依然有48秒之多。说明查询的主要耗时都用在 Prometheus 的查询处理上。
Prometheus查询处理流程分析
想要继续弄清楚 Prometheus 的查询处理为什么需要耗时这么久,我们需要简单了解一下 Prometheus 的查询处理流程。Prometheus 使用了一个基于标签(label)、值和时间戳的简单数据模型,这些标签和样本一起构成了数据序列(series),每个样本都是由时间戳和值组成。
Prometheus 将这些数据存储在其内部的时间序列数据库中(Prometheus 也支持外部存储系统)。Prometheus 的数据库被划分为基本的存储单元,称为 block,其中包含一定时间范围(默认2小时)的数据。block 的结构如下图所示: