使用Prometheus和Grafana测量时序列度量

我们使用Prometheus收集时序列度量，利用Grafana绘制成图表、显示仪表板并生成警告。首先我们部署了kube-prometheus来收集各种度量和可视化的仪表板。随着时间的推移，我们已经添加了许多我们自己的仪表板、指标和警报。

随着节点越来越多，我们逐渐难以理解Prometheus收集到的度量。尽管kube-prometheus公开了许多非常有用的数据，但有些数据我们并不需要，而有些数据过于细致，很难收集、存储和有效地查询。因此我们使用Prometheus 规则“放弃”了一些度量。

长期以来，有一个问题一直困扰我们：Prometheus消耗的内存越来越多，最终由于内存耗尽而崩溃。即使给Prometheus提供大量的内存也无济于事。更糟糕的是，每当出现崩溃，它就需要花费好几个小时重新执行预写式日志(write-ahead log)文件，之后才能正常使用。

最后我们研究了Prometheus的源代码，发现内存耗尽是由于Grafana和Prometheus之间的交互导致的，Grafana会使用Prometheus上的/api/v1/series这个API，进行{le!=""}的查询(含义是“获取所有直方图的度量”)。而/api/v1/series的实现在运行时间和空间上都没有任何限制，如果查询结果过多，就会消耗越来越多的内存和时间。即使请求者放弃请求并关闭连接，查询也会继续执行。对于我们的情况而言，无论多少内存都不够，Prometheus最终总会崩溃。于是，我们给Prometheus打了补丁，将这个API包裹在一个Context中以实现超时，终于修复了该问题。

虽然Prometheus的崩溃次数大大减少了，但我们依然需要经常重启，因此预写式日志(简称WAL)的重新执行依然是一个问题。重新执行所有 WAL 通常需要花费好几个小时，之后Prometheus才能启动，并开始收集度量和查询请求。在Robust Perception的帮助下，我们发现设置GOMAXPROCS=24可以极大地改善这个问题。因为Prometheus会在执行WAL期间尝试使用所有CPU核心，对于核心数量极多的服务器而言，核心之间的竞争会导致性能大幅度下降。

（编辑：桂林站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!