Prometheus指标优化

Posted 2023-03-19

参考技术A

目前子业务处于打磨期，规模不大，因此监控由一个Prometheus节点管理。架构如下：

由于以下原因，目前可能不考虑高可用存储方案

基于上述背景，面对磁盘持续的增长，问题依然要解决，主要思路有以下几个方面

由于前两个思路有明显缺点，因此本文围绕“指标优化”的思路描述问题分析和解决的过程，问题解决主要采用自顶向下、层层分解，最终确定我们要优化的指标，当然也少不了想象力和同事的启发。

面对百万级的Metric，应该如何快速分析出问题指标，思路如下

在Prometheus主页 -> Status -> TSDB Status 可以看到当前Prometheus的概要统计

这里会有label数量、Metric数量、Label内存占用、最多Label键值对的统计。如上图所示，排名前几的数据远大于后续的，这里我们找到了第一批可以优化的Metric和Label。

在Prometheus主页 -> Targets 可以看到我们当前所有配置的Job，使用PromQL count可以快速对采集Job有个整体的分析

以个人实际优化案例来看，有以下排名前几的Metric值得关注

这样进一步缩小了Metric的排查范围，确定出了大范围覆盖的采集指标后，还可以进一步编写脚本，从CMDB获取实例和采集端口，一次性批量获取各采集Target的文件大小，然后进行排序。

这里我们基本完成了覆盖范围比较大的采集指标分析。

由于基础资源、中间件等通用基础设施能够进行一次性分析和优化，但是业务是动态增长和变化的，因此我们需要对核心业务进行抽查。

基于对业务的理解，对重点服务的指标进行抽查，果然快速发现了异常指标，如下图所示

业务指标在分桶的设置上不合理，而且这类指标几乎出现在各个微服务上，导致大量的空间浪费，以此类推我们找到了更多这样的指标。

指标优化主要采用了Relabeling的方式，因此先对该机制进行解析。发生在采集样本数据之前，对Target实例的标签进行重写的机制在Prometheus被称为Relabeling。

relabel有几种配置类别，需要进行重点区分

注意：以drop为例，relabel_configs匹配到的数据会直接丢弃不会采集，而metric_relabel_configs是先采集过来，然后进行匹配确定丢弃的内容。

Prometheus relabel具体的语法，请参考官方 文档

通过上述分析，我们基本确定了占比最大的待优化的指标，接下来就是如何进行指标优化，结合Relabel，方式如下：

1、 labeldrop

通过示例，我们用labeldrop方式将所有正则匹配到的label丢弃，减少无效label，降低存储空间

2、 指标keep

keep的方式是只保留正则匹配的metric，其余全部丢弃，这种方式适合非常确定要保留的指标，仅保留部分指标。

3、 指标drop

keep的方式是丢弃正则匹配的metric，保留其余指标，这种方式适合确定要优化的指标，仅优化部分指标。

4、 业务针对优化

如上文所述的“业务对于桶的设置不合理”的现象，通过与研发沟通，调整common库的Prometheus部分初始化逻辑，快速减少了无效指标。

关于指标分析，以后会朝着“自动化采集管理分析”方向演进，前期重点集中于以下几个方面

关于指标优化主要采用官方的Relabel方式进行优化。Prometheus后续架构可演进的建议如下：

不管用什么方案，总之指标的持续治理是不可避免的，有其他方式的欢迎多多交流。

https://prometheus.io/docs/prometheus/latest/