共计 4151 个字符，预计需要花费 11 分钟才能阅读完成。
简介
最近我有一个工作，须要跟踪、搞定 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 平台通过集成这些既有的数据源，提供业务、技术双视角的全局稳定性视图和驾驶舱，让监控、可观测性体系化落地，呈现问题也能疾速定位，彻底去除故障焦虑。如果您有相似痛楚，快来填写表单，分割咱们交换试用吧！
