Grafana Mimir Scaling 仪表盘：基于副本建议的容量扩展指南

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

本文围绕 Grafana Mimir 官方监控 Mixin 中的Scaling 仪表盘展开，讲解它如何通过对比服务当前实际副本数与“按原因计算出的必需副本数”，在故障或性能劣化场景下给出可操作的扩容建议。读完本文，你将掌握该仪表盘的面板结构、六类扩容原因的计算原理（含 Recording Rules 源码解析）、关键默认参数，以及如何安装和使用它来定位需要扩容的 Mimir 组件。

仪表盘定位：为故障场景提供扩容建议

Grafana Mimir 是面向 Prometheus 的水平可扩展、高可用、多租户长期存储方案，其生产级监控体系由 Grafana Mimir dashboards 和告警组成。其中Scaling 仪表盘专门解决一个问题：当集群因一种或多种原因出现故障时，哪些服务值得（且可能需要）横向扩容。

该仪表盘并不展示全部组件的实时状态，而是聚焦于「副本数量是否足够」这一维度。它给出的不是必须执行的硬性指标，而是“故障发生时可以参考的指导性建议”。这与 Mimir 官方文档中对该仪表盘的定位一致：

The Scaling dashboard displays services that you can optionally scale up in the event of a failure caused by one or more reasons.

从实现上看，仪表盘的定义位于 operations/mimir-mixin/dashboards/scaling.libsonnet，编译后的成品 JSON 位于 operations/mimir-mixin-compiled/dashboards/mimir-scaling.json，其背后依赖一组同名的 Recording Rules（mimir_scaling_rules），定义在 operations/mimir-mixin/recording_rules.libsonnet。

典型使用场景

官方文档明确了该仪表盘的三个典型用途，均围绕“扩容决策”这一主题：

1. 定位需要扩容的组件：当出现特定故障或性能问题时，快速识别 Mimir 的哪些组件需要扩容、需要扩到多少副本。
2. 逐服务审视负载指标：对比单个 Mimir 服务的指标（如 CPU 使用率与请求速率），判断哪个组件正承受高负载。
3. 联动 Runbook 指导扩容：与 Mimir 官方 runbook 配合，获取针对不同组件的扩容策略细节（如不同组件的扩容上限、注意点等）。

一句话概括：当集群“出问题”时，用这个仪表盘回答“该扩谁、扩多少、为什么”。

仪表盘结构与面板解读

顶部说明面板：六类扩容原因

仪表盘第一行是一个 Markdown 文本面板（height: '200px'），完整列出了仪表盘的工作方式与全部扩容原因。其核心语义如下：

• 仪表盘通过建议可能需要扩容的服务来识别与扩容相关的问题；
• 紧随其后的表格中给出建议的副本数（Required Replicas）以及原因（Reason）；
• 如果系统正在故障，请根据原因尝试扩容到指定副本数；
• 给出的数字是“出问题时的有用参考”，而非强制规定（原文：intended as helpful guidelines when things go wrong, rather than prescriptive guidelines）。

该文本面板的完整内容可在 scaling.libsonnet 中查看，六类原因总结如下表：

核心面板：Workload-based scaling 表格

第二行（height: '400px'）是仪表盘的核心可视化——名为Workload-based scaling的表格面板。其查询表达式（简化后）为：

sort_desc( cluster_namespace_deployment_reason:required_replicas:count > ignoring(reason) group_left cluster_namespace_deployment:actual_replicas:count )

其逻辑是：对每一个(cluster, namespace, deployment, reason)组合，把「必需副本数」与「当前实际副本数」做比较，按必需副本数降序排列，从而把最需要扩容的服务排在表格最前面。面板列定义（来自 scaling.libsonnet）：

实际使用时，按Service列即可看出是 distributor、ingester、memcached 还是其他 job 需要扩容；按Reason列即可判断是采样率、活跃序列还是 CPU/内存资源导致的扩容需求；Required Replicas列则给出目标副本数。

示例效果

下图是官方文档提供的 demo 集群中的 Scaling 仪表盘截图（来源：docs/sources/mimir/manage/monitor-grafana-mimir/dashboards/scaling/mimir-scaling.png）：

