时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载本篇技术文章以 Mimir 仓库中的 v5.6 发布说明文档 为主体结合 mimir-distributed Helm chart 的 CHANGELOG 与当前 chart 的 values、模板源码完整解读 v5.6 这个版本的全部变更内容。读完本文你可以掌握 v5.6 引入的federation_frontend多集群联邦查询能力、alertmanager.serviceAccount独立服务账号的配置方式以及 rollout-operator 升级、track_sizes移除等变更的实际影响与迁移注意事项。版本概览v5.6 的兼容性与定位Grafana Mimir Helm chartmimir-distributedv5.6 与Grafana Mimir v2.15和Grafana Enterprise MetricsGEMv2.15兼容。官方定位上mimir-distributed是在 Kubernetes 上安装 Mimir 的推荐方式它以一组 Deployment/StatefulSet/Service/ConfigMap 等模板覆盖了 distributor、ingester、querier、query-frontend、store-gateway、compactor、ruler、alertmanager、gateway 等全部组件并附带 Memcached 缓存、Kafkaingest storage、MinIO对象存储等依赖。发布说明文档本身只列出高亮变更完整变更清单以 chart 的 CHANGELOG.md 为准。v5.6.0 对应的完整条目位于该文件的 5.6.0 小节中其中同时升级了 Mimir 与 GEM 至 2.15.0#10369、#10447这是本次版本最基础的配套更新。重要变更Important changes发布说明将以下两项单列为重要变更因为它们直接影响既有部署的升级行为。rollout-operator 升级至 0.20.0v5.6 将 chart 依赖的 rollout-operator 从旧版本更新到0.20.0CHANGELOG 中的 #9995 条目。rollout-operator 是 Mimir 集群滚动升级的核心协调者Mimir 各组件ingester、store-gateway、query-frontend 等在滚动更新时依赖它按 zone 分片、逐个替换实例从而保证升级期间的读写可用性。升级该组件意味着滚动升级策略、健康检查与 zone 感知逻辑都切换到 0.20.0 的行为升级 v5.6 时应当关注 rollout-operator 自身的发布说明与升级注意事项这一惯例在当前 main 分支的 CHANGELOG 中依然延续例如后续版本对 rollout-operator 0.38.x 的升级都单独标注了required actions。移除 Memcached 的 track_sizes 功能v5.6 移除了 Memcached 容器上的track_sizes特性#10032原因是该功能实际未被使用。这条变更在 CHANGELOG 中有完整的前史早期版本3.x 时代#5209曾启用track_sizes目的是帮助评估缓存效率5.6.0#10032将其从 chart 生成的 Memcached 启动参数中移除。对用户的实际影响很小因为track_sizes并非默认开启的核心能力。需要注意的是chart 目前仍然保留了通用的 memcached 扩展参数入口extraExtendedOptions见 values.yaml 中 chunks-cache / index-cache / metadata-cache 等缓存组件的配置注释其示例恰好写着# -- Add extended options for index-cache memcached container. The format is the same as for the memcached -o/--extend flag. # Example: # extraExtendedOptions: tls,modern,track_sizes extraExtendedOptions: 也就是说如果个别场景确实需要track_sizes仍可以通过extraExtendedOptions手动显式传入只是 chart 不再默认替你开启。新功能federation-frontend 多集群联邦查询v5.6 最重要的新功能CHANGELOG #9673是在 values 文件中增加了federation_frontend支持引入 GEM 的federation-frontend组件。它的能力是通过一个统一端点查询分布在多个 GEM 集群中的数据即cluster query federation集群查询联邦。结合 CHANGELOG 中紧随其后的一条增强#9734可以看清这两者的配合关系Addenabledfield for admin-api, compactor, distributor, gateway, ingester, querier, query-frontend and store-gateway components. This helps when deploying the GEM federation-frontend on its own.v5.6 为 admin-api、compactor、distributor、gateway、ingester、querier、query-frontend、store-gateway 这八个组件都新增了enabled开关其直接动机就是支持只部署 federation-frontend 本身的独立形态——联邦前端作为统一查询入口背后对接各个已存在的 GEM/Mimir 集群因此它自身不需要完整的一套写入/存储组件。配合每个组件的enabled字段你可以在 values 中裁掉用不到的部分只保留联邦查询所需的角色。从当前 main 分支的 chart 源码结构看federation_frontend这一顶层 values 小节在后续大版本演进中已不保留在 values.yaml 中仓库当前 chart 版本为 6.3.0-weekly且联邦查询能力在 Mimir 内核侧有独立实现如 pkg/querier/tenantfederation 下的租户联邦合并查询逻辑。因此本文以 v5.6 发布说明为准在 5.6 版本中联邦前端通过 values 的federation_frontend小节开启和配置如果你使用的是更新的 chart 版本请以该版本 CHANGELOG 与文档中对应机制的说明为准。功能增强详解Service 的 type 与 internalTrafficPolicy 可配置CHANGELOG #9619为所有组件的 Kubernetes Service 增加了type与internalTrafficPolicy两个可配置项并将所有ClusterIP类型 Service 的默认值设为internalTrafficPolicy: Cluster。在 values.yaml 中可以确认distributor、ingester、alertmanager、querier 等各组件的service小节均采用统一结构service: annotations: {} labels: {} # -- https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/ internalTrafficPolicy: Cluster type: ClusterIP extraPorts: []internalTrafficPolicy: Cluster是 Kubernetes Service 的默认语义即只有集群内的 Pod 流量会命中该 Service显式写出来并开放为 values 配置后运维方可以按需改为Local流量只转发到发起请求的本地节点上的 Pod常用于跨节点延迟敏感或需要保留客户端真实来源的场景。这一改动对既有安装无行为变化默认值即旧行为但为多区域/跨 zone 部署提供了配置空间。alertmanager 独立 ServiceAccount含 values 键名勘误发布说明称通过设置alertmanager.serviceAcount.create可以为 alertmanager 创建带有独立权限和授权的 service account。这里需要一处键名勘误文档中的serviceAcount是拼写笔误实际生效的 values 键名是alertmanager.serviceAccount.create这一点可以从 values.yaml 和模板代码确认# -- Dedicated service account for alertmanager pods. # If not set, the default service account defined at the begining of this file will be used. # This service account can be used even if the default one is not set. serviceAccount: create: false # -- Alertmanager specific service account name. Only takes effect when create is set to true; # otherwise the default service account is used. If not set and create is set to true, the default # name will be the default mimir service accounts name with the -alertmanager suffix. name: annotations: {} labels: {}各字段含义create: false是否创建该专属 ServiceAccount默认沿用 chart 全局的默认 service accountvalues.yaml 顶层的serviceAccount小节name仅当create: true时生效留空时默认取全局 Mimir ServiceAccount 名称 -alertmanager后缀annotations/labels附加到该 ServiceAccount 资源上的注解与标签便于接入集群内的 RBAC 治理或权限同步工具。源码层面的印证来自三个模板alertmanager-sa.yaml仅在{{- if .Values.alertmanager.serviceAccount.create }}成立时渲染 ServiceAccount 资源名称取自mimir.alertmanager.serviceAccountName命名模板alertmanager-dep.yaml 第 33 行Deployment 的serviceAccountName指向同一命名模板alertmanager-statefulset.yaml 第 80 行StatefulSetalertmanager 默认以 StatefulSet 运行同样引用该模板。值得注意的历史细节CHANGELOG 5.6.0 中有一条 BUGFIX#10016UpdateserviceAccountNamein thealertmanager-statefulsettemplate正是为了确保 StatefulSet 模板里的serviceAccountName与上述命名逻辑保持一致。因此使用 v5.6 的告警组件建议直接从该版本或其以上版本安装避免 StatefulSet 引用到错误的账号名。给这个独立 ServiceAccount 配好 RBAC 后alertmanager 组件即可与集群内其他组件的默认账号权限隔离开这在有最小权限要求的 K8s 环境中是标准做法。组件级enabled开关除前文提到的 federation-frontend 配合外这组enabled开关admin-api、compactor、distributor、gateway、ingester、querier、query-frontend、store-gateway让 chart 的角色裁剪成为一等公民你可以在 values 中直接关闭用不到的组件而不是通过把副本数设为 0 等变通手段。对于需要精简部署拓扑例如只读查询端、或联邦查询场景的安装来说这是 v5.6 提供的重要灵活性。Bug 修复CHANGELOG 5.6.0 小节CHANGELOG.md 的 5.6.0 段落共列出六条 BUGFIX逐条说明条目问题与修复#10029不再对通过*.extraArgs传入的容器命令行参数加引号。此前 values 中写的额外参数渲染后可能被带字面引号导致组件解析异常修复后extraArgs的值原样透传#10016修正 alertmanager StatefulSet 模板中的serviceAccountName与独立 ServiceAccount 命名逻辑对齐见上文#9774修正 Alertmanager 的 PVC 模板使其不再在 ArgoCD 中产生 diff——模板渲染结果与已应用清单一致GitOps 同步不再出现无意义漂移#9564修正fullnameOverride未能正确反映到生成清单的问题。使用该覆盖项改变 release 命名前缀的部署组件间 Service 名、资源名将正确跟随新前缀#9863extraObjects渲染时补一个换行使helm lint对该段 YAML 的解析不再报错便于把任意自定义对象如 CR随 chart 部署#9851为 Alertmanager 设置-server.http-idle-timeout避免 ruler 与 alertmanager 之间出现 EOF 错误该修复同时覆盖 zone-aware Alertmanager 部署其中#9851与 5.5.0 的一条修复#8192一脉相承HTTP 空闲连接超时未设置时长连接被代理或内核中途关闭会在日志中表现为 EOF给 ruler 推送告警/抓取状态造成干扰v5.6 把修复扩展到了 zone-aware 形态。从 v5.6 到当前 main 分支的对照阅读发布说明时有一个容易困惑的点仓库当前 main 分支的 chart 已演进到更新版本。对照 Chart.yaml 可以看到当前 main 上mimir-distributed的版本为6.3.0-weekly.415kubeVersion要求^1.32.0-0rollout-operator 依赖版本为0.52.0——远非 v5.6 时代的 0.20.0。这提醒我们两点适用前提本文所有配置键名、默认值均以 v5.6 发布说明及同期 CHANGELOG 条目为准如果你正运行 v5.6 的 chart请按 5.6.x 的 values schema 配置不要直接套用 main 分支的 values 文档v5.6 是一个承上启下的版本它奠定了组件级enabled裁剪、Service 流量策略可配置、组件独立 ServiceAccount 这三类能力这些能力在后续 6.x 大版本中继续保留并扩展例如后续版本为 ruler 等更多组件补充了serviceAccount配置、为 memcached 缓存提升了默认内存规格。参考文件发布说明原文docs/sources/helm-charts/mimir-distributed/release-notes/v5.6.mdchart 变更日志5.6.0 小节operations/helm/charts/mimir-distributed/CHANGELOG.mdchart values 定义operations/helm/charts/mimir-distributed/values.yamlalertmanager 独立 ServiceAccount 模板operations/helm/charts/mimir-distributed/templates/alertmanager/alertmanager-sa.yaml同目录下的 alertmanager-dep.yaml 与 alertmanager-statefulset.yamlserviceAccountName引用处chart 元信息与依赖版本operations/helm/charts/mimir-distributed/Chart.yaml赞分享时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载相关推荐Grafana Mimir Helm Chart 5.1 版本发布说明详解滚动更新策略、GOMAXPROCS 调优与 CVE 补丁链Grafana Mimir Helm Chart 5.1 版本发布说明详解滚动更新策略、GOMAXPROCS 调优与 CVE 补丁链 本文围绕 mimir d时序数据库后端数据存储可观测性云原生Grafana Mimir Helm Chart 5.2 版本发布说明PVC 保留策略、原生 Ingress 与关键修复详解Grafana Mimir Helm Chart 5.2 版本发布说明PVC 保留策略、原生 Ingress 与关键修复详解 本文基于 mimir distr时序数据库后端数据存储可观测性云原生Grafana Mimir Helm Chart v5.0 发布说明深度解读PSP 破坏性变更、Ruler 元数据缓存与滚动策略优化Grafana Mimir Helm Chart v5.0 发布说明深度解读PSP 破坏性变更、Ruler 元数据缓存与滚动策略优化 本文基于官方发布说明 v时序数据库后端数据存储可观测性云原生上一篇clangd语言服务器核心功能深度解析代码补全、跳转、诊断下一篇3 个月吃透软件工程师面试备考路线一套带你练到模拟面试的学习计划创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考