Grafana Mimir Overview resources 仪表盘：组件级资源利用率监控实战指南

• 时序数据库
• 后端
• 数据存储
• 可观测性
• 云原生

Grafana Mimir 自带的Overview resources仪表盘用于集中展示 CPU、内存、磁盘等资源利用率指标，并将全部 Mimir 组件按数据路径划分为Writes（写入）、Reads（读取）与Backend（后端）三组。本文将以该仪表盘为切入点，结合仓库内 mixin 源码与编译产物，完整讲解其布局结构、面板 PromQL 原理、前置指标依赖（Additional resources metrics）以及从预编译产物或 Jsonnet 源码两种安装方式，帮助你把它直接落地到生产集群的日常监控与容量规划中。

仪表盘概述：一屏掌握 Writes / Reads / Backend 资源状况

根据官方文档 Overview resources dashboard 的定义，该仪表盘展示 CPU、内存、磁盘以及其他资源利用率指标，并把 Mimir 组件归入三大分组：

• Writes：承载写入链路的组件；
• Reads：承载查询链路的组件；
• Backend：其余支撑类组件。

这三组的分工并非凭空划分，而是由 mixin 配置 config.libsonnet 中的componentGroups明确界定：

local componentGroups = { write: ['distributor', 'ingester'], read: ['query_frontend', 'querier', 'ruler_query_frontend', 'ruler_querier'], backend: ['query_scheduler', 'ruler_query_scheduler', 'ruler', 'store_gateway', 'compactor', 'alertmanager', 'overrides_exporter'], remote_ruler_read: ['ruler_query_frontend', 'ruler_query_scheduler', 'ruler_querier'], },

也就是说，在这个仪表盘上：

• Writes面板聚合distributor（分发器）与ingester（摄入器）两类实例；
• Reads面板聚合query-frontend（查询前端）、querier（查询器）以及 ruler 专用查询路径的ruler-query-frontend、ruler-querier；
• Backend面板聚合query-scheduler（查询调度器）、ruler-query-scheduler、ruler（规则评估器）、store-gateway（存储网关）、compactor（压缩器）、alertmanager与overrides-exporter（租户覆盖导出器）。

此外，在启用了 Gateway 网关（mixin 配置gateway_enabled）的部署中，仪表盘还会在顶部额外渲染一个Gateway行，用于单独观察网关组件的 CPU 与内存，相关逻辑见 overview-resources.libsonnet。

典型使用场景

官方文档明确给出了该仪表盘的四个典型用途，同样也是运维日常中最高频的使用场景：

1. 按组件监控集群的资源利用率：通过 Writes / Reads / Backend 三组面板，快速对比各组件的 CPU、内存与磁盘消耗水平；
2. 实时监控以暴露性能问题：当写入或查询出现延迟时，通过资源面板判断瓶颈是否来自某组件的 CPU 或内存不足；
3. 基于当前用量预测未来的资源需求：观察资源增长趋势，为扩容、资源请求（request）/限制（limit）调整提供数据依据；
4. 定位压力过大的组件：结合分组面板与实例（Pod）维度的拆分，缩小排查范围到具体组件甚至具体副本。

部署前置条件：Additional resources metrics

文档特别强调：该仪表盘依赖"额外资源指标"（additional resources metrics）。这意味着仅抓取 Mimir 自身的cortex_*/mimir_*指标是不够的，还必须让 Prometheus 或 Grafana Alloy 同时抓取以下四个指标源：

• cAdvisor：提供容器级 CPU、内存、磁盘、网络指标（container_cpu_usage_seconds_total、container_memory_working_set_bytes、container_fs_writes_bytes_total等）；
• kubelet：Kubernetes 系统组件指标，同样由 kubelet 内置暴露；
• Node Exporter：提供节点级指标（node_cpu_seconds_total、node_disk_written_bytes_total、node_memory_*等）；
• kube-state-metrics：提供 Pod/容器的资源 request 与 limit 信息（kube_pod_container_resource_requests、kube_pod_container_resource_limits）。

除此之外，requirements.md还定义了严格的标签对齐要求，否则面板查不到数据：

如果通过mimir-distributedHelm chart 部署，其内置的metamonitoring支持会自动为抓取数据补齐上述标签；否则需要自行在 Prometheus / Alloy 抓取配置中完成标签注入。关于标签字段的自定义方式（per_cluster_label、per_namespace_label、per_job_label、per_instance_label、per_node_label），可参考 requirements.md 中的完整表格与 mixin 配置。

仪表盘布局与面板逐个拆解

仪表盘定义位于 mixin 源码 overview-resources.libsonnet，编译产物为operations/mimir-mixin-compiled/dashboards/mimir-overview-resources.json（UID 固定为a9b92d3c4d1af325d872a9e9a7083d71）。整体布局自上而下为：

