Какие варианты долгосрочного хранения метрик для Prometheus ты знаешь?

Для долгосрочного хранения и анализа исторических метрик поверх Prometheus я использовал и оценивал несколько архитектур.

1. Prometheus Remote Write + Thanos Это наиболее распространенный стек в моих проектах. Prometheus настроен на отправку метрик (remote write) в Thanos Receiver, а данные хранятся в объектном хранилище (S3).

# prometheus.yml
remote_write:
  - url: "http://thanos-receive:19291/api/v1/receive"
    queue_config:
      capacity: 10000
      max_shards: 200

Преимущества: неограниченный ретеншен за счет S3, глобальный запрос по всем данным через Thanos Query, дедупликация. Я разворачивал Thanos Sidecar, Store, Compactor и Query для создания единой точки доступа к метрикам с нескольких инстансов Prometheus.

2. VictoriaMetrics Использовал его как более легковесную и производительную альтернативу, особенно для проектов с очень высокой кардинальностью метрик. VictoriaMetrics принимает данные напрямую через Prometheus remote write API и хранит их в своем эффективном формате. Его проще администрировать, чем Thanos.

3. Mimir (ранее Cortex) Применял в средах, где требовалось горизонтальное масштабирование и мультитенантность «из коробки». Mirim хорошо подходит для крупных организаций, где множество команд пишут метрики в единый кластер.

4. Увеличение retention локального TSDB Для небольших, не критичных к долгосрочным данным стендов я просто увеличивал параметр --storage.tsdb.retention.time до 30-60 дней. Это не заменяет объектное хранилище, но подходит для анализа трендов за пару месяцев без усложнения архитектуры.