Mimir

Mimir（Grafana Mimir）是 Grafana 生态中的指标后端，用于提供可横向扩展、高可用、多租户、长期保存的 Prometheus/OpenTelemetry metrics 存储和查询能力。

它通常不是直接替代应用里的 exporter，也不是负责抓取所有指标的唯一组件；它更常作为集中式远端存储，接收 Prometheus、OpenTelemetry Collector 或 Grafana Alloy 发来的指标数据。

核心问题

单个 Prometheus 很适合本地抓取、短期存储和告警，但在大规模环境里会遇到几类问题：

本地磁盘容量和保留期有限，长期趋势查询困难。
多集群、多地域、多团队需要统一查询和多租户隔离。
高可用 Prometheus 会产生重复样本，需要去重。
查询大量历史时间序列时，单机 Prometheus 容易受 CPU、内存和磁盘限制。

Mimir 解决的是“把 Prometheus 风格指标作为平台级服务长期存储和查询”的问题。它保留 Prometheus 数据模型和 PromQL 生态，同时把写入、存储、查询、规则和租户隔离拆成可扩展组件。

核心对象

对象	含义	工程关注点
Metric name	指标名，例如 `http_requests_total`	命名稳定、单位清楚
Label set	一组键值标签，例如 `service="api"`	Label Cardinality、聚合维度
Sample	某个时间点的数值	timestamp、value、乱序和重复
Time series	metric name + label set 唯一确定的一条序列	series 数量、保留期、查询范围
Tenant	多租户隔离单位	租户 ID、限流、权限、配额
Distributor	写入入口	校验、限流、租户识别、分片
Ingester / ingest storage	接收近期样本并形成可持久化数据	WAL、复制、内存、flush
Query frontend / Querier	查询入口和执行层	PromQL 查询拆分、缓存、并发
Ruler	执行 recording rule 和 alert rule	规则周期、告警一致性
Compactor / store gateway	管理长期 block 和历史查询	compaction、索引、对象存储成本

Prometheus 风格时间序列的身份可以近似写成：

series_id = metric_name + sorted(label_key = label_value)

metric_name 是指标名，label_key = label_value 是一组标签键值对，sorted(...) 表示标签集合按稳定顺序规范化后参与身份判断。只要任意一个标签值不同，就会形成新的时间序列。这不是哈希公式，而是解释“为什么标签基数会决定存储和查询成本”的工程模型。

核心机制

1. 指标先被采集，再远程写入 Mimir

常见路径是：

application / exporter
  -> Prometheus scrape or OpenTelemetry metrics
  -> Prometheus remote_write / Collector / Alloy
  -> Mimir distributor
  -> ingesters or ingest storage
  -> object storage blocks
  -> Grafana query

Prometheus 负责从目标抓取样本，再通过 remote write 把批量样本推送到 Mimir。OpenTelemetry metrics 也可以通过 Collector 或 Alloy 转换、处理后送入 Mimir。

2. 写入路径先校验租户和限制

Mimir 是多租户系统。写入请求通常必须携带租户 ID，认证和授权常由外部反向代理或网关处理。请求进入 distributor 后，会经历：

解析请求和租户。
校验限流、标签数量、样本大小和时间戳。
按 series 哈希分片，把样本路由到后续写入组件。
写入近期存储，并最终形成长期 TSDB block。

这个路径说明了一个关键边界：Mimir 可以限制坏数据进入系统，但它不能替代应用侧的指标命名治理。

3. 长期存储基于 Prometheus TSDB block 思路

Mimir 的长期存储格式基于 Prometheus TSDB。时间序列样本被组织成 block，block 中包含：

index：按 metric name 和 labels 找到 series。
chunks：保存一段时间内的压缩样本。
metadata：记录 block 时间范围、统计信息和标识。

对象存储保存这些 block，使历史数据可以跨节点、跨时间范围查询。查询时，Mimir 根据 PromQL、时间窗口和 label matcher 找到相关 block，再读取对应 chunks 计算结果。

4. 查询路径执行 PromQL 并返回时间序列结果

Grafana 通常把 PromQL 查询发给 Mimir：

Grafana panel
  -> Mimir query frontend
  -> queriers
  -> recent data + historical blocks
  -> vector / matrix result

PromQL 查询结果可能是瞬时向量、范围向量或标量。Mimir 的查询层会做切分、并行、缓存和结果合并，以支撑长时间窗口和高并发查询。

工程用途

Prometheus 长期存储：把多个 Prometheus 的 remote write 数据集中保存。
多集群统一指标平台：跨集群、跨地域、跨团队查询统一指标。
多租户监控平台：按团队、环境或客户隔离数据和配额。
集中式规则计算：用 ruler 执行 recording rule 和 alert rule，减少各 Prometheus 重复配置。
Grafana LGTM 指标后端：在 Grafana LGTM 中承担 metrics 存储和 PromQL 查询角色。

常见观察指标包括 active series、ingestion rate、remote write latency、dropped samples、query duration、ruler evaluation duration、compaction backlog、object storage error 和缓存命中率。

边界与常见坑

Mimir 不是采集协议本身：它接收 Prometheus remote write 或 OpenTelemetry metrics；目标发现、抓取和 instrumentation 仍要由 Prometheus、Alloy、Collector 或应用 SDK 完成。
Mimir 不会自动修复指标语义：单位混乱、counter/gauge 用错、label 命名不稳定，都会在长期存储中被放大。
高基数是主要成本风险：用户 ID、请求 ID、订单号、完整路径等进入 label，会让 series 数量暴涨，导致内存、索引和查询成本上升。
租户 ID 和鉴权不是细节：多租户系统必须清楚谁能写入哪个 tenant，谁能查询哪个 tenant；否则会出现数据混淆或越权查询。
remote write 成功不等于 dashboard 正常：中间还可能有延迟、丢样、去重、block compaction 和查询缓存问题。
Mimir 不等于 Prometheus 全部能力：Prometheus 的本地抓取、服务发现和部分本地告警职责仍可能保留；Mimir 更偏远端存储、横向扩展和集中查询。

Sean's Blog

探索