背景
最近接手維護了公司的名額監控系統，之後踩到坑就沒站起來過。。
本次問題的起因是我們配置了一些名額的删除政策沒有生效：
- 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-targets-timeseries-and-alerts/
後面我查到這篇文章也有相關解釋，了解了兩者的差別後再看這裡的分析會更加容易了解。
總的來說：
- relabel_configs 用于對抓取目标中繼資料的增删改；如果删除後連後續的抓取任務也會被取消。
- metric_relabel_configs 用于對抓取到的資料增删改，對于不需要的業務名額可以在這裡配置。
也就是前文講到的 relabel_configs 應用于名額抓取前，metric_relabel_configs 應用于名額抓取後。