背景

最近接手維護(hù)了公司的指標(biāo)監(jiān)控系統(tǒng)，之后踩到坑就沒站起來過。。

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

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

與這兩個容易引起誤解的配置relabel_configs/metric_relabel_configs有關(guān)。

他們都是對抓取的數(shù)據(jù)進(jìn)行重命名、過濾、新增、刪除等操作，但應(yīng)用場景卻完全不同。

我們使用了 VictoriaMetrics 替換了 Prometheus，VM 完全兼容 Prometheus ，所以本文也對 Prometheus 同樣適用。

理解錯誤1

但這里其實(shí)是有一個錯誤理解的，我是通過 VM 的服務(wù)發(fā)現(xiàn)頁面的指標(biāo)響應(yīng)頁面查詢指標(biāo)的，打開之后確實(shí)能搜到需要被刪除的相關(guān)指標(biāo)。

但其實(shí)即便是真的刪除了數(shù)據(jù)這個頁面也會有數(shù)據(jù)存在，刪除的數(shù)據(jù)只是不會寫入 VM 的時序數(shù)據(jù)庫中。

這一點(diǎn)是在后續(xù)查源碼時才發(fā)現(xiàn)；后面我配置對了依然在這里查看數(shù)據(jù)，發(fā)現(xiàn)還是沒有刪除，這個錯誤理解浪費(fèi)了不少時間??。

理解錯誤2

為了解決問題，通過 drop metrics 這類關(guān)鍵字在 VM 的官方文檔中查詢，最終找到一篇文章。https://www.robustperception.io/dropping-metrics-at-scrape-time-with-prometheus/。

按照這里的介紹，將刪除的配置加入到 metric_relabel_configs 配置下，經(jīng)過測試確實(shí)有效。

不過為啥將同樣的配置：

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

加入到 relabel_configs 未能生效呢？

估計確實(shí)容易令人誤導(dǎo)，在文檔中也找到了相關(guān)的解釋：https://www.robustperception.io/relabel_configs-vs-metric_relabel_configs/

這篇文章主要是表達(dá)幾個重點(diǎn)：

• relabel_configs 用于配置哪個目標(biāo)需要被抓取，發(fā)生在指標(biāo)抓取之前。
• metric_relabel_configs 發(fā)生在指標(biāo)抓取之后，寫入存儲之前。
• 如果其中一個沒生效，就換一個（這句話很容易讓人犯迷糊）。

但說實(shí)話當(dāng)時我看到這里還是一臉懵，為了徹底了解兩則的區(qū)別還是看源碼來的直接。

閱讀源碼理解本質(zhì)原因

metric_relabel_configs

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

首先看下metric_relabel_configs配置生效的原因。

metric_relabel_configs 配置的整體流程如上圖：

• 啟動 VM 時加載配置到內(nèi)存。
• 根據(jù)配置的抓取間隔時間(scrape_interval)抓取數(shù)據(jù)，拿到的每一條數(shù)據(jù)都需要通過 metric_relabel_configs 的應(yīng)用。
• 針對于這里的 drop_metrics 來說，就是判斷是否需要刪除掉所有的 Label。
• 如果可以匹配刪除，那就不會寫入存儲。

其中的關(guān)鍵代碼如下：

這里還有一個小細(xì)節(jié)，源碼里判斷的 action 是 drop，而我們配置的是 drop_metrics，其實(shí) drop_metrics 也是 drop 的一個封裝而已。

在解析配置的時候會進(jìn)行轉(zhuǎn)換。

與這個寫法是等價的：

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

relabel_configs

然后來看看 relabel_configs 沒有按照預(yù)期生效的原因。

其實(shí)核心的應(yīng)用配置就是同一份代碼，只是觸發(fā)點(diǎn)不一樣。

relabel_configs 是在應(yīng)用啟動的時候根據(jù)我們配置的抓取目標(biāo)的數(shù)據(jù)當(dāng)做數(shù)據(jù)源，所以這里的 action: drop 刪除的是抓取目標(biāo)，而不是真正的抓取數(shù)據(jù)。

而且它的目的是在應(yīng)用啟動的時候，用于生成抓取目標(biāo)的任務(wù)，只會運(yùn)行一次。

假設(shè)我這里改寫為：

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

那么我這個抓取任務(wù)就會被刪除掉，而不是刪除這個指標(biāo)了。

因此之前我在這里配置的是一些業(yè)務(wù)指標(biāo) regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum"，在所有元數(shù)據(jù)里自然是沒有任何一個可以匹配了，所以也就無事發(fā)生。

元數(shù)據(jù)都是以 __ 開頭。

其實(shí) VM 也有提供一個 Debug 頁面用于調(diào)試 relabel_configs，但如果知道怎么用這個調(diào)試頁面其實(shí)也理解了他的運(yùn)行原理??

總結(jié)

https://www.robustperception.io/relabelling-can-discard-targets-timeseries-and-alerts/。

后面我查到這篇文章也有相關(guān)解釋，理解了兩者的區(qū)別后再看這里的分析會更加容易理解。

總的來說：

• relabel_configs 用于對抓取目標(biāo)元數(shù)據(jù)的增刪改；如果刪除后連后續(xù)的抓取任務(wù)也會被取消。
• metric_relabel_configs 用于對抓取到的數(shù)據(jù)增刪改，對于不需要的業(yè)務(wù)指標(biāo)可以在這里配置。

也就是前文講到的 relabel_configs 應(yīng)用于指標(biāo)抓取前，metric_relabel_configs 應(yīng)用于指標(biāo)抓取后。