扩容建议背后的机制：Recording Rules 深度解析

Scaling 仪表盘本身只做“呈现”，真正完成计算的是一组名为mimir_scaling_rules的 Recording Rules（位于 operations/mimir-mixin/recording_rules.libsonnet）。理解了这些规则，才算真正理解仪表盘。规则最终编译输出为cluster_namespace_deployment_reason:required_replicas:count与cluster_namespace_deployment:actual_replicas:count两条核心时序指标（可在 operations/mimir-mixin-compiled/rules.yaml 中查看编译结果）。

基准数据：actual_replicas 与请求量

• cluster_namespace_deployment:actual_replicas:count：统计 Deployment 的kube_deployment_spec_replicas与 StatefulSet 的kube_statefulset_replicas的并集，并做了两处归一化：多可用区（multi-zone）部署会去掉zone-X后缀后合并统计；-rc/-wc这类滚动（rollout）副本后缀也被剥离，避免迁移期间重复计数。
• cluster_namespace_job:cortex_distributor_received_samples:rate5m：distributor 收到的采样速率，是sample_rate类规则的数据来源。

六类规则逐一拆解

以下公式均来自 recording_rules.libsonnet，可对照源码核验：

① distributor：sample_rate（采样率不足）

ceil( quantile_over_time(0.99, sum by (cluster, namespace) ( cluster_namespace_job:cortex_distributor_received_samples:rate5m )[24h:] ) / 240000 )

设计意图（源码注释）：distributor 应能处理240k samples/s。取过去 24h 的 P99 接收速率，除以单副本能力，向上取整得到必需副本数。

② distributor：sample_rate_limits（租户速率上限不足）

ceil( sum by (cluster, namespace) (cortex_limits_overrides{limit_name="ingestion_rate"}) * 0.6 / 240000 )

设计意图：副本应能覆盖各租户ingestion_rate上限总和的 60%（limit_utilisation_target = 0.6）。

③ ingester：sample_rate（采样率不足，含复制因子）

ceil( quantile_over_time(0.99, sum by (cluster, namespace) ( cluster_namespace_job:cortex_distributor_received_samples:rate5m )[24h:] ) * 3 / 80000 )

关键点：Mimir 默认复制因子（replication factor）为3，所以这里在 distributor 侧测得的采样速率要×3才等价于 ingester 实际写入速率；每个 ingester 按可处理80k samples/s计算（max_samples_per_sec_per_ingester = 80e3）。

④ ingester：active_series（活跃序列不足）

ceil( quantile_over_time(0.99, sum by(cluster, namespace) (cortex_ingester_memory_series)[24h:] ) / 1500000 )

设计意图：单个 ingester 内存中应能承载150 万条活跃序列（max_series_per_ingester = 1.5e6），取 24h 的 P99 活跃序列数除以该值。

⑤ ingester：active_series_limits（租户序列上限不足）

ceil( sum by (cluster, namespace) (cortex_limits_overrides{limit_name="max_global_series_per_user"}) * 3 * 0.6 / 1500000 )

设计意图：副本应能承载各租户max_global_series_per_user上限总和×3（复制因子）×60%的序列量。

⑥ ingester：sample_rate_limits（租户速率上限不足）

ceil( sum by (cluster, namespace) (cortex_limits_overrides{limit_name="ingestion_rate"}) * 0.6 / 80000 )

设计意图：同 distributor 的sample_rate_limits，但按 ingester 单副本 80k samples/s 计算。

⑦ memcached：active_series（缓存容量不足）

ceil( (sum by (cluster, namespace) ( cortex_ingester_tsdb_storage_blocks_bytes{job=~".+/ingester.*"} ) / 4) / avg by (cluster, namespace) ( memcached_limit_bytes{job=~".+/memcached"} ) )

设计意图（源码注释）：ingester 在磁盘上保存 96h 数据，期望 memcached 缓存其中的 1/4；用 ingester 磁盘块字节数除以 4，再除以 memcached 容量上限，得到所需 memcached 副本数。

⑧ 所有 job：cpu_usage与memory_usage（资源使用率不足）

