Налаштування Prometheus Long-term Storage через Cortex

Налаштування 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 компактує та downsamplить блоки.

Які компоненти 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 у сценаріях жорсткої ізоляції даних та реального часу. Для простих сценаріїв 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. Отримайте консультацію щодо вашого завдання — ми оцінимо проєкт і запропонуємо оптимальне рішення. Зв'яжіться з нами, щоб обговорити деталі.