簡介
最近我有一個任務，需要跟蹤、搞定 series 基數問題，並顯著減少 Prometheus 的資源使用。為了做到這一點，我首先需要分析系統。在本文中，我將解釋如何使用 mimirtool 來識別平臺上使用哪些指標以及哪些沒有被使用。
先決條件
本文中描述的所有內容都是在 Kubernetes 環境中使用 kube-prometheus-stack 完成的。如果您的 Prometheus 部署方式與我不同，您可能需要進行調整，但如果您同時擁有 Prometheus 和 Grafana 的至少一個例項，那麼您應該可以繼續使用。
根據 Grafana 的官網：
Mimirtool 是一個 CLI 工具，可用於涉及 Grafana Mimir 或 Grafana Cloud Metrics 的 Prometheus 相容任務的各種操作。
要重現示例，您需要：
# Archlinux
pacman -Sy kubectl mimir jq
# MacOS
brew install kubectl mimirtool jq如果您的 Prometheus 和 Grafana 例項也在 Kubernetes 上執行，如果您希望能夠複製和貼上示例，則可以在下面的變數中複製它們的 pod 名稱：
# kubectl get pod -n monitoring | grep -E 'prometheus|grafana'
my_grafana_pod="kube-prometheus-stack-grafana-6b7fc54bd9-q2fdj"
my_prometheus_pod="prometheus-kube-prometheus-stack-prometheus-0"分析你的 Prometheus 的 metrics 使用情況
我們需要做的第一件事是確定我們使用的指標和我們擁有的指標。我過去曾使用 grep 手動完成此操作，但 mimirtool 使它變得非常簡單！
Grafana 儀表板中的指標
在我們提取 Grafana 例項中使用的指標列表之前，我們首先需要建立一個具有管理員角色的 Grafana API 金鑰。如果你有一個暴露的 Grafana 例項，只需開啟它並轉到 https://grafana.your.domain/org/apikeys 。如果沒有，您可能需要先公開它：
# Run this is a separate terminal
kubectl port-forward ${my_grafana_pod} -n monitoring 3000:3000然後你應該能夠開啟：http://localhost:3000/org/apikeys
從那裡，單擊 New API key 按鈕，為金鑰命名、管理員角色和可選的 TTL，如下所示：
Screenshot: Creation of a Grafana API Key.
單擊新增並將 Token 儲存到終端中的變數：
GRAFANA_API_TOKEN="copy your token here"我們現在可以使用 mimirtool 來提取我們的 Grafana 例項中使用的指標列表：
mimirtool analyze grafana --address=http://localhost:3000 --key="${GRAFANA_API_TOKEN}"完成後，您應該在當前目錄中有一個 metrics-in-grafana.json 檔案，其中包含 Grafana 中使用的 JSON 格式的指標列表。
Prometheus 規則中的指標
我們將對我們在 Prometheus 規則中使用的指標做同樣的事情。 因為我使用 Prometheus Operator，所以我的規則來自不同的地方和格式，主要是 ServiceMonitors 但不僅如此。最後，它們都載入到 Prometheus 例項本身，這就是為什麼我們需要直接在 Prometheus pod 上提取指標列表。
所有規則都位於我的 Prometheus pod 中的 /etc/prometheus/rules/ 中，檢查你的規則並在需要時進行調整：
# Print your Prometheus rules files
kubectl exec -it ${my_prometheus_pod} -n monitoring \
-- sh -c 'for i in `find /etc/prometheus/rules/ -type f` ; do cat $i ; done'如果您在輸出中看到您的 Prometheus 規則，請將它們匯出到本地檔案：
# Export your Prometheus rules files to a local file
kubectl exec -it ${my_prometheus_pod} -n monitoring \
-- sh -c 'for i in `find /etc/prometheus/rules/ -type f` ; do cat $i ; done' > my-prom-rules.yaml如果您有多個規則檔案，您可能需要在繼續之前修復 YAML 結構：
# Fix the combined rules YAML schema for mimirtool
sed -i -e 's/groups://g' -e '1s/^/groups:/' my-prom-rules.yaml您也可以在一個命令中執行此操作：
# One-liner
kubectl exec -it ${my_prometheus_pod} -n monitoring \
-- sh -c 'for i in `find /etc/prometheus/rules/ -type f` ; do cat $i ; done' \
| sed -e 's/groups://g' -e '1s/^/groups:/' > my-prom-rules.yaml現在我們在 my-prom-rules.yaml 中有了匯出的規則，我們現在可以使用 mimirtool 來提取指標列表：
mimirtool analyze rule-file my-prom-rules.yaml與我們為 Grafana 所做的類似，您現在應該在當前目錄中有一個 metrics-in-ruler.json 檔案，其中包含 Prometheus 規則中使用的指標列表。
其他地方的指標
根據您的環境，您可能會在其他地方使用 Prometheus 指標，例如，如果您有任何基於自定義指標的 HorizontalPodAutoscaler。如果是這種情況，您將需要找到一種方法在進一步操作之前將指標列表匯入其中一個檔案中。
與 Prometheus 對比
一旦我們同時擁有 metrics-in-grafana.json 和 metrics-in-ruler.json，其中包含我們當前使用的指標列表，我們就可以將它們與我們在 Prometheus 中擁有的所有指標進行比較。這使我們能夠獲得 Prometheus 中已使用和未使用的指標列表。
為此，我們需要公開我們的 Prometheus 例項：
# run this is a separate terminal
kubectl port-forward ${my_prometheus_pod} -n monitoring 9090:9090再一次，我們將使用 mimirtool 自動載入我們之前建立的檔案並將它們與儲存在我們的 Prometheus 例項中的指標進行比較：
mimirtool analyze prometheus --address=http://localhost:9090樣例輸出：
$ mimirtool analyze prometheus --address=http://localhost:9090
INFO[0000] Found 1377 metric names
INFO[0000] 22451 active series are being used in dashboards
INFO[0000] 28440 active series are NOT being used in dashboards
INFO[0000] 270 in use active series metric count
INFO[0000] 1105 not in use active series metric count最終會得到 prometheus-metrics.json 檔案，其中包括了已使用和未使用的 metrics 列表。
要以原始文字格式儲存已用指標列表：
jq -r ".in_use_metric_counts[].metric" prometheus-metrics.json | sort > used_metrics.txt要以原始文字格式儲存未使用的指標列表：
jq -r ".additional_metric_counts[].metric" prometheus-metrics.json | sort > unused_metrics.txt在此示例中，這是一個預設的 Kubernetes 部署，只有幾個正在執行的應用程式，我們看到只使用了 270/1377 個指標，這意味著 80% 的抓取指標從未使用過！您擁有的應用程式和指標越多，這個數字就越大。
未使用的列表可能是最有趣的一個。有了它，我們可以甄別那些或許可以在我們的儀表板和警報中利用的指標，但也可以甄別出或許需要在 Exporter 側禁用的無用指標，或者使用 relabeling 規則 刪除它們。
結語
在本文中，我們能夠從我們的 Prometheus 例項中提取已使用和未使用的指標列表。雖然這有助於理解我們的監控系統，但請記住，禁用和刪除未使用的指標可能對 Prometheus 效能的影響有限。在另一篇文章中，我將解釋我是如何處理基數問題並顯著減少 Prometheus 資源使用的。
本文作者的一些聯絡方式：
- GitHub : https://github.com/dotdc
- Mastodon : https://hachyderm.io/@0xDC
- Twitter : https://twitter.com/0xDC_
- LinkedIn : https://www.linkedin.com/in/0xDC
?
SRE的煩惱，我們懂
我們觀察到很多公司都搭建了林林總總的監控系統，但是不成體系，故障定位不夠快，老闆很焦慮。我們提供的Flashcat平臺透過整合這些既有的資料來源，提供業務、技術雙視角的全域性穩定性檢視和駕駛艙，讓監控、可觀測性體系化落地，出現問題也能快速定位，徹底去除故障焦慮。如果您有類似痛楚，快來填寫表單，聯絡我們交流試用吧！
