从源码彻底理解 Prometheus/VictoriaMetrics 中的 relabel_configs/metric_relabel_configs 配置

源码,彻底,理解,prometheus,victoriametrics,relabel,configs,metric,配置 · 浏览次数 : 128

小编点评

**理解错误1:** * 通过 VM 的服务发现页面的指标响应页面查询指标,打开之后确实能搜到需要被删除的相关指标。 * 但是即使真的删除了数据这个页面也会有数据存在,删除的数据只是不会写入 VM 的时序数据库中。 * 这点是在后续查源码时才发现的,为了彻底了解两则的区别还是看源码来的直接。 **理解错误2:** * relabel_configs 配置的 overall 流程如上图:启动 VM 时加载配置到内存根据配置的抓取间隔时间(scrape_interval)抓取数据,拿到的每一条数据都需要通过 metric_relabel_configs 的应用。 * 针对于这里的 drop_metrics 来说,就是判断是否需要删除掉所有的 Label。 * 如果可以匹配删除,那就不会写入存储。 * 中的代码如下: - source_labels: [ __name__ ] regex: "^envoy_.*|^url\\_\\_\\_\\_.*|istio_request_bytes_sum" action: droprelabel_configs * 其实核心的应用配置就是同一份代码,只是触发点不一样。 * relabel_configs 是在应用启动的时候根据我们配置的抓取目标的数据当做数据源,所以这里的 action: drop 删除的是抓取目标,而不是真正的抓取数据。

正文

背景

最近接手维护了公司的指标监控系统,之后踩到坑就没站起来过。。

本次问题的起因是我们配置了一些指标的删除策略没有生效:

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

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

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

我们使用了 VictoriaMetrics 替换了 Prometheus,VM 完全兼容 Prometheus ,所以本文也对 Prometheus 同样适用。

理解错误1

image.png
但这里其实是有一个错误理解的,我是通过 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
  • 如果可以匹配删除,那就不会写入存储。

其中的关键代码如下:

这里还有一个小细节,源码里判断的 actiondrop,而我们配置的是 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-targets-timeseries-and-alerts/


后面我查到这篇文章也有相关解释,理解了两者的区别后再看这里的分析会更加容易理解。

总的来说:

  • relabel_configs 用于对抓取目标元数据的增删改;如果删除后连后续的抓取任务也会被取消。
  • metric_relabel_configs 用于对抓取到的数据增删改,对于不需要的业务指标可以在这里配置。

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

与从源码彻底理解 Prometheus/VictoriaMetrics 中的 relabel_configs/metric_relabel_configs 配置相似的内容:

从源码彻底理解 Prometheus/VictoriaMetrics 中的 relabel_configs/metric_relabel_configs 配置

背景 最近接手维护了公司的指标监控系统,之后踩到坑就没站起来过。。 本次问题的起因是我们配置了一些指标的删除策略没有生效: - action: drop_metrics regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum" 与这两个容易引

从源码入手详解ReentrantLock,一个比synchronized更强大的可重入锁

写在开头 随手一翻,发现对于Java中并发多线程的学习已经发布了十几篇博客了,多线程 是Java基础中的重中之重!因此,可能还需要十几篇博客才能大致的讲完这部分的知识点,初学者对于这部分内容一定要多花心思,不可马虎!今天我们继续来学习一个重要知识点:ReentrantLock ReentrantLo

从源码层面深度剖析Spring循环依赖

作者:郭艳红 以下举例皆针对单例模式讨论 图解参考 https://www.processon.com/view/link/60e3b0ae0e3e74200e2478ce 1、Spring 如何创建Bean? 对于单例Bean来说,在Spring容器整个生命周期内,有且只有一个对象。 Sprin

从源码角度剖析 golang 如何fork一个进程

# 从源码角度剖析 golang 如何fork一个进程 创建一个新进程分为两个步骤,一个是fork系统调用,一个是execve 系统调用,fork调用会复用父进程的堆栈,而execve直接覆盖当前进程的堆栈,并且将下一条执行指令指向新的可执行文件。 在分析源码之前,我们先来看看golang fork

从源码角度深入解析Callable接口

摘要:从源码角度深入解析Callable接口,希望大家踏下心来,打开你的IDE,跟着文章看源码,相信你一定收获不小。 本文分享自华为云社区《一个Callable接口能有多少知识点?》,作者: 冰 河。 并发编程一直是程序员们比较头疼的,如何编写正确的并发程序相比其他程序来说,是一件比较困难的事情,并

从源码层面深度剖析Spring循环依赖

本文从源码层面介绍了Spring如何创建bean、如何解决循环依赖,同时也介绍了不能解决哪些循环依赖,同时在文章的最后解决循环依赖报错的几个方法

从源码中解析fabric区块数据结构(一)

从源码中解析fabric区块数据结构(一) 前言 最近打算基于fabric-sdk-go实现hyperledger fabric浏览器,其中最重要的一步就是解析fabric的上链区块。虽说fabric是Golang实现的,但直到2021年2月1号才发布了第一个稳定版fabric-sdk-go,而且官

源码级深度理解 Java SPI

本文从源码入手分析,深入探讨 Java SPI 的特性、原理,以及在一些比较经典领域的应用。

聊聊我认为的OpenFeign

此篇文章不从源码角度解析,网上一搜一大把。我个人的习惯是自己评估与思考下大概的设计思路是什么,然后看源码与博客佐证。否则一来就是使用然后看源码,一坨一坨的代码,真的看的头疼。以上仅是个人的学习方法。 聊聊OpenFeign,其实这个框架,之前用过,但没留意太多;说白了这个框架的出现就是为了让我们做R

如何正确使用 ThreadLocal,你真的用对了吗?

本文主要从源码的角度解析了 ThreadLocal,并分析了发生内存泄漏的原因及正确用法,最后对它的应用场景进行了简单介绍。