乐趣区

关于prometheus:从源码彻底理解-PrometheusVictoriaMetrics-中的-relabelmetricconfigs-配置

jiezi

背景

最近接手保护了公司的指标监控零碎，之后踩到坑就没站起来过。。

本次问题的起因是咱们配置了一些指标的删除策略没有失效：

      - action: drop_metrics
        regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"

与这两个容易引起误会的配置 relabel_configs/metric_relabel_configs 无关。

他们都是对抓取的数据进行重命名、过滤、新增、删除等操作，但利用场景却齐全不同。

咱们应用了 VictoriaMetrics 替换了 Prometheus，VM 齐全兼容 Prometheus，所以本文也对 Prometheus 同样实用。

了解谬误 1

但这里其实是有一个谬误了解的，我是通过 VM 的服务发现页面的指标响应页面查问指标的，关上之后的确能搜到须要被删除的相干指标。

但其实即使是真的删除了数据这个页面也会有数据存在，删除的数据只是不会写入 VM 的时序数据库中。

这一点是在后续查源码时才发现；前面我配置对了仍然在这里查看数据，发现还是没有删除，这个谬误了解节约了不少工夫😂。

了解谬误 2

为了解决问题，通过 drop metrics 这类关键字在 VM 的官网文档中查问，最终找到一篇文章。
https://www.robustperception.io/dropping-metrics-at-scrape-time-with-prometheus/

依照这里的介绍，将删除的配置退出到 metric_relabel_configs 配置下，通过测试的确无效。

不过为啥将同样的配置：

  relabel_configs:
      - action: drop_metrics
        regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"

退出到 relabel_configs 未能失效呢？

预计的确容易令人误导，在文档中也找到了相干的解释：
https://www.robustperception.io/relabel_configs-vs-metric_relabel_configs/

这篇文章次要是表白几个重点：

  • relabel_configs 用于配置哪个指标须要被抓取，产生在指标抓取之前。
  • metric_relabel_configs 产生在指标抓取之后，写入存储之前。
  • 如果其中一个没失效，就换一个（这句话很容易让人犯迷糊）

但说实话过后我看到这里还是一脸懵，为了彻底理解两则的区别还是看源码来的间接。

浏览源码了解实质起因

metric_relabel_configs

  metric_relabel_configs:
      - action: drop_metrics
        regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"

首先看下 metric_relabel_configs 配置失效的起因。

metric_relabel_configs 配置的整体流程如上图：

  • 启动 VM 时加载配置到内存
  • 依据配置的抓取间隔时间 (scrape_interval) 抓取数据，拿到的每一条数据都须要通过 metric_relabel_configs 的利用。
  • 针对于这里的 drop_metrics 来说，就是判断是否须要删除掉所有的 Label。
  • 如果能够匹配删除，那就不会写入存储。

其中的要害代码如下：

这里还有一个小细节，源码里判断的 action 是 drop，而咱们配置的是 drop_metrics，其实 drop_metrics 也是 drop 的一个封装而已。

在解析配置的时候会进行转换。

与这个写法是等价的：

      - source_labels: [__name__]
        regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"
        action: drop

relabel_configs

而后来看看 relabel_configs 没有依照预期失效的起因。

其实外围的利用配置就是同一份代码，只是触发点不一样。

relabel_configs 是在利用启动的时候依据咱们配置的抓取指标的数据当做数据源，所以这里的 action: drop 删除的是抓取指标，而不是真正的抓取数据。

而且它的目标是在利用启动的时候，用于生成抓取指标的工作，只会运行一次。

假如我这里改写为：

  relabel_configs:
      - source_labels: [__address__]
        regex: '192.xx.xx.xx:443'
        action: drop

那么我这个抓取工作就会被删除掉，而不是删除这个指标了。

因而之前我在这里配置的是一些业务指标 regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"，在所有元数据里天然是没有任何一个能够匹配了，所以也就无事产生。

元数据都是以 __ 结尾。

其实 VM 也有提供一个 Debug 页面用于调试 relabel_configs，但如果晓得怎么用这个调试页面其实也了解了他的运行原理😂

总结

https://www.robustperception.io/relabelling-can-discard-targe…

前面我查到这篇文章也有相干解释，了解了两者的区别后再看这里的剖析会更加容易了解。

总的来说：

  • relabel_configs 用于对抓取指标元数据的增删改；如果删除后连后续的抓取工作也会被勾销。
  • metric_relabel_configs 用于对抓取到的数据增删改，对于不须要的业务指标能够在这里配置。

也就是前文讲到的 relabel_configs 利用于指标抓取前，metric_relabel_configs 利用于指标抓取后。

退出移动版