这两个规则没有写死 deployment，而是对全部 job 通用：

ceil( cluster_namespace_deployment:actual_replicas:count * quantile_over_time(0.99, cluster_namespace_deployment:container_cpu_usage_seconds_total:sum_rate[24h]) / cluster_namespace_deployment:kube_pod_container_resource_requests_cpu_cores:sum )

思路是：用「当前实际副本数 × 24h P99 CPU 使用率」得到总需求，再除以「所有副本的 CPU requests 总和」得到必需副本数。内存规则memory_required_replicas_count结构完全相同，只是把 CPU 指标换成container_memory_usage_bytes与kube_pod_container_resource_requests_memory_bytes。这两条规则对 cAdvisor 暴露的 sandbox/parent cgroup 序列（image=""）做了过滤，避免 CPU 时间重复计数（见 config.libsonnet 中的注释）。

关键默认参数与自定义方式

所有可调参数都集中在 operations/mimir-mixin/recording_rules.libsonnet 与 operations/mimir-mixin/config.libsonnet 中：

需要注意的两点：

1. 多可用区归并：workload_group_regex为(.*?)(?:-zone-[a-z])?((?:-rc|-wc)-[0-9]+)?，会把-zone-a、-zone-b等多个可用区的同组件副本合并统计（见 config.libsonnet），因此扩容建议是按“整个服务（跨所有可用区）”给出的。
2. 部署形态差异：mimir_scaling_rules分为kubernetes与baremetal两组。Kubernetes 形态基于kube_deployment_spec_replicas、kube_statefulset_replicas、container_*等指标；baremetal 形态基于cortex_build_info、process_cpu_seconds_total、node_cpu_seconds_total等指标，且 CPU/内存公式中多除以一个resource_threshold（0.66），因为裸机场景没有 Kubernetes 资源请求（requests）语义，需要额外预留资源余量。两组模板由_config.deployment_type选择，编译期即确定使用哪一组。

若需修改单副本能力假设（如每个 ingester 能承载 200 万序列）或调整 60% 的利用率目标，直接在 mixin 配置中覆盖上述参数后重新编译即可。

安装与使用前提

Scaling 仪表盘随 Grafana Mimir 监控 Mixin 一起发布，安装方式与其余仪表盘、告警一致，见 Installing Grafana Mimir dashboards and alerts：

• 方式一（成品导入）：直接下载仓库 operations/mimir-mixin-compiled/dashboards 下的mimir-scaling.json导入 Grafana，并把 operations/mimir-mixin-compiled/rules.yaml 中的mimir_scaling_rules安装到 Prometheus。该方式使用默认配置，无法自定义指标标签名。
• 方式二（源码编译）：按 installing-dashboards-and-alerts.md 的指引，先调整 operations/mimir-mixin/config.libsonnet，再执行make build-mixin编译，最后导入operations/mimir-mixin-compiled/dashboards/下的 JSON 并安装rules.yaml与alerts.yaml。
• 方式三（Jsonnet vendoring）：若基础设施已用 Jsonnet 管理，可直接 vendor 整个 mixin 并通过覆盖_config字段定制（详见文档同一章节）。

安装前还需满足监控指标采集的标签要求（requirements），并由 Prometheus 或 Grafana Alloy 以约定的标签抓取 Mimir 集群指标；同时务必先安装配套的 Recording Rules，否则required_replicas、actual_replicas等指标不存在，表格将无数据可显示。

小结

Grafana Mimir Scaling 仪表盘是把「容量规划专家经验」固化成指标的一次典型实践：它不直接告诉你“系统坏了”，而是基于 24h 的 P99 负载曲线与租户上限配置，对每个服务算出“如果现在出问题，你应该有多少副本”，再与当前副本数对比，把差距最大的服务以表格形式呈现。理解其背后的mimir_scaling_rulesRecording Rules，是正确解读扩容建议、按需调整容量假设的前提——当你的集群负载模型与默认参数（如单副本 24 万 samples/s、150 万序列、60% 利用率目标）不符时，修改 mixin 配置并重新编译，才能让这份扩容指南真正贴合你的环境。

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