Зачем нужны Thanos, Mimir или VictoriaMetrics поверх обычного Prometheus и какую проблему они решают с точки зрения долгосрочного хранения?

Короткий ответ

Standalone Prometheus хранит данные локально на одном диске с ограниченным retention и без встроенной высокой доступности или глобального view между несколькими Prometheus-инстансами; такие системы добавляют долгосрочное хранение (через объектное хранилище S3/GCS), дедупликацию данных между репликами и единый запрос по множеству Prometheus сразу.

Как это работает подробнее

каждый Prometheus продолжает делать scrape локально, но дополнительно отправляет данные через remote_write в удалённое хранилище (Mimir, VictoriaMetrics) или использует Thanos Sidecar, который выгружает локальные TSDB-блоки в объектное хранилище. Дальше отдельный компонент (Thanos Querier, Mimir Query Frontend) объединяет данные из множества источников и отдаёт их в Grafana как единую точку запроса, включая исторические данные за месяцы/годы.

Пример кода

config.yamlКопировать

# Фрагмент конфигурации remote_write в Prometheus для отправки в Mimir
remote_write:
  - url: "http://mimir:9009/api/v1/push"
    queue_config:
      max_samples_per_send: 5000

Что использовать на практике

• Практика. такие решения нужны, когда требуется retention дольше, чем разумно держать на локальном диске одного Prometheus, либо нужен единый дашборд по метрикам из нескольких Prometheus (например, по регионам/кластерам), либо нужна отказоустойчивость самого хранилища метрик. Для небольшой системы с одним кластером и коротким retention эта сложность часто избыточна — выбор зависит от реальных требований к retention, масштабу и бюджету на эксплуатацию дополнительного компонента.
• Практика. После настройки запрос за данные старше локального retention Prometheus (например, за 6 месяцев) должен обслуживаться уже не локальным Prometheus, а Mimir — это можно проверить, временно остановив локальный Prometheus и убедившись, что исторические данные в Grafana всё равно доступны через query frontend Mimir.

Подводные камни

• Частые ошибки. внедрять Thanos/Mimir "на будущее" без текущей необходимости, добавляя операционную сложность (ещё один распределённый компонент, который сам нужно мониторить) без явной выгоды; не продумывать downsampling (постепенное снижение детализации старых данных) — без него долгосрочное хранение raw-данных становится дорогим как по месту, так и по скорости запросов за длинные периоды.