從原始碼徹底理解 Prometheus/VictoriaMetrics 中的 relabel/metric_configs 配置

crossoverJie發表於2023-03-13
原始碼Prometheus

背景

最近接手維護了公司的指標監控系統，之後踩到坑就沒站起來過。。

本次問題的起因是我們配置了一些指標的刪除策略沒有生效：

      - 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。
  • 如果可以匹配刪除，那就不會寫入儲存。

其中的關鍵程式碼如下：

這裡還有一個小細節，原始碼裡判斷的 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 應用於指標抓取後。

相關文章