1. Gateway 行（可选）

仅当$._config.gateway_enabled为真时渲染，包含三个面板：

• CPU：网关容器 CPU 使用率；
• Memory (workingset)：网关容器工作集内存；
• Memory (go heap inuse)：Go 运行时堆内存。

2. Writes 行

• CPU：写入组件容器 CPU 使用率，单位short（核心数），按实例标签聚合；
• Memory (workingset)：工作集内存，单位bytes；
• Memory (go heap inuse)：Go 堆内存使用量，单位bytes，用于观察 Go runtime 堆增长是否异常。

3. 磁盘面板行（标题为空）

• Disk writes：磁盘写入吞吐，单位Bps；
• Disk reads：磁盘读取吞吐，单位Bps；
• Disk space utilization：PVC 磁盘空间利用率，单位percentunit（0~1）。

这一行紧跟 Writes 行之后渲染，随后再依次出现Reads 行、Reads 磁盘行、Backend 行、Backend 磁盘行。也就是说，Writes / Reads / Backend 三组各拥有相同的面板组合：CPU + Memory（workingset）+ Go heap + Disk writes + Disk reads + Disk space utilization。

面板的复用手法体现了 mixin 的工程化设计：CPU、内存、Go heap、磁盘读写、磁盘空间利用率等面板都封装在 dashboard-utils.libsonnet 中，以containerCPUUsagePanelByComponent、containerMemoryWorkingSetPanelByComponent、containerGoHeapInUsePanelByComponent、containerDiskWritesPanelByComponent、containerDiskReadsPanelByComponent、containerDiskSpaceUtilizationPanelByComponent等函数按组件名批量生成。同样的函数也被writes-resources、reads-resources、compactor-resources等姊妹仪表盘复用，保证全仓库资源面板的一致性。

底层 PromQL：资源查询模板与部署类型适配

所有面板的查询语句并非硬编码在仪表盘文件中，而是统一收敛在 config.libsonnet 的resources_panel_queries配置中，并按Kubernetes与baremetal两种deployment_type分别定义。以下挑选核心查询说明其原理。

Kubernetes 部署模式下的关键查询

CPU 用量（按容器 CPU 总时间求速率）：

sum by(pod) (rate(container_cpu_usage_seconds_total{namespace=~"$namespace",container=~"<containerName>"}[$__rate_interval]))

工作集内存（刻意使用max而非sum，原因在源码注释中有明确说明：滚动更新期间 StatefulSet 的旧 Pod 指标有约 5 分钟滞后，若用sum会错误地把新旧实例内存累加）：

max by(pod) (container_memory_working_set_bytes{namespace=~"$namespace",container=~"<containerName>"})

Go 堆内存：

sum by(pod) (go_memstats_heap_inuse_bytes{namespace=~"$namespace",container=~"<containerName>"})

磁盘空间利用率（基于 kubelet 卷统计，PVC 名与容器名正则匹配）：

max by(persistentvolumeclaim) ( kubelet_volume_stats_used_bytes{namespace=~"$namespace", persistentvolumeclaim=~".*(<containerName>).*"} / kubelet_volume_stats_capacity_bytes{namespace=~"$namespace", persistentvolumeclaim=~".*(<containerName>).*"} )

磁盘写入/读取吞吐在 Kubernetes 模式下使用 Node Exporter 的节点级磁盘速率指标，并通过ignoring(pod) group_right()与 cAdvisor 的容器磁盘写指标做关联，同时借助device!~".*sda.*"过滤掉系统启动盘（node_boot_disk_device_regex默认匹配sda，若云厂商默认设备是vda需要覆盖该配置，见 config.libsonnet），避免启动盘流量干扰 Mimir 数据盘视图。

此外，在 Kubernetes 模式下，内存面板还会叠加一个OOMKilled 标记查询（kube_pod_container_status_last_terminated_reason{...,reason="OOMKilled"}的首次出现检测），一旦有 Pod 因内存超限被杀，面板会立刻以独立图例样式标出，这对定位内存压力组件非常有价值。

baremetal 部署模式下的查询差异

当deployment_type: 'baremetal'时，resources_panel_queries.baremetal下定义的是另一套面向节点级指标的查询，例如 CPU 使用只统计node_cpu_seconds_total{mode="user"}，工作集内存用node_memory_MemTotal_bytes减MemFree、Buffers、Cached、Slab、PageTables、SwapCached近似计算，磁盘利用率基于node_filesystem_*在mountpoint=instanceDataDir（默认/，可通过instance_data_mountpoint调整）上的可用空间比例计算。裸机部署下不存在容器 request/limit 与 PVC 概念，因此相关查询被省略。注意：文档要求，baremetal 部署需设置deployment_type: 'baremetal'并重新编译仪表盘。

