Cortex: архитектура, multi-tenant и режимы развёртывания
Cortex выступает как мощный слой распределённого мониторинга поверх Prometheus, обеспечивая горизонтальное масштабирование, изоляцию арендаторов и длительное хранение данных. В условиях больших платформ и множественных команд Cortex становится краеугольным камнем архитектуры наблюдаемости: он сохраняет концепцию Prometheus, но добавляет сложность и гибкость распределённых сервисов, удалённых хранилищ и многоарендной эксплуатации. Эта глава посвящена детальному рассмотрению архитектуры Cortex, механизмов multi-tenant и различным режимам развёртывания, а также практикам эксплуатации на масштабируемых платформах.
Cortex проектируется с учетом необходимости разделять данные разных арендаторов, обеспечивать доступ к историческим данным и сохранять высокую доступность при растущих нагрузках. В техническом плане речь идёт как о маршрутизации и кэшировании запросов, так и об управлении данными на уровне блочно-ориентированного хранения и индексов. В рамках курса рассматриваются конфигурации, которые позволяют разворачивать Cortex в продакшн-средах - как в виде набора микро-сервисов в Kubernetes, так и в виде упрощённых конфигураций All-in-One для тестирования и прототипирования.
Краткое содержание главы
-
Архитектура Cortex: блоки, потоки данных и принципы разделения по арендаторам.
-
Multi-tenant и изоляция данных: как Cortex обеспечивает разделение, квоты и безопасность между tenants.
-
Режимы развёртывания: All-in-One и микросервисная архитектура на Kubernetes, паттерны высокой доступности и эксплуатации.
-
Удалённая память и long-term storage: интеграция с объектными хранилищами и внешними механизмами длительного хранения.
-
Производительность, мониторинг и эксплуатационные практики: балансировка нагрузки, настройка лимитов, мониторинг состояния компонентов и планирование.
Архитектура Cortex: блоки и потоки данных
Cortex реализует многопользовательскую и долговременную модель мониторинга за счёт разделения по арендаторам и распределённого хранения. Основу составляют набор микросервисов, каждый из которых отвечает за конкретный этап обработки данных и запроса: ingestion, хранение, индексирование и обслуживание запросов. Взаимодействие между компонентами строится вокруг общих паттернов горизонтального масштабирования и устойчивости к сбоям.
Компоненты Cortex
-
Distributor - входной узел для записей от клиентов. Distributor получает временные ряды и маршрутизирует записи к ингестерам с учётомTenant-идентификаторов и хеш-кольца. Основная роль Distributor - обеспечить устойчивое распределение нагрузки и репликацию записей между ингестерами для надёжности.
-
Ingester - узел, который удерживает данные в памяти и периодически пишет их в блочное хранилище. Ingester отвечает за агрегирование и сохранение временных рядов в формате блоков, поддерживая схему восстановления после сбоев. Ингестеры используют кольцо (ring) для балансировки нагрузки и динамической ребалансировки при масштабировании.
-
Querier - компонент, обрабатывающий запросы к данным. Querier может читать данные как из памяти ingester’ов (для горячих данных), так и из длительного хранения (для исторических данных). В продвинутых конфигурациях к запросам может добавляться Frontend, который планирует и кеширует результаты, снижая задержки и повторную работу.
-
Store-Gateway - мост между блоками блочного хранилища и запросами. Store-Gateway организует чтение исторических блоков из внешнего хранилища и подает их в Querier. Это ключевой элемент при работе с long-term storage, позволяя держать в памяти только необходимый объём индексов.
-
Compactor - независимый сервис, отвечающий за компрессию и переработку блоков времени в более эффективные формы хранения, включая downsampling и удаление устаревших блоков в рамках политики хранения. Compactor обеспечивает баланс между точностью данных и затратами на хранение.
-
Ruler - сервис правил alerting и регламентов, работающий на tenants. Ruler вычисляет правила на уровне Cortex и триггерит алерты на основе данных Tenant.
-
Query-Frontend / Frontend - кеширование и планирование запросов, повышение эффективности чтения и ограничение параллельности. Эти компоненты особенно важны на платформах с высоким количеством параллельных запросов.
-
Authz/Identity и API-гейтинг - механизмы контроля доступа на уровне API, связанные с tenant-уровнем и политиками доступа. В продвинутых конфигурациях обеспечивают безопасность и соответствие регуляторным требованиям.
Потоки данных: ingestion и query
После подключения клиента, данные проходят через Distributor, который маршрутизирует записи к ингестерам согласно кольцу и tenant-макету. Ингестеры буферизуют данные в памяти и периодически пишут их в блочное хранилище как блоки. Такой подход обеспечивает быструю запись и гарантированную долговременную доступность данных.
Путь запроса начинается с Querier: запрос обрабатывается через Frontend (если включен) и далее направляется к Ingester’ам để hot data, и к Store-Gateway для доступа к историческим данным в блочном хранилище. В случае больших таймфреймов и необходимости агрегаций, Cortex может распараллеливать вычисления по нескольким ингестерам и блокам, объединяя их результаты на уровне Querier.
Индексация и поиск по данным осуществляются через разделяемые механизмы каталога блоков. Индексы хранятся отдельно и позволяют быстро определить, какие блоки соответствуют запросу конкретного tenants. Это критично для масштабирования: при возрастании retention и числа tenants индексная структура должна сохранять низкие задержки поиска.
Хранение и индексация
Блоки времени - это базовая единица Cortex. Блок содержит как сами временные ряды, так и метаданные, необходимые для поиска и фильтрации. Хранение блоков осуществляется в объектном хранилище (S3, GCS, Azure и т. д.), что обеспечивает повторяемость и долговременную доступность.
Индексы, необходимые для быстрого поиска по tenant’ам и диапазонам времени, существуют отдельно от блочного содержимого и могут быть закешированы на уровне Frontend/Querier. Такая архитектура разделения - индекса и данных - является ключевой для масштабирования: индекс имеет меньший объём, но требует быстрого доступа, тогда как данные занимают значительный объём и управляются через ленточные блоки.
Взаимодействие с внешними системами
Cortex поддерживает интеграцию с удалённым хранением, что позволяет держать данные в соответствии с требованиями долговременного хранения. В продвинутых конфигурациях Cortex может работать со всем спектром блочных хранилищ и обеспечивает управление политиками хранения, такими как ретеншн и downsampling. В рамках архитектуры присутствуют механизмы для чтения данных из внешних хранилищ во время выполнения запросов и эффективной маршрутизации по tenant’ам.
Multi-tenant и изоляция данных
Многопользовательская архитектура Cortex опирается на концепцию арендаторов (tenants). Каждый tenant имеет собственную видимую метрику и данные, изолированные на уровне хранения, индексов и конфигураций. Это достигается через изолированные пространства имен внутри Distributor, Ingester и Querier, а также через политики доступа на уровне API.
Архитектурные принципы изоляции
-
Логическая изоляция: данные арендаторов разделяются на уровне хэш-кольца и маршрутизации запросов. Tenant-идентификатор включается в маршрутизацию и в формирование блоков.
-
Изоляция хранения: блоки и индексы физически находятся в рамках конкретного tenant’а, и доступ к ним осуществляется с учётом tenant‑id. Это позволяет параллельно обслуживать множество арендаторов в пределах одного кластера без пересечения данных.
-
Контроль доступа: API-уровень обеспечивает аутентификацию и авторизацию по tenant’ам. В продвинутых сценариях применяются политики на уровне ролей и клиентских токенов, что препятствует неавторизованному доступу к данным.
-
Квоты и лимиты: для предотвращения перегрузки одного tenant’а и обеспечения справедливого распределения ресурсов используются лимиты по количеству записей, скорость записи и задержке запросов. Эти параметры настраиваются для каждого tenant в зависимости от его бизнес‑контекста.
Операционная изоляция и разделение ресурсов
-
Респонсивное масштабирование: рост числа tenants сопровождается горизонтальным масштабированием ingester’ов и количством реплик в каждом компоненте.
-
Применение тайминг‑политик: retention policies и downsampling применяются на уровне tenant’а и не мешают обработке соседних tenants.
-
Наблюдаемость арендаторов: метрики Cortex и собственные метрики tenants позволяют отслеживать использование ресурсов и качество обслуживания на уровне отдельного tenant.
Режимы развёртывания Cortex
Cortex поддерживает несколько режимов развёртывания, что определяет архитектуру, паттерны эксплуатации и требования к инфраструктуре. Вprod‑средах предпочтение обычно отдаётся микросервисной конфигурации на Kubernetes, однако для прототипирования или отдельных сценариев допускаются All-in-One конфигурации.
All-in-One (монолитный) режим
В All-in-One режим Cortex запускается как единый процесс, который объединяет несколько функций: ingestion, хранение и запросы. Такой подход упрощает развёртывание на начальном этапе, ускоряя тестирование гипотез и сокращая операционные риски. Однако он ограничивает горизонтальное масштабирование и может быть узким местом при росте нагрузки. Подобная конфигурация целесообразна для локальных лабораторий, демонстраций и интеграционных тестов, но редко применяется в крупных продакшн‑средах.
-
Преимущества: простота развёртывания, единая конфигурация, ускорение цикла разработки.
-
Ограничения: ограниченная масштабируемость, сложности в управлении ресурсами при росте tenancy, более тяжёлые обновления.
Микросервисная архитектура на Kubernetes
Наиболее распространённый и рекомендованный режим для production‑окружений. Разделение функциональности на Distributor, Ingester, Querier, Store-Gateway, Compactor, Ruler, Frontend позволяет масштабировать отдельные компоненты в зависимости от рабочих нагрузок и требованиям SLA.
-
Преимущества: независимая масштабируемость компонентов, упрощённое обновление и тестирование отдельных сервисов, улучшенная отказоустойчивость, более гибкие стратегии развертывания и миграции.
-
Рекомендованные паттерны: использование Helm‑чартов или операторов для конфигурации, горизонтальное масштабирование по требованию, настройка affinity/anti-affinity и топологии зоны доступности (AZ) для повышения устойчивости.
Эксплуатационные паттерны
-
High Availability: многократные экземпляры Distributor/Ingester в разных зонах доступности, репликация блочного хранилища и резервные планы на случай сбоев.
-
Upgrades и canary‑проверки: применение стратегий постепенного развёртывания, тестирование на стейдж‑окружении, мониторинг влияния на производительность.
-
Observability: детальная мониторинговая карта компонентов Cortex и зависимостей, включая задержки, пропускную способность и состояние хранения.
Удалённая память и long-term storage
Долгосрочное хранение и удалённая память являются ключевыми аспектами Cortex, особенно в контексте больших платформ и политик retention. Cortex строит хранение on-blocks в совместимых объектных хранилищах и обеспечивает доступ к этим блокам для выполнения запросов с длительным ретержн.
Интеграция с удалённой памятью
-
Объектное хранилище: данные блоков Cortex записываются в S3, GCS, Azure и другие совместимые хранилища. Блоки структурируются по временным интервалам и tenant’ам, что позволяет эффективно реплицировать и удалять данные.
-
Store-Gateway: сервис, который позволяет Querier’у получить доступ к данным в блочном хранилище. Store-Gateway использует индексы, чтобы минимизировать количество обращений к хранилищу и ускорить чтение histórico.
-
Индустриальные политики ретенции: Cortex поддерживает гибкие политики хранение, позволяя снижать точность данных с ростом времени и управлять downsampling для снижения затрат на хранение.
Сравнение с другими подходами к долговременному хранению
-
Cortex предоставляет свой собственный подход к длительному хранению данных через блоковую архитектуру и блочное хранение, что обеспечивает эффективность чтения из огромных объёмов и устойчивость ко сбоев. В рамках экосистемы Prometheus существуют альтернативы, например Thanos и Mimir, которые решают схожие задачи с другой реализационной моделью. Выбор между Cortex и аналогами зависит от требований к мульти‑тенантности, операционной сложности и специфике хранения.
-
В сценариях крупных платформ интеграция с удалённой памятью позволяет отделять вычислительную нагрузку от длительного хранения, переносить старые данные в хранилище, и сохранять быстрый доступ к актуальным данным через ingester и кэш Frontend.
Практические аспекты
-
Конфигурация хранения: выбор потока записи и чтения, параметры компрессии блоков и размер блоков.
-
Резервирование и доступность: конфигурации репликации между зонами доступности, хранение нескольких копий блоков и стратегия восстановления после сбоев.
-
Мониторинг долговременного хранения: показатели загрузки хранилища, задержки чтения/записи, частота обновления индексов и задержки в кэшах.
Производительность, мониторинг и эксплуатационные практики
Эффективное управление Cortex на больших платформах требует системного подхода к масштабированию, конфигурации и наблюдаемости. Основной принцип - разделение нагрузки между компонентами и tenant‑уровень контроля над ресурсами и запросами.
Масштабирование и конфигурация
-
Горизонтальное масштабирование: добавление реплик Distributor, Ingester и Querier в зависимости от интенсивности записей, числа tenants и объёма исторических запросов. В устойчивых конфигурациях применяются отказоустойчивые режимы репликации и балансировщики нагрузки.
-
Роль Frontend и кэширования: использование Query-Frontend для снижения параллелизма на уровне Querier и кеширования повторяющихся запросов. Это снижает задержки и экономит вычислительные ресурсы.
-
Настройка лимитов: per-tenant лимиты скорости записи, ширины диапазона запросов и времени ожидания, чтобы предотвратить «один tenant» от доминирования ресурсов.
-
Оптимизация хранения: правильный выбор размера блоков, стратегии компрессии и частоты компакции. Эти параметры напрямую влияют на скорость чтения и стоимость хранения.
Производительность запросов
-
Планирование запросов: разнесение обработчиков по tenant’ам и разделение задач распараллеливания на уровне Querier. Эффективное соединение между ingester’ами и store-gateway снижает задержки данных.
-
Состояние кэширования: Frontend/Query-Frontend держат кэш результатов, уменьшая повторные вычисления. В условиях больших загрузок это существенно снижает латентность.
-
Индексы и фильтрация: горизонтальная масштабируемость индексов и умелая фильтрация по тегам tenant’а сокращают объем сканируемых блоков и ускоряют поиск.
Эксплуатационные практики
-
Мониторинг и алерты: ключевые метрики Cortex включают задержки записи и чтения, пропускную способность по tenant, задержки в хранилище и количество активных ingester-реплик. Непрерывный мониторинг позволяет своевременно выявлять узкие места.
-
Обновления и миграции: планирование изменений конфигураций, тестирование новых версий в staging и постепенное развёртывание в production. В случаях крупных обновлений применяются canary‑паттерны и контроль целостности данных.
-
Обеспечение отказоустойчивости: использование multi‑AZ/multi‑region развёртываний, репликации и резервного копирования критически важных компонентов Cortex. Восстановление должно быть автоматизированным и воспроизводимым.
-
Безопасность: шифрование в пути и на покое, управление доступом на уровне tenant, журналирование операций и соответствие требованиям регуляторов. Эти аспекты особенно важны в средах с конфиденциальными метриками и соблюдением политик.
Key takeaways
-
Cortex предоставляет горизонтальное масштабирование и мульти‑тенантную изоляцию за счёт модульной архитектуры: Distributor, Ingester, Querier, Store-Gateway, Compactor, Ruler и Frontend.
-
Изоляция tenants достигается через tenant‑идентификатор, изолированные блоки и индексы, политики доступа и квоты на ресурсы.
-
Развертывание на Kubernetes с разделением функций по сервисам является рекомендуемой практикой для продакшна; All-in-One конфигурации подходят для тестирования и прототипирования.
-
Долговременное хранение интегрируется через блочное хранение в объектных хранилищах; Store-Gateway обеспечивает доступ к историческим данным для запросов.
-
Производительность достигается за счёт планирования запросов, кэширования, параллелизма и разумной политики хранения данных (retention, downsampling).
-
Эффективные операционные практики включают мониторинг, canary‑развертывания, резервирование и безопасность на уровне tenant.
-
Выбор подхода к долговременному хранению и архитектуре зависит от требований к мульти‑тенантности, доступности и стоимости хранения на крупных платформах.
-
Гибкость Cortex позволяет адаптировать конфигурацию под специфические сценарии между vendor-специализированными архитектурами и открытыми решениями на базе Prometheus.
-
В контексте экосистемы Prometheus Cortex выступает эффективным решением для мониторинга больших кластеров и поддержания долгосрочного хранения, при этом он требует грамотной архитектуры и процедур эксплуатации.
FAQ
- В чём основное различие между Cortex и Thanos/Mimir как решениями для долгосрочного хранения Prometheus?
- Cortex реализует масштабируемую структуру с блоками и многоарендной изоляцией, фокусируясь на ingestion‑потоках и запросах через распределённые сервисы. Thanos и Mimir тоже предлагают долговременное хранение и кросс‑кластерную агрегацию, но их архитектуры отличаются подходами к индексации и маршрутизации запросов. Выбор зависит от требований к мульти‑тенантности, простоты эксплуатации, поддержки конкретных хранилищ и зрелости инфраструктурных процессов в организации.
- Как Cortex обеспечивает изоляцию данных между арендаторами?
- Изоляция достигается через tenant‑идентификатор на уровне маршрутизации, отдельные блоки и индексы для каждого tenant, а также политикам доступа и квот. Это позволяет обслуживать множество арендаторов на одном кластере без пересечения данных и с предсказуемым потреблением ресурсов.
- Какие режимы развёртывания наиболее применимы к Cortex в продакшене?
- Наиболее распространённый режим - микросервисная архитектура на Kubernetes с независимыми сервисами Distributor, Ingester, Querier, Store-Gateway и др. Это обеспечивает гибкую масштабируемость, простоту обновлений и отказоустойчивость. All-in-One режим может использоваться для разработки, тестирования и быстрого прототипирования, но не рекомендован для продакшна в условиях больших нагрузок.
- Как Cortex реализует долговременное хранение данных?
- Cortex сохраняет данные в блочном формате в объектном хранилище (S3, GCS, Azure и др.). Store-Gateway обеспечивает доступ к блокам исторических данных; Compactor управляет компрессией и downsampling. Политики хранения позволяют задавать ретеншн и управлять затратами на хранение, сохраняя при этом необходимую точность для запросов.
- Какие ключевые показатели следует мониторить в Cortex для поддержания производительности?
- Пропускная способность записи и чтение (throughput), задержки на уровне ingester и querier, число активных инстансов, загрузка блочного хранилища, задержки чтения из хранилища и показатели кэширования. Также важны метрики доступа к tenant‑у, распределения нагрузки по кольцу и состояние репликаций.
- Какие паттерны эксплуатации помогают справляться с ростом числа арендаторов?
- Горизонтальное масштабирование отдельных компонентов, разделение функций по сервисам, настройка Tenant‑уровневых квот и лимитов, использование Frontend для кэширования и планирования запросов, мониторинг и автоматическое перераспределение нагрузки при добавлении новых tenants.
- Каковы лучшие практики обеспечения отказоустойчивости Cortex?
- Развертывание в нескольких AZ/Region, наличие реплик ингестеров и Distributor, резервирование блочного хранилища и регулярное тестирование восстановления. Важна автоматизация обновлений и мониторинг состояния во всех слоях архитектуры.
- Как подход Cortex влияет на безопасность и соответствие требованиям?
- Cortex может обеспечить шифрование в траектории и на покое для трафика API и взаимодействий с хранилищем, управление доступом на уровне tenant, аудит и журналы операций. При работе с чувствительными данными следует поддерживать строгие политики аутентификации, авторизации и резервного копирования.
- Можно ли сочетать Cortex с внешними решениями долговременного хранения?
- Да. Cortex поддерживает интеграцию со сторонними системами долговременного хранения через Store-Gateway и гибкие конфигурации хранения. В рамках экосистемы Prometheus возможны сценарии совместной эксплуатации с Thanos или Mimir, но это требует внимательного проектирования архитектуры и согласования политик хранения, чтобы избежать дублирования данных и конфликтов индексов.
- Какие типичные опасности и узкие места возникают при эксплуатации Cortex на больших платформах?
- Узкие места часто возникают из‑за нехватки ресурсов у ingester/querier при резком росте нагрузки, задержки доступа к удалённому хранилищу, неэффективной кэширования и неправильной настройки политики хранения. Регулярное тестирование, мониторинг и автоматизация масштабирования помогают минимизировать риски. Также важно отслеживать баланс арендаторов, чтобы не допустить перегрузки одного tenant’а в ущерб другим.
