Mimir是Prometheus的后端存储层,专注接收远程写入、可靠存储与高效查询;需配合多个Prometheus实例使用,Grafana统一查询其网关,生产环境须用对象存储、组件分离、租户隔离及查询优化。
在 Linux 系统上部署 Mimir,是解决 Prometheus 单点存储瓶颈、实现大规模集群长期指标统一管理的关键一步。Mimir 不是 Prometheus 的替代品,而是它的“后端存储大脑”——它接收多个 Prometheus 实例的远程写入(remote_write),提供高可用、多租户、无限保留的查询能力,并天然支持全局视图聚合。
Mimir 本身不主动抓取指标,也不管理告警规则或服务发现。它专注三件事:接收写入、可靠存储、高效查询。因此实际架构中,你仍需部署多个 Prometheus 实例(例如按业务域或集群分片),每个实例配置 remote_write 指向 Mimir;而所有 Grafana 查询可统一指向 Mimir 的查询网关,实现跨集群数据融合。
典型链路为:
→ Prometheus A(写入) → Mimir
→ Prometheus B(写入) → Mimir
→ Grafana(查 Mimir)→ 展示全量指标
适合测试与中小规模起步,无需 Kubernetes 或复杂集群:
dpkg -i 安装/etc/mimir/config.yml,关键项包括:target: all(启用全部组件)server.http_listen_port: 9009(API 入口)blocks_storage.backend: filesystem(开发环境可用,生产务必换为 S3/MinIO)ingester.ring.kvstore.store: memberlist(单机用 memberlist,多节点需 etcd 或 consul)sudo chown -R $USER:$USER /var/lib/mimir
mimir -config.file=/etc/mimir/config.yml
prometheus.yml 中添加:remote_write:<br> - url: "http://mimir-host-ip:9009/api/v1/push"
http://mimir-host-ip:9009/status 查看 ingester 是否注册成功单机模式无法满足可靠性与扩展性要求。生产部署必须升级以下配置:
filesystem,改用对象存储(如 MinIO、AWS S3、Aliyun OSS)。Mimir 的 blocks 存储设计依赖强一致性对象存储,本地磁盘仅用于临时缓冲ingester、querier、frontend、compactor 拆分为独立进程或容器,按负载横向扩展。例如:增加 querier 实例提升并发查询能力,增加 ingester 提升写入吞吐write_relabel_configs 加标签区分来源,便于故障排查X-Scope-OrgID 实现多租户。例如让 dev/prom/prod 环境写入同一套 Mimir,但互不可见。需在 Prometheus remote_write 中设置 headers 字段frontend 组件做查询路由与缓存;调整 querier.query_ingesters_within 时间窗口避免重复扫描;对高频查询预计算 recording rules 并写回 Mimir若已使用 Prometheus Operator 管理集群内 Prometheus 实例,集成 Mimir 更加标准化:
Prometheus CR 中直接声明 spec.remoteWrite,URL 指向 Mimir Ingress 或 Service(如 http://mimir-gateway.mimir.svc.cluster.local/api/v1/push)spec.remoteWrite.writeRelabelConfigs 添加 prometheus 和 replica 标签,辅助 Mimir 去重grafana/mimir-distributed chart)或 Kustomize 部署 Mimir 各组件query-frontend 地址(如 http://mimir-query-frontend.mimir.svc.cluster.local),而非直连单个 querier这套架构已在多个百节点以上 Kubernetes 集群落地验证,支撑日均百亿级样本写入、TB 级历史数据秒级响应查询。核心不在组件数量,而在存储选型合理、租户边界清晰、写入路径冗余、查询路径缓存到位。