企业官网建设流程全解析

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

Grafana Mimir 2.9 是一次以“降本增效”为主线的重要版本：它降低了 store-gateway 与 querier 在宽匹配器查询下的内存/CPU 开销，为 Ruler 引入实验性对象存储缓存并将规则同步间隔从1m放宽至10m，还带来了 ingester 到 querier 流式 chunks 的实验性支持。本文基于 docs/sources/mimir/release-notes/v2.9.md 与当前仓库源码，完整梳理该版本的功能增强、废弃/移除项、默认值变化与缺陷修复，帮助你在升级前准确评估影响面。

版本亮点概览

Grafana Mimir 2.9 的核心亮点可以归纳为四类性能优化加一项实验性能力：

• 降低 store-gateway 内存占用：当查询包含宽泛的 label 匹配器（例如datacenter="dc1"）时，Mimir 2.9 会拉取更少的索引数据，从而显著减少 store-gateway 的内存分配；
• 降低部分 shuffle sharding 场景下的 CPU 占用：当租户启用了 shuffle sharding，且 shard size 较大但仍小于 ingester 总数时，querier 的 CPU 消耗明显下降；
• 减少 compactor 与 ruler 的对象存储 API 调用次数：包括实验性的 ruler 存储缓存与“规则变更即时同步”两项优化；
• 实验性支持从 ingester 到 querier 流式传输 chunks：预期在大基数查询场景下大幅降低 querier 内存占用，因为 chunks 可以被按需读入内存。

完整的变更清单可参见仓库内的 CHANGELOG.md。

功能与增强

1. Ruler 存储缓存（实验性）

在运行 2 个及以上 ruler 副本的 Mimir 集群中，每个副本都会周期性地向对象存储发起 “list objects” 请求来发现规则文件。2.9 引入了实验性的 ruler 存储缓存来减少这类调用，可通过-ruler-storage.cache.*CLI flags 或其对应的 YAML 配置项进行配置。

从源码结构看，该配置定义在 pkg/ruler/rulestore/config.go：rulestore.Config内嵌了Cache cache.BackendConfig字段，并以ruler-storage.为前缀注册 flags。需要注意两个实现约束：

• 缓存支持的 backend 目前是memcached（supportedCacheBackends = []string{cache.BackendMemcached}），且除local（本地目录）存储外均适用；
• 在后续版本中（见 CHANGELOG.md 第 1197 行附近），实验性 flag-ruler-storage.cache.rule-group-enabled被移除，只要配置了缓存，规则组内容的缓存就始终启用。

2. 规则变更即时同步，-ruler.poll-interval放宽至 10m

2.9 引入了一项新特性：当通过 API 修改租户规则配置时，立即触发一次该租户规则组的同步，而不必等待周期性轮询。作为配套，周期性同步间隔-ruler.poll-interval的默认值从1m放宽到10m。

这一新行为默认全局启用，可通过以下两种方式调整：

• 全局禁用：-ruler.sync-rules-on-changes-enabled=false；
• 租户级调整：per-tenant overrideRulerSyncRulesOnChangesEnabled（接口定义见 pkg/ruler/compat.go）。

从源码实现看，同步链路是异步的 “fire-and-forget” 模式：pkg/ruler/ruler.go 中的NotifySyncRulesAsync首先检查租户级开关，随后把 userID 入队到outboundSyncQueue；随后notifySyncRules会遍历 ring 中所有活跃 ruler，调用SyncRulesgRPC 端点（pkg/ruler/ruler.go），并且不等待远端实例完成同步、失败仅记录日志。这也意味着即时同步是“尽力而为”的加速通道，-ruler.poll-interval的周期轮询仍然是最终的一致性兜底。

3. 减少 compactor 与 ruler 的对象存储访问

除 ruler 缓存外，2.9 还包含针对 compactor 和 ruler 访问对象存储中规则数据的通用优化，目的是减少不必要的 list/get 调用。对于规则数量庞大或对象存储费用敏感的集群，这是一项“静默”的成本优化——升级后通常无需改配置即可受益。

4. store-gateway 内存优化与 shuffle sharding CPU 优化

• 宽匹配器索引裁剪：面对datacenter="dc1"这类覆盖大量 series 的匹配器，store-gateway 现在只拉取裁剪后的索引数据，直接减少内存分配。这在 store-gateway 因宽查询被 OOM 的集群中收益最直接；
• shuffle sharding CPU 优化：当租户 shard size 较大但小于 ingester 总数时（例如 3 副本 ring 中 shard size 为 2 这类“半冗余”配置），querier 过去会在每个 shard 上重复做无效功，2.9 修复了这一冗余路径的 CPU 开销。

5. 实验性：ingester 到 querier 的流式 chunks

