Настройка 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. Получите консультацию по вашей задаче — мы оценим проект и предложим оптимальное решение. Свяжитесь с нами, чтобы обсудить детали.







