背景
最近接手維護了公司的指標監控系統，之後踩到坑就沒站起來過。。 
<!--more-->
本次問題的起因是我們配置了一些指標的刪除策略沒有生效：
- 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 應用於指標抓取後。