根本原因是grafana大盘查询触发大量时间序列读取与聚合计算，全由prometheus内存完成；优化核心是分流负载：限制查询范围、降频采集、删除高基数标签、用录制规则预计算、拆分专用实例及启用远程读。
Prometheus 大盘加载慢、内存飙升，根本原因通常是 Grafana 查询触发了大量时间序列读取和聚合计算，而这些操作全由 Prometheus 实例在内存中完成。优化核心不是“让大盘更快”，而是“不让 Prometheus 为大盘扛下不该扛的负载”。
限制查询范围与降频指标
大盘默认常设 1 小时或 24 小时视图，但若底层指标基数高（比如带 pod_name、namespace、container_id 等高维标签），短短几分钟内就可能拉取数十万时间序列，直接压爆 Prometheus 内存。
- 在 Grafana 面板中显式设置较短的查询时间范围（如 15 分钟），避免默认“最近 1 小时”带来的隐性压力
- 对非关键监控项（如单个容器的网络包计数、进程打开文件数）改用更低频采集（如 scrape_interval: 60s 或 300s），减少单位时间样本密度
- 对大盘只展示聚合结果的场景（如“集群 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 的明细，却在后台默默加载全部。
- 在
scrape_configs中用 metric_relabel_configs 删除大盘无用的标签：- source_labels: [path]regex: ".*"action: labeldrop - 用 relabel_configs 合并或泛化实例标识，避免每个 Pod IP 变成独立 series：
- source_labels: [__meta_kubernetes_pod_name, __meta_kubernetes_namespace]target_label: instanceseparator: "_"
→ 把pod-a_ns1、pod-b_ns1等统一为可聚合维度 - 直接 drop 调试类指标（如
go_gc_duration_seconds、process_open_fds），它们极少用于大盘，却显著增加索引负担
用录制规则替代实时 PromQL 计算
每次刷新大盘，Grafana 都会重跑一遍复杂 PromQL（如 sum by (service) (rate(http_requests_total[5m]))）。如果涉及百万级时间序列，Prometheus 必须先加载所有匹配 series，再做 rate + sum，内存峰值极易突破 10GB。
- 把高频大盘查询固化为录制规则，每天生成固定频率的聚合序列（如每 30 秒一次），查询时只读这一个低基数序列
- 录制规则命名要带业务语义（如
svc:requests_rate_5m:sum），方便 Grafana 直接引用，不拼 PromQL - 配合 --rule.files 加载规则，并确保 Prometheus 配置了足够 --web.enable-admin-api（便于调试规则执行情况）
拆分查询负载与启用远程读
单台 Prometheus 扛所有大盘查询，等于让数据库同时服务 OLTP + OLAP。合理分流是关键。
- 为大盘专用部署一台轻量级 Prometheus 实例（仅加载录制规则和聚合指标），不抓取原始数据，只从主实例或对象存储同步结果
- 若已用 Thanos，开启 Thanos Query 缓存（基于 Redis 或 Memcached），相同面板刷新复用缓存结果，避免重复计算
- 对历史趋势类大盘（如“近 30 天错误率走势”），配置 remote_read 指向长期存储（如 Thanos Store Gateway），让查询绕过本地 TSDB，减轻 head block 压力
