Прямой ответ
Проблема, которую решает Mimir: Prometheus — локальное хранилище (один диск/нода — retention недели, горизонтального масштаба нет — «метрики за год» или «все кластеры в одном окне» — невозможны — метрики-основы); Mimir (Grafana, наследник Cortex/Thanos-идей) — глобальное хранилище: Prometheus'ы продолжают собирать (скрейпы/алерты — локально), но remote write шлют сэмплы в Mimir, который хранит их в объектном хранилище (S3/GCS/MinIO — блоки TSDB + индекс — дёшево и практически бесконечно — «метрики за 13 месяцев» — норма), а querying-слой (PromQL-совместимый — Grafana подключается к Mimir как к источнику — те же запросы, другой масштаб); архитектура (микросервисная — компоненты): distributor (приём remote write — валидация/хэшинг по tenant+series), ingester (накопление в памяти → блоки в объектное хранилище — репликация-подобная — replication factor 3 — нода не теряет), compactor (слияние блоков — downsampling (5m/1h-агрегаты для долгих периодов — гистограммы-агрегация — «год в деталях» не нужен — raw 15 дней, 5m — 90 дней, 1h — годы — стоимость), store-gateway/query-frontend (чтение/кэш/параллелизация запросов); multi-tenancy из коробки (tenant-id заголовок — команды/проекты изолированы — лимиты на tenant — «один сервис затопил хранилище» — квоты — ёмкость); когда нужен Mimir (честные критерии): метрик больше одного Prometheus (мульти-кластер/регионы — единое окно — k8s-парки), retention месяцы-годы (тренды/SLO-история (SLO — error budget за квартал — нужна история — дашборд), централизация (все команды в одну точку — лимиты/аудит — мониторинг-стек); когда НЕ нужен: один кластер, retention 15 дней хватает — локальный Prometheus проще/дешевле (Mimir — это 6+ компонентов эксплуатировать (helm-деплой — k8s-требование — «Mimir для одного Prometheus» — оверкилл — альтернативы:VictoriaMetrics-single (VM — проще для средних объёмов), Thanos (sidecar-модель — ближе к Prometheus — выбор — экосистемный контекст); Grafana Cloud Metrics = managed Mimir («не хотим эксплуатировать» — цена за сэмплы — buy-vs-build — аналогия выбора); подключение (минимум действий): Prometheus — remote_write: [url: ...] (+ basic auth/tenant — секреты), Grafana — новый datasource (Mimir/Prometheus-тип — URL query-frontend) — дашборды переключаются на источник (Grafana — запросы те же — recording rules — часть переезжает в Mimir- ruler-компонент).
Практика: ресурсы, лимиты, эксплуатация
Планирование Mimir-кластера (ёмкость-методика): входные параметры — active series (ряды — кардинальность — дизайн метрик ДО масштаба — «Mimir не лечит id-лейблы, хранит их дорого»), ingestion rate (сэмплы/с — ряды × скрейп-интервал), retention-политика (raw/downsample-сроки); ориентиры (из практических замеров — сверять с бенчмарком-дисциплиной на своём железе): ingester — RAM-ёмкий (head-блоки в памяти — series × RAM — главный потребитель — 1–2M рядов на ingester-реплику типично), distributor/query-frontend — CPU (приём/распараллеливание), объектное хранилище — стоимость доминирует на длинном retention (S3-цены — ГБ-месяцы — MinIO-self-hosted — железо вместо аренды — «своё дешевле на объёмах» — расчёт); лимиты tenant'ов обязательны (ingestion_rate/series-per-tenant — защита от кардинальность-взрывов — «сервис выкатил user_id-лейбл» — квота отбила, алерт сработал — инцидент локализован — алерты); мониторинг самого Mimir (internal-метрики — очередь ingester/ошибки compactor/latency запросов — Grafana-дашборды из поставки — «хранилище метрик без метрик» — ирония, не делать — healthcheck-культура); обновление Mimir — rolling по компонентам (стратегии — ingester-drain — graceful — данные в объектном хранилище — нода-потеря не страшна при RF=3 — failover-аналогия); бэкап — само объектное хранилище (3-2-1 — MinIO-репликация/S3-versioning — «метрики не критичны» — SLO-история/аудит говорят обратное — политика ретеншена — решение зафиксировать — ADR).
Практический сценарий: четыре Prometheus'а → единый Mimir за две недели
Контекст: 4 k8s-кластера (прод×2, staging, dev), каждый со своим Prometheus (retention 15 дней — локальные диски), боли: «сравнить прод-кластеры» — две вкладки Grafana вручную, «показать SLO за квартал» — данных нет (15 дней), один Prometheus на 12M рядов — 48 ГБ RAM (кардинальность-ревизия проведена — 12M — реальная потребность парка); решение — Mimir на k8s (helm-чарт — деплой — MinIO на 4 ТБ как S3 (MinIO — своё железо — расчёт: 12M рядов × 13 мес ≈ 1.8 ТБ с downsampling — запас ×2 — ёмкость); внедрение: (1) Mimir-кластер (distributor/ingester RF=3/compactor/store-gateway — ресурсы из замеров staging-прогона — методика — не из статей); (2) remote_write с 4 Prometheus'ов (tenant на кластер — лимиты per-tenant — параллельно с локальным хранением — миграция-осторожность — данные дублируются месяц); (3) сверка (Grafana-дашборд из Mimir против локального за неделю — расхождения <0.1% — remote write дропов нет — метрики самого Mimir (self-мониторинг)); (4) Grafana — datasource-свитч (Grafana — дашборды не правились — PromQL совместим — запросы — единственная правка: recording rules → Mimir ruler (глобальные агрегаты — recording); (5) алертинг остался на локальных Prometheus (Alertmanager-практика — алерты на свежих данных — локально надёжнее — Mimir ruler — фаза 2 — «алерты из глобального хранилища» — задержка ingestion учитывается — SLO-контекст); итоги: SLO-дашборды за квартал работают (дашборд), сравнение кластеров — один запрос, RAM прод-нод −35 ГБ (локальный retention сократили до 48ч — Mimir — источник правды — ресурсы), стоимость — MinIO-железо + 0.2 ставки на эксплуатацию против Grafana Cloud-счёта ~$900/мес — окупилось за 2 месяца (buy-vs-build — расчёт в ADR); находки: query-frontend кэш дал p95 дашбордов 4 с → 700 мс (повторные запросы — кэш-паттерны — аналогия), tenant-лимит поймал кардинальность-регресс в dev-кластере на первой неделе (кардинальность-процесс — квота как детектор); вывод: Mimir окупается при 2+ Prometheus'ах или retention-требовании — иначе локальный TSDB/VM-сингл честнее — выбор-контекст.
FAQ
Mimir против Thanos — что выбрать для долгосрочного хранения? Общая идея у обоих (Prometheus + объектное хранилище + глобальный запрос), различия в модели: Thanos — sidecar рядом с каждым Prometheus (конвертирует локальные блоки в object storage — «Prometheus остаётся главным» — компактор/стор глобальные), Mimir — remote write в независимый кластер («Prometheus — только сборщик» — приём/хранение — свои компоненты — Cortex-наследие); критерии: существующие Prometheus с локальными дисками и минимум изменений — Thanos sidecar, новый стек/мульти-тенантность/жёсткие лимиты — Mimir (tenancy/лимиты из коробки — кардинальность-защита), Grafana Cloud-путь — Mimir (совместимость с managed — миграция туда-обратно); Grafana Mimir 3.x частично совместим с Thanos-бакетами (миграция возможна — документация — «переезд Thanos→Mimir» — недели); оба требуют k8s-зрелости (helm/операторы) и объектного хранилища (MinIO/S3); честный третий путь — VictoriaMetrics-кластер (VM — проще в эксплуатации, меньше компонентов — «не Grafana-стек» — сравнение по своим критериям — выбор).
Как remote write влияет на сам Prometheus и что с потерями?
Overhead на Prometheus: очередь отправки в памяти (samples — буфер — при недоступности Mimir копится — queue_config тюнинг — RAM +10–20% типично), сеть (сэмплы ×2 — локально+remote — ёмкость-учёт), CPU минимальный (сжатие snappy); потери: при переполнении очереди — дропы (метрика prometheus_remote_storage_samples_dropped_total — алерт обязателен — алерты — «метрики молча теряются» — худший сценарий), при смерти Prometheus — неслитый буфер (минуты данных — критичные алерты дублировать локальным evaluation — сценарий выше — «алерты из Mimir» — задержка+потери — алертинг ближе к данным); гарантии: remote write — at-most-once из коробки (нет WAL-перечитки в старых версиях; Prometheus 2.x agent mode (wal-agent — конфигурация — только remote write с WAL-очередью на диске — переживает рестарт — «агент-режим» для k8s-парков — легче полного Prometheus); мониторинг пайплайна: лаг очереди/дропы/latency push — дашборд+алерты (метрики — телеметрия хранилища метрик — обязательна — Alloy-аналогия).
Как настроить downsampling и retention в Mimir?
Retention — на уровне хранилища/compactor (конфиг -compactor.retention / per-tenant retention-аргументы — raw 15–31 день типично — детали дорогие); downsampling: compactor генерирует 5m и 1h блоки (агрегаты — max/min/sum/count гистограммных бакетов — гистограммы — процентили из 1h-агрегатов менее точны, но тренды видны — «SLO за год» — из downsampled — достаточно — SLO-дашборд); политика-пример: raw 31 день (расследования инцидентов — детали — incident), 5m — 180 дней (квартальные тренды), 1h — 3 года (SLO-история/аудит — стоимость — 1h-блоки копеечны); Grafana-нюанс: max_source_resolution (авто по диапазону — «неделя» — raw, «год» — 1h — бесшовно для пользователя — Grafana-настройка); «хранить raw год» — возможно, но стоит (объектное хранилище ×N — MinIO-расчёт — вопрос «кто реально смотрит детали за март» — обычно никто — downsampling — 90% экономии при 99% полезности — кардинальность-культура).
Можно ли хранить в Mimir только часть метрик? Да, и это рекомендованный паттерн для стоимости: write_relabel_configs на Prometheus (конфигурация — фильтрация перед отправкой — «долгосрочно — только бизнес/SLO-метрики, infra-детали — локально 15 дней» — remote write-поток −60% — стоимость); критерии отбора: SLO-метрики/бизнес-показатели (SLO — тренды нужны), агрегаты recording rules (дёшево и полезны долго), детали инстансов/подов — локально (k8s-churn — ряды эфемерных подов в долгосрочном хранилище — мусор — кардинальность); антипаттерн: «шлём всё, потом разберёмся» — стоимость линейна — разбор не наступает — техдолг; ревизия отбора — ежеквартально (какие «долгие» метрики реально запрашивали — usage-анализ Mimir (метрики-usage — mimirtool — «неиспользуемое — выключить» — зависимости-ревизия — аналогия).
Источники: документация Grafana Mimir (architecture, get started), Prometheus remote storage — ссылки в шапке.