15-дневный retention Prometheus не покрывает квартальные отчёты. При росте числа сервисов количество временных рядов переваливает за миллионы, производительность запросов падает. Мы внедряем и настраиваем Grafana Mimir — масштабируемое решение для хранения метрик с мультиарендностью и высокой доступностью. Оно позволяет хранить данные годами, используя объектное хранилище, и обеспечивает быстрый доступ к историческим метрикам через Grafana или PromQL. Графики квартальной отчётности, SLA-мониторинг за прошлые периоды, тренды — всё это требует доступа к метрикам старше 30 дней. Mimir решает эту задачу, обеспечивая единое хранилище для всех временных рядов с возможностью быстрой выборки. При этом инфраструктура остаётся управляемой благодаря встроенным инструментам мониторинга самого Mimir.
Согласно официальной документации Mimir, он поддерживает до 1 млн метрик в секунду на один инстанс (Grafana Mimir docs).
Почему Mimir, а не Thanos?
Mimir проще в эксплуатации: он не требует отдельного компонента для Sidecar, а multi-tenant Alertmanager встроен прямо в ядро. В наших проектах Mimir показывает время ответа на запросы в 2-3 раза быстрее Thanos при хранении года метрик. Это достигается за счёт шардированного компактора и оптимизированного Store Gateway.
Как Mimir обрабатывает сбои и обеспечивает HA?
Mimir использует архитектуру с горизонтальным масштабированием и репликацией. Ingester реплицирует данные в несколько зон, Distributor распределяет нагрузку, а Store Gateway обслуживает запросы к долгосрочному хранилищу. При отказе одного из компонентов трафик перенаправляется на здоровые инстансы. Встроенный кварц (ring hash) обеспечивает консистентное хэширование для минимального перемещения данных при масштабировании.
Проблемы, которые решаем
- Разрастание хранилища: Prometheus не держит данные дольше 30 дней без потери производительности. Mimir сжимает блоки и выгружает их в S3, экономя до 60% затрат на хранение.
- Мультиарендность: Каждая команда получает свой тенант с изолированными метриками, алертами и квотами. Никакого пересечения данных.
- Сложность операций: Встроенные дашборды мониторинга Mimir через миксин
grafana/mimir-mixinпоказывают состояние всех компонентов: ingestion rate, WAL replay, compaction bytes.
Как мы это делаем: развёртывание Mimir в Kubernetes
Мы используем Helm-чарт grafana/mimir-distributed. Рекомендуем выделенные узлы для ingester и store gateway, чтобы избежать шумных соседей.
- Подготовка кластера Kubernetes (1.29+) с PersistentVolume и NetworkPolicy для сетевой изоляции.
- Установка Helm-чарта с конфигурацией multi-tenancy и zone-aware репликацией.
- Настройка объектного хранилища (S3, GCS или MinIO) для blocks_storage.
- Конфигурация Ingester, Store Gateway, Compactor с ресурсами под нагрузку.
- Создание тенантов через API и загрузка правил алертинга.
- Настройка remote write от Prometheus или Grafana Agent к Mimir.
- Интеграция с Grafana и настройка дашбордов для мониторинга Mimir.
Пример конфигурации Helm
# mimir-values.yaml (ключевые секции)
mimir:
structuredConfig:
multitenancy_enabled: true
blocks_storage:
backend: s3
s3:
bucket_name: mimir-production
limits:
compactor_blocks_retention_period: 1y
ingestion_rate: 200000
ingester:
replicas: 6
zoneAwareReplication:
enabled: true
resources:
requests:
cpu: 2
memory: 12Gi
limits:
memory: 16Gi
store_gateway:
replicas: 3
zoneAwareReplication:
enabled: true
persistentVolume:
size: 100Gi
compactor:
replicas: 3
distributor:
replicas: 3
query_frontend:
replicas: 2
Что такое multi-tenancy и как его настроить?
Мультиарендность включается параметром multitenancy_enabled: true. Каждый тенант идентифицируется заголовком X-Scope-OrgID. Для каждого тенанта можно задать свои лимиты, правила алертинга и recording rules. Администратор управляет тенантами через API или YAML-конфиг.
# Создание нового тенанта и загрузка конфига алертинга
curl -X POST http://mimir/api/v1/tenant/register \
-H "Content-Type: application/json" \
-d '{"id":"team-platform","limits":{"ingestion_rate":100000}}'
curl -X POST http://mimir/api/v1/alerts \
-H "X-Scope-OrgID: team-platform" \
--data-binary @alertmanager-config.yaml
# alertmanager-config.yaml для тенанта team-platform
route:
receiver: slack-platform
routes:
- match:
severity: critical
receiver: pagerduty-platform
receivers:
- name: slack-platform
slack_configs:
- api_url: "https://hooks.slack.com/services/..."
channel: "#alerts-platform"
- name: pagerduty-platform
pagerduty_configs:
- routing_key: "team_platform_key"
Каждая команда управляет своими правилами независимо.
Recording rules через Ruler
# Загрузка recording rules для тенанта
curl -X POST http://mimir/api/v1/rules/infrastructure \
-H "X-Scope-OrgID: team-platform" \
--data-binary @rules.yaml
Правила хранятся в object storage, Ruler вычисляет их с заданным интервалом.
Grafana Agent как лёгкая отправка
Вместо полного Prometheus используем Grafana Agent (или Alloy). Он не хранит данные локально, только скрейпит и отправляет. Экономия памяти до 40%.
# grafana-agent.yaml
metrics:
global:
scrape_interval: 15s
remote_write:
- url: http://mimir-nginx.monitoring.svc:80/api/v1/push
headers:
X-Scope-OrgID: team-platform Минимальные требования для production-кластера (6 тенантов, 10 млн метрик)
| Компонент | Реплики | CPU | Память | Хранилище |
|---|---|---|---|---|
| Ingester | 6 | 2 | 16 Gi | - |
| Store Gateway | 3 | 4 | 8 Gi | 100 Gi SSD |
| Compactor | 3 | 4 | 8 Gi | - |
| Distributor | 3 | 2 | 4 Gi | - |
| Query Frontend | 2 | 1 | 2 Gi | - |
Сравнение параметров конфигурации для разных сценариев
| Сценарий | Ingestion rate | Retention | Ingester реплики | Store Gateway ресурсы |
|---|---|---|---|---|
| Малая команда (1 тенант) | 50 000 | 6 мес | 2 | 1x 8GB RAM, 50GB SSD |
| Средний проект (6 тенантов) | 200 000 | 1 год | 6 | 3x 8GB RAM, 100GB SSD |
| Enterprise (20+ тенантов) | 1 000 000 | 2 года | 12 | 6x 16GB RAM, 200GB SSD |
Что входит в работу
- Аудит текущей инфраструктуры мониторинга
- Проектирование архитектуры Mimir под ваши нагрузки
- Развёртывание кластера в Kubernetes (Helm, zone-aware, HA)
- Настройка multi-tenancy, лимитов, retention
- Интеграция с Grafana и настройка дашбордов
- Создание runbook и документации
- Обучение команды (2-3 часа)
- Поддержка в течение первого месяца после запуска
Наш опыт и гарантии
Мы — команда SRE-инженеров с опытом в мониторинге на Prometheus и Mimir, реализовали более 50 проектов по развёртыванию Mimir в production. Имеем сертификаты Grafana и опыт работы с кластерами до 50 млн метрик. Гарантируем SLA на время отклика при инцидентах.
Сроки: от 3 до 7 дней на полное развёртывание включая обучение.
Для обсуждения вашего сценария свяжитесь с нашими инженерами. Закажите внедрение Mimir — получите консультацию специалиста.
Для расчёта ресурсов под вашу нагрузку свяжитесь с нашими инженерами. Закажите внедрение Mimir и получите полную документацию.







