Prometheus本身是一款非常优秀的监控系统，但它的单机架构在数据量上来之后会暴露出明显的短板：本地TSDB存储容量有限、查询大时间范围数据时内存暴涨、实例重启后历史数据依赖快照恢复。Grafana Mimir正是为了解决这些问题而生，它兼容Prometheus的写入和查询接口，可以把数据放到对象存储中做长期保存，并支持水平扩展。本文以Ubuntu 22.04为例，详细介绍Mimir的配置过程。
Mimir的几种运行模式怎么选
Mimir支持三种部署模式：单体模式（monolithic）、只读扩写模式（read-write）和完整的微服务模式（microservices）。单体模式下所有组件跑在一个进程里，配置最简单，适合监控目标在一百万活跃序列以内、单机内存充足的场景。对于刚起步的团队，直接用单体模式配上本地文件系统或者MinIO作为对象存储，就能获得数据长期保留的能力。
当序列数量增长到几百万级别时，就需要考虑微服务模式了。Mimir的组件包括写入路径的distributor、ingester，查询路径的query-frontend、querier、query-scheduler，以及后台任务的compactor、store-gateway、ruler等。分布式模式下每个组件独立部署、独立扩容，比如ingester内存不够就加节点，查询慢就横向扩展querier，这种弹性是单机Prometheus完全做不到的。
本文后面以微服务模式为主线讲解，因为掌握了分布式配置，单体模式只是把配置合并到一个文件而已。理解每个组件的职责是配置的关键，否则出了问题很难定位。下面先从基础环境准备说起。
Ubuntu环境准备与二进制部署
首先创建专用用户和目录结构，避免用root跑服务。Mimir是Go编写的单二进制程序，部署非常简单：
sudo useradd --no-create-home --shell /bin/false mimir sudo mkdir -p /etc/mimir /var/lib/mimir sudo wget https://downloads.grafana.com/mimir/releases/mimir-linux-amd64 -O /usr/local/bin/mimir sudo chmod +x /usr/local/bin/mimir mimir --version
接下来准备对象存储。分布式模式下Mimir强依赖对象存储来保存数据块、规则和告警记录，生产环境推荐S3或者兼容S3协议的服务，测试环境可以用MinIO快速搭建：
wget https://dl.min.io/server/minio/release/linux-amd64/minio chmod +x minio sudo mv minio /usr/local/bin/ sudo mkdir -p /data/minio MINIO_ROOT_USER=mimiradmin MINIO_ROOT_PASSWORD=mimirsecret123 \ minio server /data/minio --address :9000 --console-address :9001
然后在MinIO中创建几个bucket，分别存放块数据、规则和告警，Mimir官方建议把这三类数据分开存放，便于生命周期管理和权限隔离：
mc alias set local http://127.0.0.1:9000 mimiradmin mimirsecret123 mc mb local/mimir-blocks mc mb local/mimir-rules mc mb local/mimir-alerts
核心配置文件详解
Mimir的配置通过YAML文件完成，下面给出一份分布式模式的核心配置示例，覆盖了对象存储、复制因子和租户认证几个关键点：
multitenancy_enabled: true
activity_tracker:
filepath: /var/lib/mimir/metrics-activity.log
blocks_storage:
backend: filesystem
filesystem:
dir: /var/lib/mimir/tsdb
bucket_store:
sync_dir: /var/lib/mimir/tsdb-sync
tsdb:
dir: /var/lib/mimir/tsdb
compactor:
data_dir: /var/lib/mimir/compactor
sharding_ring:
kvstore:
store: memberlist
ruler:
enable_api: true
rule_store:
backend: filesystem
ring:
kvstore:
store: memberlist
server:
http_listen_port: 9009
grpc_listen_port: 9095
ingester:
ring:
replication_factor: 3
kvstore:
store: memberlist
distributor:
ring:
kvstore:
store: memberlist这里有几个参数需要重点说明。replication_factor设置为3意味着每条时间序列会写入三个ingester节点，任何一台宕机都不会丢数据，前提是集群至少有三台机器。kvstore使用memberlist可以省去部署Consul或etcd的步骤，Mimir节点之间通过gossip协议自动发现彼此，小规模集群用这个方案最省事，大规模集群再考虑换Consul。
multitenancy_enabled开启后，请求头中必须携带X-Scope-OrgID才能读写数据，不同租户的数据完全隔离。如果是内部单一团队使用，也可以关闭多租户，请求时就不需要这个头了。
配置Systemd服务与Prometheus远程写入
每个Mimir组件可以用同一个二进制配合-target参数启动。创建一个Systemd服务模板，以ingester为例：
[Unit] Description=Mimir Ingester After=network.target [Service] User=mimir ExecStart=/usr/local/bin/mimir \ -config.file=/etc/mimir/mimir.yaml \ -target=ingester \ -server.http-listen-port=9009 Restart=always LimitNOFILE=65536 [Install] WantedBy=multi-user.target
把这份单元文件复制多份，改一下target值，就能分别启动distributor、querier、query-frontend、compactor、store-gateway等组件。全部启动后，用systemctl status确认各组件状态，然后配置Prometheus把数据远程写入Mimir。在Prometheus的配置文件中追加如下内容：
remote_write:
- url: http://distributor地址:9009/api/v1/push
headers:
X-Scope-OrgID: team-a
queue_config:
max_samples_per_send: 2000
capacity: 5000Prometheus本身的本地存储可以缩短保留时间到一两天，只作为缓冲层，长期数据全部落在Mimir管理的对象存储里。查询时Grafana数据源指向Mimir的query-frontend地址即可，PromQL语法完全兼容，原有的仪表盘无需任何改动。
高可用与常见问题排查
生产环境部署时，Prometheus建议也跑两份实例采集相同目标，同时远程写入同一套Mimir，Mimir会自动对重复样本去重。相比通过Consul做服务发现再选主的Thanos方案，这种双写架构简单得多，也更容易维护。distributor和query-frontend这类无状态组件前面可以挂Nginx或负载均衡器做多副本流量分发。
排查问题时先看各组件的/metrics和成员环状态。ingester环形状态不健康通常是防火墙拦截了gossip端口，确保节点间9095、7946等端口互通。如果查询报出块未找到的错误，多半是store-gateway的bucket索引同步延迟，检查对象存储的访问凭证和网络连通性。内存方面，ingester的内存占用大约是活跃序列数乘以每序列几KB，序列量突增时要留意OOM，必要时调低每个ingester的最大序列数让它自动分片。
整套体系搭建完成后，你就拥有了一个可以无限横向扩展、数据永不丢失的监控系统。后续还可以开启Mimir自带的限流配置，防止单个租户的异常基数把集群打挂，这比单机Prometheus时代的运维体验好太多了。
Ubuntu配置Mimir分布式Prometheus监控架构修改时间：2026-09-04 04:23:26