组件分组与标签匹配机制

面板能否选对指标，取决于 mixin 中的正则匹配器。config.libsonnet中instance_names与container_names两组配置分别定义了"实例（Pod/节点）"与"容器"两类正则：

• 在 Kubernetes 模式下，实例正则会被包装成 Helm 兼容格式(.*mimir-)?<name>.*，以兼容mimir-distributedHelm chart 生成的组件命名（如mimir-ingester-*）；
• 裸机模式下则包装成.*<name>形式，匹配任意前缀。

同时per_instance_label控制按哪个标签拆线（Kubernetes 部署编译产物中实际为pod，配合 Node 级标签instance共同定位），per_node_label默认取instance。分组面板（如 Writes 行的write、Reads 行的read）则把组内各组件的正则用|连接后整体匹配，因此在编译后的 JSON 中可以看到诸如container=~"query-frontend|querier|ruler-query-frontend|ruler-querier"这样的联合正则。

这也解释了为什么文档反复强调job 标签的选择规则：在微服务模式下job应为<namespace>/<component>（如<namespace>/ingester、<namespace>/store-gateway），单机一体化模式下应为<namespace>/mimir。详情见 requirements.md 的 Job selection 一节。

安装与启用

Overview resources 仪表盘随 Grafana Mimir 的监控套件一起分发，支持两种安装方式：

方式一：直接导入预编译产物

无需编译，直接从仓库的operations/mimir-mixin-compiled/dashboards/目录下载 mimir-overview-resources.json，在 Grafana 中通过 Dashboards → Import 导入即可。该方式的仪表盘使用默认配置，无法自定义标签名，适合快速上手。完整的导入步骤见 installing-dashboards-and-alerts.md。

方式二：从 Jsonnet 源码编译

当需要自定义标签名、组件匹配正则或部署类型时，应从源码编译：

1. 检阅并修改 mixin 配置 operations/mimir-mixin/config.libsonnet，例如将deployment_type改为'baremetal'、覆盖per_instance_label、调整job_names等；

2. 在仓库根目录执行编译命令：

   make build-mixin

3. 将生成的operations/mimir-mixin-compiled/dashboards/目录下的 JSON 导入 Grafana。

若你已在用 Jsonnet 做基础设施即代码（IaC），也可将operations/mimir-mixin作为 mixin 依赖 vendoring 进自己的仓库，通过覆盖_config字段定制后编译，详细步骤同样参见 installing-dashboards-and-alerts.md。另外需要注意，面板依赖的 PromQL 大量使用$__rate_interval，若 Prometheus 抓取间隔大于默认的1m，应重新编译 mixin 并同步调整scrape_interval配置，以保证速率窗口足够大（见 requirements.md 的说明）。

实战建议

• 与姊妹仪表盘搭配使用：Overview resources 只做资源概览，若要深挖写入/读取链路的延迟、错误率，可切换到Mimir / Writes、Mimir / Reads；若要细看某组件的网络吞吐与并发连接，可参考writes-networking、reads-networking。这些仪表盘之间的跳转链接已内置于Mimir / Overview仪表盘面板描述中（见 mimir-overview.json），其中 Overview resources 的 UIDa9b92d3c4d1af325d872a9e9a7083d71正是由overview-resources.libsonnet中std.md5(filename)计算得出并用于跨盘引用的。
• 排查顺序建议：先看对应分组（Writes/Reads/Backend）的 CPU 与工作集内存是否有单实例突刺 → 再看 Go heap 是否持续增长（疑似内存泄漏）→ 观察磁盘空间利用率是否接近 100%（store-gateway/compactor 的 PVC 是高发点）→ 结合 OOMKilled 标记确认是否存在内存 Limit 过小的问题。
• 容量预测：在 Grafana 中拉长时间范围（如 30d）观察资源趋势曲线，配合kube_pod_container_resource_limits/requests相关的 limit/request 线，可以判断当前 request 是否贴合实际用量，为后续扩缩容提供数据支撑。

总结

Overview resources 仪表盘是 Grafana Mimir 运维观测体系中"资源维度"的入口级视图，通过 Writes / Reads / Backend 三组分组聚合了 CPU、内存（工作集与 Go heap）、磁盘读写与磁盘空间等核心指标。其背后由operations/mimir-mixin的 Jsonnet 源码统一生成，查询模板按 Kubernetes / baremetal 两套部署模型适配，标签选择、组件分组均可通过 mixin 配置灵活定制。只要满足 Additional resources metrics 的指标采集与标签对齐要求，即可在生产环境直接导入使用，用于实时监控、性能定位与容量规划。

• 时序数据库
• 后端
• 数据存储
• 可观测性
• 云原生