★ FEATURED ARTICLE 时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载导读本文以 Grafana Mimir v3.0 release notes 为骨架系统讲解该版本的两大核心里程碑基于 Kafka 的ingest storage摄取存储架构与成为默认查询引擎的Mimir Query EngineMQE同时完整覆盖 3.0 引入的重要变更、实验性功能与已知问题。读完本文你将理解 3.0 的架构演进动机、MQE 相比 Prometheus 引擎的流式执行原理掌握启用 Kafka 摄取存储、切换/回退查询引擎、开启集群校验等实战配置方法并能在升级前完成针对性的兼容性检查。一、Grafana Mimir 3.0 概览Grafana Labs 于 3.0 版本正式发布 Grafana Mimir以下行文简称 Mimir其定位依然是为 Prometheus 提供水平可扩展、高可用、多租户、长期存储的时序数据库参见仓库根目录 README.md 中的项目描述。本版的主要亮点可概括为三条主线引入 ingest storage 架构通过 Kafka 将读写路径解耦读写可独立伸缩MQE 全面转正Mimir Query Engine 成为 querier 与 query-frontend 的默认查询引擎大规模清理删除若干已废弃的实验性标志与部署模式并对默认行为做了一系列收敛。对于完整的变更列表官方建议直接查阅仓库根目录的 CHANGELOG.md其中## 3.0.0一节自 CHANGELOG.md 第 922 行 起逐条记录了本次发布的所有 CHANGE / FEATURE / ENHANCEMENT / BUGFIX。二、核心特性一Ingest storage 架构2.1 为什么引入 Kafka 摄取层在 Mimir 3.0 之前的经典架构classic architecture中ingester 同时承担写入与查询两条链路既要接收并暂存样本又要响应 querier 的查询请求。在大查询负载下读写双方会争抢 ingester 的 CPU、内存与网络资源产生相互拖累。ingest storage 架构的核心思路是在写入端与查询端之间引入 Kafka 作为异步缓冲层。写入路径变为distributor将租户数据写入 Kafka 主题ingester作为 Kafka 消费者持续拉取分区数据并落盘到 TSDB查询时 querier 只与 ingester以及 store-gateway交互不再触碰写入链路。由此读与写可以独立水平伸缩写扩容只需增加 Kafka 分区与消费能力读扩容只需增加 querier/ingester 副本。官方 release notes 明确其收益包括提升写入稳定性、改善查询性能、增强大规模部署的运维灵活性。重要前提在 Mimir 3.0 中经典架构依然受支持classic architecture is still supported用户不必强制迁移。同时官方在 Kafka 后端配置文档 中明确从 3.0 起ingest storage 是运行 Mimir 的首选preferred且稳定stable的架构。2.2 如何启用 Kafka 摄取存储Kafka 后端需要显式开启且所有 Mimir 组件都必须统一启用否则组件间数据流会不一致。核心配置标志如下出处configure-kafka-backend.md配置标志含义-ingest-storage.enabledtrue显式启用 ingest storage 架构所有组件都要设置-ingest-storage.kafka.addresshost:port[,host:port...]Kafka seed broker 地址可配置逗号分隔的多个地址以提升引导可用性-ingest-storage.kafka.topicname用于摄取数据的 Kafka 主题名-ingest-storage.kafka.auto-create-topic-default-partitionsnumber主题不存在时消费者/生产者首次访问会自动创建该数字为自动创建时的分区数至少应等于一个 zone 内的 ingester 数量另外官方推荐配合调整-distributor.remote-timeout5s把默认的 remote write 超时调大因为写入 Kafka尤其是 Kafka 兼容后端可能比直写 ingester 更慢。从源码看该特性在配置结构上集中定义于 pkg/mimir/mimir.go 的IngestStorage字段第 130 行类型为ingest.Config并在 mimir.go 第 207 行 注册标志、第 295 行 做合法性校验。校验逻辑中还包含一条关键约束只有启用了 ingest storage才允许关闭 ingester 的 Push gRPC 方法见 mimir.go 第 351-352 行因为启用摄取存储后 ingester 只应通过 Kafka 接收数据——这也印证了该架构读写分离的设计初衷。2.3 不同 Kafka 后端的适配Mimir 3.0 支持对接多种 Kafka 兼容实现各自需要的额外配置如下Apache Kafka 与 Confluent KafkaMimir 默认的-ingest-storage.kafka.producer-max-record-size-bytes约为15.2 MB而两者默认message.max.bytes仅为1 MB。需要在 broker 配置如server.properties中调大message.max.bytes16000000也可按主题粒度调整bin/kafka-configs.sh --bootstrap-server host:port \ --alter --entity-type topics --entity-name topic-name \ --add-config max.message.bytes16000000Warpstream-ingest-storage.kafka.use-compressed-bytes-as-fetch-max-bytesfalse2.4 Kafka 认证与传输安全Mimir 3.0 的 Kafka 客户端支持丰富的认证方式绝大多数基于 SASL 框架PLAIN / SCRAM-SHA-256 / SCRAM-SHA-512用户名 密码认证对应标志-ingest-storage.kafka.sasl-mechanism、-ingest-storage.kafka.sasl-username、-ingest-storage.kafka.sasl-password。默认机制为PLAIN为向后兼容PLAIN 机制下不配用户名与密码即视为禁用 SASL。OAUTHBEAREROAuth 2.0 Bearer Token静态配置可用-ingest-storage.kafka.sasl-oauthbearer-token、-ingest-storage.kafka.sasl-oauthbearer-zid、-ingest-storage.kafka.sasl-oauthbearer-extensions可选动态刷新可走 JSON 配置文件或 HTTP 回调。AWS_MSK_IAM面向 Amazon MSK 的 IAM 认证静态配置用-ingest-storage.kafka.sasl-msk-iam-access-key、-ingest-storage.kafka.sasl-msk-iam-secret-key、-ingest-storage.kafka.sasl-msk-iam-session-token可选、-ingest-storage.kafka.sasl-msk-iam-user-agent可选。动态刷新两种方式配置文件-ingest-storage.kafka.sasl-oauthbearer|msk-iam-file-pathJSON 形状分别对应{token: ..., zid: ..., extensions: {...}}与{AccessKey: ..., SecretKey: ..., SessionToken: ..., UserAgent: ...}仅 token/AccessKeySecretKey 为必填。每次需要重新认证时会重新读取该文件Mimir 不会主动通知刷新时机凭据生命周期与文件更新需自行在带外处理。HTTP 回调-ingest-storage.kafka.sasl-mechanism-http-socket-path指定 Unix domain socket 路径超时可用-ingest-storage.kafka.sasl-mechanism-http-socket-timeout配置默认10s。服务端收到对/的 HTTP GET 后需返回 200 及上述 JSON 对象。相比静态配置与文件方式HTTP 回调无需带外管理凭据生命周期凭据也不必持久化按需动态下发。传输加密方面-ingest-storage.kafka.tls-enabledtrue开启 TLS需要 mTLS 时追加-ingest-storage.kafka.tls-ca-pathCA 证书缺省用系统根 CA、-ingest-storage.kafka.tls-cert-path与-ingest-storage.kafka.tls-key-path两者须成对配置可选-ingest-storage.kafka.tls-server-name覆盖服务端证书预期名称、-ingest-storage.kafka.tls-insecure-skip-verify仅测试用、以及-ingest-storage.kafka.tls-cipher-suites、-ingest-storage.kafka.tls-min-version等进阶项。2.5 摄取存储架构下的行为差异结合仓库源码与文档启用 ingest storage 后部分机制的行为会发生变化升级运维时需注意Push gRPC 方法可关闭ingester 只从 Kafka 接收数据时可关闭-ingester.push-grpc-method-enabled见 pkg/ingester/ingester.go 第 247 行 的注释说明owned series 追踪方式改变在摄取存储架构中token 被分配给partition而非 ingester序列的复制由 Kafka 分区机制承载因此经典架构所需的 owned series 配置步骤可以省略见 configure-owned-series.md部分限流器不适用Push 请求的 circuit breaker 与 reactive limiter 在摄取存储架构中不可用分别见 about-ingester-circuit-breakers.md 与 about-reactive-limiters.mdshuffle sharding 转向分区维度写读路径的分区级 shuffle sharding 见 configure-shuffle-sharding/index.md。三、核心特性二Mimir Query EngineMQE成为默认引擎3.1 MQE 是什么Mimir Query EngineMQE是 Mimir 自研的 PromQL 查询引擎位于 pkg/streamingpromql/其设计说明见 pkg/streamingpromql/README.md。它的目标是在安全、高性能、低成本的前提下求值涉及数百万条序列的查询核心手段是流式streaming执行关键思路是不一次性把所有输入序列载入内存而是在需要时才按需流式读入。官方 release notes 给出的量化收益是相比 Prometheus 引擎峰值内存占用最高可降低 92%从而在大负载下获得更快、更稳的查询性能与更低资源消耗。其原理可借助一个具体例子说明原文来自 pkg/streamingpromql/README.md查询sum by (environment) (some_metric{clustercluster-1})。Prometheus 引擎先把选择器命中的所有序列的全部样本一次性载入内存再逐组求和峰值时同时持有全部输入序列样本与全部输出序列样本。MQE先执行选择器、收集全部序列的标签据此预先计算出sum by (environment)的全部可能输出序列environment 每个取值一条然后逐条读入输入序列、累加到对应输出序列峰值时只持有一条输入序列的样本与所有输出序列的样本。更复杂的查询可以逐级流式传递如max(sum by (environment) (...))每当一个sum分组结果完整产出立即交给max更新当前最大值详见 README 中的 mermaid 查询计划图。在 MQE 内部每条查询被表示为一系列串联的 operator如 instant vector selector、sum 聚合、max 聚合它们满足InstantVectorOperator接口通过SeriesMetadata()与NextSeries()两个核心方法逐系列产出数据。3.2 默认引擎与切换方式从2.17开始MQE 已是 querier 的默认引擎见 v2.17 release notes到3.0query-frontend 也默认使用 MQECHANGELOG.md 第 935 行即 MQE 成为所有 querier 与 query-frontend 的默认引擎。MQE 与 Prometheus 引擎的取值常量定义于 pkg/querier/querier.go 第 94-95 行PrometheusEngine prometheus、MimirEngine mimir切换引擎的标志在 querier.go 第 115 行 注册-querier.query-enginemimir|prometheus默认值为mimir。若想继续使用 Prometheus 引擎按 release notes 明确说明设置-querier.query-engineprometheus校验逻辑见 querier.go 第 126-128 行传入其他值会直接报unknown PromQL engine错误引擎实际构建分支在 querier.go 第 211-221 行 附近prometheus走promql.NewEngine(...)mimir走streamingpromql.NewEngine(...)。3.3 引擎回退机制MQE 当前仍非 100% 覆盖所有 PromQL 语法因此 Mimir 提供了回退机制-querier.enable-query-engine-fallback默认true。当 MQE 遇到不支持的查询时自动回退到 Prometheus 引擎执行注册于 querier.go 第 116 行。这也是 MQE 全面转正后能保持稳定兼容的关键保障。3.4 MQE 相关增强3.0 新增从 CHANGELOG.md 的 3.0.0 记录看本版对 MQE 的强化集中在直方图查询优化query-frontend.rewrite-histogram-queries新增 MQE AST 优化 pass重写直方图查询为更高效的执行顺序CHANGELOG.md 第 955 行查询重写优化query-frontend.rewrite-propagate-matchers在二元运算间复制相关 label matcherCHANGELOG.md 第 954 行查询计划改进querier 与 query-frontend 支持在前端进行查询计划query planning并分发计划片段给 querier 执行CHANGELOG.md 第 963 行公共子表达式消除CSE扩展至即时查询的 range vector 表达式CHANGELOG.md 第 977 行新增实验性 PromQL 函数支持mad_over_time、ts_of_min_over_time等CHANGELOG.md 第 968-970 行查询前端 MQE 相关标志querier.mimir-query-engine.enable-prune-toggles取代旧的query-frontend.prune-queriesCHANGELOG.md 第 933 行。四、其他关键增强3.0 除两大主线外还包含以下值得关注的变化HA tracker 默认后端切换为 memberlistdistributor 的 HA tracker 默认使用 memberlist 而非 etcd/consuletcd 与 consul 虽仍支持但已标记废弃CHANGELOG.md 第 948、1008 行Store-gateway 动态复制因子默认值提高-store-gateway.dynamic-replication.multiple默认改为5以增强近期 block 的复制CHANGELOG.md 第 940 行UTF-8 标签/指标名支持扩展cardinality 相关 API 端点与label_join、label_replace、count_values等函数支持 UTF-8 命名CHANGELOG.md 第 927-928 行Ruler 远程评估支持使用 Prometheus 兼容 HTTP 端点做远程规则评估remote evaluation mode可用于多实例联邦CHANGELOG.md 第 952 行缓存与依赖清理移除 Redis 缓存后端支持CHANGELOG.md 第 929 行成本归因cost attribution每用户标签基数默认上限降至 2000CHANGELOG.md 第 941 行。五、重要变更与升级注意事项升级到 3.0 前务必逐一核对下列行为变化release notes 的 Important changes 一节ingest storage 架构引入数据流在组件间发生变化读写分离启用前需先备好 Kafka 后端与分区规划。MQE 成为默认引擎若不希望使用 MQE必须显式设置-querier.query-engineprometheus注意 2.17 中-query-frontend.query-engine是实验性标志3.0 前端已默认 MQE。实验性功能移除read-write 部署模式被移除CHANGELOG.md 第 939 行对应 2.17 中 mixin 的 read-write 模式也早已移除query-frontend 的-query-frontend.downstream-url代理任意 Prometheus 后端被移除CHANGELOG.md 第 931 行实验性 instant query splitting 被移除CHANGELOG.md 第 932 行废弃的-ingester.stream-chunks-when-using-blocks等标志被清理CHANGELOG.md 第 937 行。配置清理与结构调整query-scheduler 成为必选组件-querier.frontend-address、-querier.max-outstanding-requests-per-tenant、-query-frontend.querier-forget-delay被移除不再支持前端内嵌 query-schedulerCHANGELOG.md 第 936 行流式查询成为强制路径-querier.streaming-chunks-per-ingester-buffer-size等必须为非零值CHANGELOG.md 第 938 行Redis 缓存后端不再可用CHANGELOG.md 第 929 行移除非标准 HTTP 529 限流状态码选项统一用 429CHANGELOG.md 第 943 行。六、实验性功能Experimental features3.0 中以下功能仍处于实验阶段官方建议谨慎使用并及时反馈问题实验性功能启用方式与说明Prometheus Remote-Write 2.0 协议通过 HTTPContent-Type: application/x-protobuf; protoio.prometheus.write.v2.Request识别见 pkg/distributor/push.go 第 273-304 行 的isRemoteWrite2实现未设置 Content-Type 或 proto 为prometheus.WriteRequest时按 v1 处理PromQL duration 表达式允许在 range 或 offset 值中做简单算术例如rate(http_requests_total[5m * 2])HTTP 集群校验默认关闭通过-server.cluster-validation.*系列标志启用见下Native OTLP delta 指标摄取默认关闭-distributor.otel-native-delta-ingestion启用后直接存储原始 delta 采样值禁用时拒绝 delta 指标见 pkg/util/validation/limits.go 第 429 行6.1 HTTP 集群校验配置详解集群校验cluster validation用于让 HTTP/gRPC 服务端校验请求是否来自预期集群在集群迁移等场景下防止跨集群误写。配置模型定义于 dskit 的 vendor/github.com/grafana/dskit/clusterutil/cluster_validation_config.go关键配置项-server.cluster-validation.label主集群标签label-server.cluster-validation.additional-labels迁移期间可额外接受的多余标签需先设置主 label见该文件第 49-53 行的校验-server.cluster-validation.http.enabled启用 HTTP 校验默认关闭-server.cluster-validation.http.soft-validation软校验模式仅可伴随 enabled 开启-server.cluster-validation.http.exclude-paths、-server.cluster-validation.http.exclude-user-agents从校验中排除的路径 / User-Agent-server.cluster-validation.grpc.enabled等gRPC 侧对应配置。客户端侧gRPC 调用方也可配置自己的集群标签例如 pkg/frontend/config.go 第 49 行 的-query-frontend.client-cluster-validation.label以及 pkg/mimir/mimir.go 第 901 行 的公共配置前缀-common.client-cluster-validation.*。完整的各类客户端前缀可见 pkg/mimir/mimir_config_test.go 第 90-93 行 中的测试用例。七、Bug fixes 与 Helm chart 说明官方 release notes 明确完整的 bug 修复列表请查阅 CHANGELOG.md 的 3.0.0 记录。其中值得注意的修复类型包括Remote-Write 2.0 相关修复零时间序列请求导致的 nil 指针 panicCHANGELOG.md 第 879 行、修复WriteResponseStats统计差异CHANGELOG.md 第 1014 行、修复 RW2 请求中 Unknown 类型 metric metadata 被静默丢弃CHANGELOG.md 第 1022 行MQE 查询正确性修复label_join错误信息引用源标签名错误CHANGELOG.md 第 1041 行摄取存储修复 fetcher 从 Kafka 请求超限字节数等问题CHANGELOG.md 第 1025 行一般稳定性querier 对同时间戳样本确定性合并CHANGELOG.md 第 1016 行、store-gateway 潜在 goroutine 泄漏CHANGELOG.md 第 1017 行等。此外需要特别注意Grafana Mimir 的 Helm chart 是独立发布、独立版本化的因此 3.0 的 release notes 不包含 Helm chart 的变更明细请查阅独立的 Helm chart 文档仓库内的 Helm chart 位于 operations/helm/charts/。八、从源码继续深入如果希望进一步验证本文涉及的技术细节建议直接在仓库中查看以下位置摄取存储配置pkg/mimir/mimir.go 第 130、207、295、351 行配置挂载与校验、docs/sources/mimir/configure/configure-kafka-backend.md完整 Kafka 配置指南MQE 实现与原理pkg/streamingpromql/README.md流式执行原理与查询计划示例、pkg/querier/querier.go 第 94-128、199-221 行引擎选择与回退RW2 协议识别pkg/distributor/push.go 第 273-304 行OTLP delta 摄取pkg/util/validation/limits.go 第 429 行集群校验实现vendor/github.com/grafana/dskit/clusterutil/cluster_validation_config.go完整变更清单CHANGELOG.md 第 922 行起3.0.0 条目。总结Grafana Mimir 3.0 是一次架构级的版本升级Kafka 摄取存储把读写路径彻底解耦MQE 以流式执行成为默认查询引擎并显著压低峰值内存同时通过移除 read-write 模式、废弃 Redis 缓存、强制 query-scheduler 等方式收敛了历史包袱。对于运维团队升级前请重点核对 Kafka 后端可用性、MQE 回退策略、query-scheduler 部署以及各类已移除标志的清理对于开发与调优场景则可从-ingest-storage.*与-querier.query-engine两组配置入手结合 CHANGELOG.md 逐步验证 3.0 的各项行为变化。赞分享时序数据库后端数据存储可观测性云原生【免费下载链接】mimirGrafana Mimir provides horizontally scalable, highly available, multi-tenant, long-term storage for Prometheus.项目地址https://gitcode.com/gh_mirrors/mimir/mimir点击查看免费下载相关推荐Grafana Mimir 查询引擎MQEFuzz 模糊测试指南Grafana Mimir 查询引擎MQEFuzz 模糊测试指南 导读 本文围绕 Grafana Mimir 仓库中 Mimir Query Engine时序数据库后端数据存储可观测性云原生Grafana Mimir 2.15 发布要点深度解读S2 gRPC 压缩、PromQL 3.0 兼容性升级与实验性 Mimir 查询引擎Grafana Mimir 2.15 发布要点深度解读S2 gRPC 压缩、PromQL 3.0 兼容性升级与实验性 Mimir 查询引擎 本文基于 Graf时序数据库后端数据存储可观测性云原生Grafana Mimir v2.2 版本发布解读乱序样本摄入、存储前缀、升级要点与 Bug 修复Grafana Mimir v2.2 版本发布解读乱序样本摄入、存储前缀、升级要点与 Bug 修复 本文基于 Grafana Mimir 官方发布说明 v2时序数据库后端数据存储可观测性云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
系统简介)
