Настройка Prometheus Long-term Storage через Cortex

Когда стандартного хранения метрик Prometheus перестаёт хватать, а история нужна на годы, мы настраиваем Cortex — горизонтально масштабируемый бэкенд с multi-tenancy и приёмом данных через remote_write в реальном времени. Наша команда реализует проект под ключ — от аудита до внедрения и последующей поддержки, обеспечивая надёжное долгосрочное хранение без срыва сроков.
Часто задаваемые вопросы

Настройка Prometheus Long-term Storage через Cortex

Мы часто получаем запросы от команд, чьи метрики Prometheus перестают помещаться в стандартный retention 15 суток. Приходится либо жертвовать историей, либо поднимать ещё один Prometheus и настраивать federation. Вместо этого мы предлагаем Cortex — горизонтально масштабируемый multi-tenant бэкенд, который принимает данные через remote_write в реальном времени. За 5 лет работы с распределёнными системами мы настроили Cortex для десятков проектов: от SaaS-платформ до внутренних мониторингов.

Как Cortex решает проблему долгосрочного хранения?

Cortex хранит все метрики в object storage (S3, GCS, MinIO) и позволяет задать retention в годах. Ingestion происходит мгновенно: данные отправляются через remote_write, минуя задержки Thanos Sidecar (~2 часа). В отличие от Thanos, Cortex не требует Sidecar для каждого Prometheus и даёт встроенную multi-tenancy. Для одной из наших платформ с 2 млн активных серий мы сократили задержку на получение свежих метрик с 2 часов до 30 секунд.

Когда Cortex, а не Thanos

Cortex предпочтительнее когда:

  • нужна строгая multi-tenancy изоляция (разные команды/клиенты не видят данные друг друга)
  • требуется горизонтальное масштабирование ingestion без ограничений одного Prometheus
  • данные должны быть доступны немедленно без ожидания upload
  • Prometheus может упасть — Cortex обеспечивает HA на стороне storage

Cortex сложнее в операционном плане: это распределённая система с 8+ отдельными компонентами. Но результат — единое хранилище с retention до 2 лет, SLO 99.9% и полное разделение данных.

Почему multi-tenancy важна для команд?

В больших организациях каждая команда видит только свои метрики. Cortex реализует изоляцию через заголовок X-Scope-OrgID. Мы настраивали это для SaaS-продукта, где 5 команд одновременно писали данные в один кластер Cortex, не зная чужих метрик. Гарантируем корректную настройку RBAC и аудит доступа.

Архитектура компонентов

Prometheus --remote_write--> Distributor --> Ingester (ring) --> Object Storage
Querier <--> Store Gateway (chunks) <-- Object Storage
Compactor
Query Frontend (cache layer)
Ruler (recording/alerting rules)
Alertmanager (alerts)

Distributor принимает remote_write, хэширует ряды по label-ам, распределяет по Ingester-ам через consistent hashing ring. Ingester держит данные в памяти, периодически сбрасывает в object storage. Запущен в кольце с репликацией: каждая серия записывается на 3 Ingester-а. Querier читает из Ingester (свежие данные) и Store Gateway (исторические). Compactor компактирует и downsamples блоки.

Какие компоненты Cortex самые ресурсоёмкие?

Ingester — самый тяжёлый: держит данные последних ~2 часов в памяти. На большом объёме (1M+ активных серий) каждый Ingester потребляет 8–16 GB RAM. Мы рекомендуем планировать 2–3 реплики Ingester для отказоустойчивости. Остальные компоненты (Distributor, Querier) менее требовательны — достаточно 2 vCPU и 4 GB RAM.

Конфигурация Prometheus remote_write

remote_write:
  - url: http://cortex-distributor:9009/api/prom/push
    queue_config:
      max_samples_per_send: 10000
      max_shards: 30
      capacity: 20000
    write_relabel_configs:
      - source_labels: [__name__]
        regex: "go_.*"
        action: drop
    headers:
      X-Scope-OrgID: "team-platform"

X-Scope-OrgID — обязательный заголовок для multi-tenant Cortex.

Минимальная конфигурация Cortex (single-process)

Для тестирования запускаем single-binary:

target: all
auth_enabled: true
server:
  http_listen_port: 9009
ingester:
  ring:
    kvstore:
      store: memberlist
    replication_factor: 3
blocks_storage:
  backend: s3
  s3:
    bucket_name: cortex-blocks
    region: eu-west-1
  tsdb:
    dir: /tmp/cortex/tsdb
compactor:
  data_dir: /tmp/cortex/compactor
store_gateway:
  sharding_enabled: true
  sharding_ring:
    replication_factor: 3
limits:
  ingestion_rate: 100000
  max_label_names_per_series: 30
  retention_period: 90d

Production: микросервисный режим

В production каждый компонент деплоится отдельно через Helm:

helm repo add cortex-helm https://cortexproject.github.io/cortex-helm-chart
helm install cortex cortex-helm/cortex --namespace monitoring -f values.yaml

Ключевые секции values.yaml:

config:
  auth_enabled: true
  blocks_storage:
    backend: s3
    s3:
      bucket_name: cortex-production
      endpoint: s3.amazonaws.com
  ingester:
    replicas: 6
    resources:
      requests:
        memory: 8Gi
        cpu: 2
  distributor:
    replicas: 3
  store_gateway:
    replicas: 3
    persistentVolume:
      size: 50Gi

Multi-tenancy в Grafana

Для разделения данных настраиваем Grafana datasource с заголовком tenant:

datasources:
  - name: Cortex-Team-Platform
    type: prometheus
    url: http://cortex-query-frontend:9009/api/prom
    jsonData:
      httpHeaderName1: "X-Scope-OrgID"
    secureJsonData:
      httpHeaderValue1: "team-platform"
  - name: Cortex-Team-Backend
    type: prometheus
    url: http://cortex-query-frontend:9009/api/prom
    jsonData:
      httpHeaderName1: "X-Scope-OrgID"
    secureJsonData:
      httpHeaderValue1: "team-backend"

Cortex vs Thanos: практическое сравнение

Аспект Cortex Thanos
Ingestion remote_write (real-time) Sidecar upload (~2h delay)
HA Встроенная через replication Через дублирование Prometheus
Multi-tenancy Нативная Требует внешних механизмов
Операционная сложность Высокая Средняя
Retention до 2 лет (настраивается) Ограничен размером bucket
Ресурсы На 30% больше CPU/RAM Экономнее

Cortex лучше Thanos в сценариях жёсткой изоляции данных и реальном времени. Для простых сценариев Thanos может быть дешевле.

Что входит в нашу работу по настройке Cortex

  • Аудит текущей инфраструктуры Prometheus
  • Проектирование архитектуры: выбор объектного хранилища, схемы tenant-ов, политик retention
  • Развёртывание Cortex в single-binary или микросервисном режиме
  • Интеграция с существующими Prometheus (remote_write) и Grafana
  • Настройка мониторинга самого Cortex (Grafana dashboards, алерты)
  • Документация по эксплуатации и runbook
  • Передача знаний команде заказчика

Сроки: от 3 до 10 дней в зависимости от сложности. Стоимость рассчитывается индивидуально.

Зачем выбирать нас?

5 лет опыта с Prometheus, Cortex и Thanos. Более 20 успешных проектов по развёртыванию observability-стеков. Гарантируем SLA 99.9% на кластер Cortex. Получите консультацию по вашей задаче — мы оценим проект и предложим оптимальное решение. Свяжитесь с нами, чтобы обсудить детали.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1393
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1368
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    815
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1139