Prometheus 如何优化大盘加载的内存占用

根本原因是Grafana大盘查询触发大量时间序列读取与聚合计算，全由Prometheus内存完成；优化核心是分流负载：限制查询范围、降频采集、删除高基数标签、用录制规则预计算、拆分专用实例及启用远程读。

Prometheus 大盘加载慢、内存飙升，根本原因通常是 Grafana 查询触发了大量时间序列读取和聚合计算，而这些操作全由 Prometheus 实例在内存中完成。优化核心不是“让大盘更快”，而是“不让 Prometheus 为大盘扛下不该扛的负载”。

限制查询范围与降频指标

大盘默认常设 1 小时或 24 小时视图，但若底层指标基数高（比如带 pod_name、namespace、container_id 等高维标签），短短几分钟内就可能拉取数十万时间序列，直接压爆 Prometheus 内存。

1. 在 Grafana 面板中显式设置较短的查询时间范围（如 15 分钟），避免默认“最近 1 小时”带来的隐性压力
2. 对非关键监控项（如单个容器的网络包计数、进程打开文件数）改用更低频采集（如 scrape_interval: 60s 或 300s），减少单位时间样本密度
3. 对大盘只展示聚合结果的场景（如“集群 CPU 使用率”），禁用原始指标直查，改用录制规则预计算：

   groups:

   - name: cluster_cpu_usage

   rules:

   - record: cluster:cpu_usage:avg1m

   expr: 1 - avg by (cluster) (rate(node_cpu_seconds_total{mode="idle"}[1m]))

过滤高基数标签与冗余指标

一个 http_requests_total{job="api", instance="pod-123", path="/v1/user", status="200"} 就是一个独立时间序列；path 和 status 组合稍多，序列数就指数增长。大盘不需要看到每个 path 的明细，却在后台默默加载全部。

1. 在 scrape_configs 中用 metric_relabel_configs 删除大盘无用的标签：

   - source_labels: [path]

   regex: ".*"

   action: labeldrop

2. 用 relabel_configs 合并或泛化实例标识，避免每个 Pod IP 变成独立 series：

   - source_labels: [__meta_kubernetes_pod_name, __meta_kubernetes_namespace]

   target_label: instance

   separator: "_"

   → 把 pod-a_ns1、pod-b_ns1 等统一为可聚合维度

3. 直接 drop 调试类指标（如 go_gc_duration_seconds、process_open_fds），它们极少用于大盘，却显著增加索引负担

用录制规则替代实时 PromQL 计算

每次刷新大盘，Grafana 都会重跑一遍复杂 PromQL（如 sum by (service) (rate(http_requests_total[5m]))）。如果涉及百万级时间序列，Prometheus 必须先加载所有匹配 series，再做 rate + sum，内存峰值极易突破 10GB。

1. 把高频大盘查询固化为录制规则，每天生成固定频率的聚合序列（如每 30 秒一次），查询时只读这一个低基数序列
2. 录制规则命名要带业务语义（如 svc:requests_rate_5m:sum），方便 Grafana 直接引用，不拼 PromQL
3. 配合 --rule.files 加载规则，并确保 Prometheus 配置了足够 --web.enable-admin-api（便于调试规则执行情况）

拆分查询负载与启用远程读

单台 Prometheus 扛所有大盘查询，等于让数据库同时服务 OLTP + OLAP。合理分流是关键。

1. 为大盘专用部署一台轻量级 Prometheus 实例（仅加载录制规则和聚合指标），不抓取原始数据，只从主实例或对象存储同步结果
2. 若已用 Thanos，开启 Thanos Query 缓存（基于 Redis 或 Memcached），相同面板刷新复用缓存结果，避免重复计算
3. 对历史趋势类大盘（如“近 30 天错误率走势”），配置 remote_read 指向长期存储（如 Thanos Store Gateway），让查询绕过本地 TSDB，减轻 head block 压力