2.9 增加了实验性支持：querier 查询 ingester 时可以流式接收 chunks，而不是等整个响应打包后一次性载入内存。这使得选择大量 series 的查询内存曲线从“峰值集中”变为“按需读取”。

从源码结构看，流式消费侧实现在 pkg/querier/block_streaming.go：storeGatewayStreamReader负责管理来自远端的 chunk 流与缓冲，通过StartBuffering启动流式读取，逐批处理storepb.StreamingChunks消息，并基于StreamingChunksEstimate进行预估。当前仓库主干中，这一机制已演进为更通用的 streaming 读路径，验证了 2.9 实验特性的技术方向。

6. Helm chart 独立发布

Grafana Mimir 和 Grafana Enterprise Metrics 的 Helm chart 从 2.9 起独立发布。仓库内保留了完整的 chart 定义与测试集，包括 operations/helm/charts 下的模板、operations/helm/tests 下约 2200 个测试 YAML，以及 operations/compare-helm-with-jsonnet/ 中用于保证 Helm 与 jsonnet 输出一致性的对比工具。如果你此前跟随 jsonnet 部署，升级 chart 时应注意版本节奏与 Mimir 本体不再同步。

重要变更（Important changes）

升级 2.9 前，以下变更需要逐一核对你的部署配置与监控告警。

已移除的指标与配置

被移除的已废弃/实验性指标：

• cortex_bucket_store_chunk_pool_requested_bytes_total
• cortex_bucket_store_chunk_pool_returned_bytes_total

在 2.9 新标记为废弃、并计划于 2.11 移除的配置：

2.9 中正式移除的 2.7 已废弃配置：

如果你的启动脚本或 Helm values 中还显式传着这些 flag，升级后应清理掉，避免依赖已无意义的参数。

实验特性转为稳定（Stable）

以下 flag 从实验性转为稳定，可放心用于生产：

• -query-frontend.query-sharding-max-regexp-size-bytes
• -query-scheduler.max-used-instances
• -(alertmanager|blocks|ruler)-storage.storage-prefix
• -compactor.first-level-compaction-wait-period
• -usage-stats.enabled与-usage-stats.installation-mode
• -query-frontend.query-sharding-target-series-per-shard

其中query-sharding-max-regexp-size-bytes的判定逻辑可见 pkg/frontend/querymiddleware/limits.go 的接口定义与 pkg/frontend/querymiddleware/querysharding.go 的实现：sharding 决策会读取多租户中“最小正数”作为正则大小上限，防止因单个租户配置为 0（不限制）而使分片决策失控。

默认值变更

关于 partial block 清理，从源码结构看，compactor 的 block cleaner 在 pkg/compactor/blocks_cleaner.go 中逐租户读取CompactorPartialBlockDeletionDelay，当延迟低于允许的最小值时会以警告日志禁用该租户的清理逻辑。默认1d意味着：block 上传或租户删除过程中意外中断留下的part/前缀对象，会在一天后被自动删除，减少了人工清理 partial block 的运维负担——但如果你依赖自定义脚本清理这些对象，需要重新核对窗口期是否冲突。

缺陷修复（Bug fixes）

• Store-gateway：检测 postings cache 中的碰撞（上游 PR #4770）。postings cache 碰撞若不被检测，理论上可能返回错误的 postings 列表，此修复保证数据正确性；
• Store-gateway：修复LabelValues响应缓存值超过 655360 个时的 panic（上游 PR #5021）。对于高基数 label（如instance值极多的租户），此前命中的超长缓存条目会触发 panic，现予以修复。

2.9.4：安全补丁

2.9.4 将 Alpine 基础镜像升级到 3.18.5，用于修复 CVE-2023-5363（上游 PR #6895）。如果你部署在 2.9.x 线上环境，建议直接采用 2.9.4 及以上构建。

升级建议小结

结合以上变更，升级 2.9 前的核对清单：

1. 清理已移除的 4 个 flag（2.7 废弃项），否则部分发行版启动时会因未知/无效参数告警；
2. 监控大盘中引用cortex_bucket_store_chunk_pool_*_total两个指标的面板需要下线或替换；
3. 评估query-sharding-max-regexp-size-bytes默认4096是否会影响你的长正则查询分片行为，必要时显式调大或置 0；
4. 规则密集、对象存储调用费高的集群，可提前规划 memcached 资源并试点-ruler-storage.cache.backend=memcached（注意 local 后端不支持缓存）；
5. 依赖-ruler.poll-interval控制规则生效延迟的运维流程，需知晓新默认 10m，以及默认开启的 API 变更即时同步（可用-ruler.sync-rules-on-changes-enabled=false或租户级 override 关闭）；
6. 安全合规要求下，镜像版本选择 2.9.4 及以上。

完成上述核对后，2.9 带来的 store-gateway 内存下降、querier CPU 下降与对象存储调用下降通常可以“零配置改动”直接享受。

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