Экосистема и интеграции: Pushgateway, Thanos, Cortex, Grafana Loki

Мониторинг в крупной современной инфраструктуре строится на сочетании модульной экосистемы и продуманной архитектуры данных. В рамках этой главы рассматриваются ключевые элементы Prometheus-экосистемы, их роли, архитектурные особенности и типичные сценарии внедрения. Особое внимание уделяется тому, как интеграция Pushgateway, Thanos, Cortex и Grafana Loki дополняют базовую функциональность Prometheus, обеспечивая сбор метрик и логов, масштабируемость, мультиарендность и единое управление данными на протяжении горизонтов времени и пространств. Основной принцип - обеспечить согласованный доступ к данным, минимизировать задержки при запросах и гарантировать устойчивость к перегрузкам в условиях микро- и макрокомпонентной архитектуры.

Дальше мы последовательно разберём роль каждого компонента, общие паттерны интеграции и практические примеры конфигураций. В итоге читатель сможет выбрать оптимальную комбинацию инструментов под свои требования: от небольшого кластера до крупных многоуровневых сред с длинной ретенцией и мультиарендностью.

Краткое содержание главы
Архитектура и принципы интеграции между основными элементами Prometheus-экосистемы.
Pushgateway: сценарии использования, stitched-подход к данным и ограничения.
Thanos и Cortex: принципы масштабирования, хранение в объектном хранилище, мультиарендность и планирование запросов.
Grafana Loki: архитектура логов, интеграция с метриками и коррелированными запросами.
Практические паттерны интеграции: экспортёры, сервис-д discovery, конфигурации и кейсы внедрения.

Архитектура и принципы интеграции

Мониторинг в современной инфраструктуре строится на разделении задач между различными слоями: сбор метрик, долговременное хранение, агрегация запросов, работа с логами и визуализация. В этой части рассмотрены ключевые принципы, которые определяют выбор архитектурных решений и их взаимодействие.

Основной поток данных в Prometheus-экосистеме начинается с агентов-экспортеров и непосредственно Prometheus-инстансов, которые периодически «скрапят» метрики с конечных точек. Однако в условиях больших кластеров, миграций между средами и необходимости долгосрочного хранения стандартной функциональности Prometheus может оказаться недостаточно. Здесь на сцену выходят Thanos и Cortex, дополняющие архитектуру: они обеспечивают глобальный единый просмотр данных по нескольким кластерам, мультиарендность и хранение метрик за пределами локального диска. Логи же традиционно обрабатываются отдельно через Loki, который обеспечивает эффективное индексирование и поиск по журнальным записям, интегрируясь с теми же визуализаторами (например, Grafana).

Ключевые принципы включают:

Разделение областей ответственности: метрики - Prometheus/Thanos/Cortex, логи - Loki, визуализация - Grafana. Такой подход упрощает масштабирование, упрощает обеспечение SLA и уменьшает риски пересечения зон ответственности.
Эффективное хранение и допрос: Thanos и Cortex позволяют сохранять данные в объектном хранилище и отвечать на глобальные запросы без потери точности, включая дедупликацию и downsampling.
Мультиарендность и изоляция: Cortex обеспечивает изоляцию и многоарендность, что особенно важно в SaaS-моделях и крупных организациях, где разные команды работают в рамках общей инфраструктуры мониторинга.
Эффективная сборка логов и метрик: Loki дополняет Prometheus-метрики, давая возможность коррелировать логи с метриками без перегрузки поиска и индексации.

Практически это означает, что архитектор должен оценить требования к долговременной ретенции, частоте обновления, требованиям к изоляции данных, а также к потоку запросов и задержкам. В большинстве реализаций появляется следующий паттерн: локальные Prometheus-инстансы собирают метрики в рамках узла/кластера, Thanos/ Cortex обеспечивают глобальные запросы и долговременное хранение, Loki собирает логи (часто через Promtail) и связывает их с соответствующими метриками для тесной корреляции. Такой подход позволяет строить единый, масштабируемый и управляемый мониторинг.

Примерно это можно описать алгоритмически: локальная сборка -> агрегация и репликация -> долгосрочное хранение -> глобальные запросы и управление данными -> визуализация. Важной частью остаётся выбор конкретной реализации: Thanos или Cortex, а также необходимость поддержки Loki. Решения должны приниматься на уровне стратегии эксплуатации, а не по единовременному техническому предпочтению.

Pushgateway: задача, архитектура, сценарии использования

Pushgateway предназначен для поддержки короткоживущих и пакетных задач, которым невозможно или нецелесообразно реализовать обычный механизм скрапинга метрик со стороны Prometheus. Основной принцип работы прост: приложение или задача «публикуют» метрики в Pushgateway, после чего Prometheus периодически их считывает как обычную метрику через endpoint Pushgateway. Этот подход удобен в моделях CI/CD, пакетных обработках, миграциях и других сценариях, где длительное наличие процесса под управлением Prometheus невозможно или нецелесообразно.

Архитектурно Pushgateway представляет собой отдельный сервис, который хранит временные метрики, помеченные некоторыми лейблами, такими как job, instance и другие. В отличие от обычных целевых точек мониторинга, данные в Pushgateway могут быть более подвержены «шуму» и высоким кардинальности, поэтому его использование требует дисциплины в дизайне лейблов и периодическом очищении устаревших данных.

Типичные сценарии использования:

пакетные задачи и ETL-пайплайны, которые запускаются по расписанию и завершаются, не оставаясь в сети как постоянные сервисы.
батчи с гибко меняемой инстанс-идентификацией; Pushgateway позволяет «привязать» результаты запуска к соответствующему job-лейблу.
временные тестовые окружения, где важна быстрая инкапсуляция метрик без необходимости разворачивать полноценный агент сбора.

Рассмотрим ограничения и рекомендации:

Pushgateway не предназначен для длительного хранения или SLA-основы мониторинга. По возможности метрики должны скрапиться напрямую через обычные target-инстансы.
Кардинальность лейблов нужно держать под контролем. Не создавайте бесконечное множество записей по каждому запуску, иначе запросы к Prometheus станут неоправданно дорогими.
Разграничение доступа и безопасность: Pushgateway должен быть защищён внешними механизмами, поскольку он служит точкой входа данных. Для производственных сред применяются аутентификация и ограничение доступа.

Ниже приведён пример конфигурации и командной строки, иллюстрирующий базовые сценарии.

## Пример метрик в Pushgateway (формат text)
## TYPE batch_metric counter
batch_metric_total{job="batch_export",instance="batch-01"} 1

## Пример команды curl для публикации
curl --data-binary @metrics.txt http://pushgateway.example.org:9091/metrics/job/my_batch

## Пример конфигурации Prometheus для скрапинга Pushgateway
scrape_configs:
  - **job_name**: 'pushgateway'
    static_configs:
      - **targets**: ['pushgateway.example.org:9091']

Важно помнить, что Pushgateway предназначен как вспомогательный механизм, а не замена нормального принципа скрапинга: постоянные сервисы должны регистрироваться как обычные targets, тогда Prometheus будет работать наилучшим образом в рамках единого времени обновления.

Thanos и Cortex: горизонтальная масштабируемость и мультиарендность

Эволюция Prometheus в сторону больших и многоарендных систем потребовала решений по масштабированию и единообразному доступу к данным. В этом контексте Thanos и Cortex выступают как расширение и усиление базового функционала Prometheus, но реализованы с разными целями.

Thanos фокусируется на глобальном просмотре метрик, долговременном хранении вне локального диска, дедупликации и единых запросах по нескольким кластером. Архитектура Thanos строится вокруг Store API, Sidecar, Querier, Compactor, Rule и Object Store (S3/GCS/Azure). Основные преимущества - глобальный single pane of glass, единая ретенция и консистентный доступ, даже если данные физически распределены по нескольким странам и средам. Thanos обеспечивает дедупликацию на уровне запросов и позволяет строить глобальные алерты и правила на базе сосредоточенного набора данных.
Cortex ориентирован на мультиарендность и масштабирование в SaaS/enterprise-средах. Архитектура Cortex разделяет ввод данных (Distributor/Ingress) и хранение (Store) в сложном конвейере, где данные индексируются и разделяются поTenant-у, поддерживается мультитенантная модель с изоляцией. Cortex может функционировать как нод-услуга, обслуживающая множество Tenant'ов, и реализует горизонтальное масштабирование записи и чтения благодаря разделению по контекстам.

Типичные архитектурные паттерны интеграции:

Глобальный просмотр: Thanos позволяет объединять несколько кластеров в единый граф запросов. Это особенно полезно в организациях с несколькими кластерами Kubernetes, тестовыми и продакшн средами, где необходим единый источник truth.
Долговременное хранение: Thanos использует объектное хранилище для долгосрочного хранения метрик, что снимает требования к локальному объему и упрощает управление ретенцией и политиками.
Мультиарендность и изоляция: Cortex предоставляет механизмы мультиарендности на уровне метрик и обеспечивает плато для алертинга и дашбордов по tenant-идентификаторам.
Выбор между подходами: Thanos и Cortex могут использоваться по отдельности или совместно. Типичная рекомендация - Thanos для глобального просмотра и долговременного хранения, Cortex - когда нужна строгая мультиарендность и управляемый вход/вывод метрик в рамках SaaS или большого внутриишного сервиса.

Ниже приведено минимальное конфигурационное представление для примера интеграции Thanos с S3-хранилищем. Оно иллюстрирует ключевые элементы: объектное хранилище, Sidecar и Querier.

## Thanos Object Store (пример конфигурации для S3)
type: S3
config:
  bucket: "prometheus-thanos-bucket"
  region: "us-east-1"
  access_key_id: "YOUR-ACCESS-KEY"
  secret_access_key: "YOUR-SECRET-KEY"
  endpoint: "https://s3.amazonaws.com"

## Пример конфигурации Thanos Sidecar (часть к Prometheus)
## Это упрощённый пример; реальные конфигурации зависят от окружения
prometheus:
  url: http://prometheus-operated:9090
store:
  enabled: true
  object_store_config:

Cortex же может быть описан более абстрактно как система, состоящая из Distributor, Ingester, Querier, Ruler и Frontend, которая публикует данные через блоки хранения. В зависимости от требований к tenant-изоляции и задержке латентности, архитектура Cortex может строиться с различной степенью гориентированной на грузопереработку инфраструктуры. Для предприятий, которым критически необходима мультиарендность и гибкие границы доступа, Cortex предоставляет разнообразные модули и конфигурации, в том числе для аутентификации и авторизации на уровнеTenant.

Практическая рекомендация по выбору: если требуются единая ретенция, глобальные запросы и единая визуализация данных по нескольким кластерам - выбирайте Thanos в связке с Prometheus. Если же основная задача - мультиарендность и изоляция данных в рамках SaaS или крупных бизнес-додж - рассмотрите Cortex. В реальной среде возможен гибридный подход: Thanos как слой глобального доступа и долгосрочного хранения, Cortex - для сервисов внутри конкретного SaaS-окружения.

Grafana Loki: архитектура логов и интеграции с Prometheus

Loki - система для обработки логов, спроектированная с фокусом на совместно с Prometheus и Grafana. Основная концепция Loki - индексировать логи не по полному содержанию, а по лейблам (metadata) и хранить сами журнальные данные в ленивой, дешевой структуре. Это позволяет эффективно искать логи, коррелировать их с метриками и строить единые дашборды.

Архитектура Loki включает:

Ingesters/Distributors: получатели логов, временная зона записей и распределение по партициям.
Index и Chunk хранения: обработка и хранение логов в чанках с эффективной индексацией по лейблам.
Promtail (агент сбора): сбор логов с нод или контейнеров, лейблы, маршрутизация к Loki.
Grafana как визуализация и поиск: связь между метриками и логами в единых дашбордах.

Преимущества Loki в связке с Prometheus:

Логично-структурированная корреляция: по идентификаторам, времени и лейблам можно проводить быстрый поиск по логам, сопоставляя их с конкретной метрикой.
Эффективность хранения: хранение логов без полного индексирования каждого поля, что снижает стоимость хранения.
Простота масштабирования: совместная обработка логов и метрик в связке Loki+Prometheus упрощает управление и мониторинг.

Типичные сценарии использования:

Корреляция ошибок и задержек: например, при росте latency в очередь сообщений можно анализировать соответствующие логи и сопоставлять их с пиковой нагрузкой, отраженной в метриках.
Поиск инцидентов по временным диапазонам: Grafana предоставляет возможность фильтрации логов через Loki, используя аналогичные фильтры, как и в Prometheus, и синхронно картировать их на дашборды.

Ниже приведён пример Promtail-конфига для сбора логов из /var/log и отправки их в Loki.

server:
  http_listen_port: 9080
positions:
  filename: /tmp/positions.yaml
clients:
  - url: http://loki:3100/loki/api/v1/push
scrape_configs:
  - **job_name**: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          __path__: /var/log/*log

Этот конфигурационный пример демонстрирует базовую схему: Promtail считывает логи из файлов, добавляет метки и отправляет их в Loki. В реальной среде конфигурацию Promtail можно расширять для поддержки контейнерной среды (Docker/Kubernetes), обработки структурированных логов (JSON), фильтрации и маршрутизации к Loki в зависимости от уровней логирования и источников.

Интеграция Loki и Prometheus может осуществляться через визуализацию в Grafana, где пользователи могут запускать запросы одновременно по метрикам и логам, получая эффективную картину событий и зависимостей.

Интеграции, экспортёры и сервис-дискавери: практические паттерны

Эффективная интеграция между компонентами экосистемы достигается через грамотное применение сервис-дискавери, экспортёров и корректную конфигурацию скрапинга. В практике часто встречаются следующие паттерны:

Экспортёры: node_exporter, blackbox_exporter и специализированные экспортеры для приложений. Они позволяют адаптировать сбор метрик под конкретные решения и инфраструктуру, не переписывая код приложений.
Service discovery (SD): Kubernetes SD, static SD, Consul SD. SD позволяет динамически обнаруживать целевые точки мониторинга и автоматически обновлять конфигурацию Prometheus без ручного вмешательства.
relabel_configs: один из мощных инструментов** - трансформация и фильтрация меток на этапе конфигурации скрапинга для обеспечения консистентности данных и снижения числа уникальных серий.
Объектное хранение и репликация: в случае Thanos/Сortex, данные сохраняются в облачном хранилище или локальном объектном хранилище, что обеспечивает долговременное хранение и устойчивость к потере нод.

Типичное практическое решение - интеграция Kubernetes с Prometheus и Thanos для глобального доступа. В таком сценарии:

Prometheus внутри кластера собирает метрики локально.
Thanos Sidecar (или отдельный Thanos Store) отсылает данные в внешний объект-буфер (S3/GCS). Это обеспечивает долговременное хранение и единый глобальный просмотр.
Cortex используется там, где требуется мультиарендность и гибкие политики доступа к данным, особенно в SaaS и инфраструктурах со множеством команд.
Loki собирает логи через Promtail и связывает их с соответствующими метриками в Grafana.

Ниже приведён пример конфигурации Turndown Prometheus для кластера Kubernetes, который использует Kubernetes SD и relabeling для фильтрации и нормализации данных.

scrape_configs:
  - **job_name**: 'kubernetes-nodes'
    kubernetes_sd_configs:
      - **role**: node
    relabel_configs:
      - **source_labels**: [__address__]
        target_label: instance
      - **source_labels**: [__meta_kubernetes_node_label_kubernetes_io_hostname]
        target_label: hostname
      - **action**: drop
        regex: ''
      - **action**: labeldrop
        regex: __meta_kubernetes_node_label_.*

Ключевые вопросы: как обеспечить консистентность между метриками и логами, как обеспечить оптимальное использование долговременного хранения, какие индексы и политики TTL необходимы - эти вопросы определяют конфигурацию и масштабируемость системы.

Практические сценарии внедрения и выбор решений

При проектировании мониторинга с использованием Prometheus-экосистемы следует учитывать характер нагрузок, требования к задержкам и лимиты по хранению. В реальных проектах чаще всего встречаются следующие сценарии:

Многоуровневое хранение: локальные Prometheus-инстансы для быстрого реагирования, Thanos для глобального просмотра и долговременного хранения. Это минимизирует стоимость хранения и ускоряет доступ к данным за счет агрегации на границе.
Мультиарендная среда: Cortex становится необходимым инструментом, если нужно аккуратно разделять данные между командами, обеспечивать изоляцию и соблюдать правила доступа. В таком случае архитектура строится на разделении по Tenant и использовании Frontend/Distributor для равномерной нагрузки.
Логи и метрики в связке: Loki и Prometheus позволяют строить кросс-линковку между событиями и их метриками, что критично для анализа производительности и инцидентов. Прямой доступ к логам через Grafana совместно с метриками ускоряет диагностику.
Безопасность и операционное управление: интеграция аутентификации и авторизации, управление доступом к данным, аудит изменений конфигураций и регулярный пересмотр политик retention и privacy.

В практическом плане рекомендуется:

Определить требования к ретенции и SLAs перед выбором Thanos vs Cortex. Для глобального просмотра долгосрочных данных предпочтительнее Thanos, для мультиарендной среды - Cortex.
Реализовать единые политики идентификации источников (ленбы и префиксы) для метрик и логов, чтобы упростить поиск и корреляцию.
Внедрить инфраструктуру обслуживания и мониторинга самой мониторинговой системы: health checks, readiness probes, мониторинг использования хранилища и запросов, автоматическую перезагрузку подов, динамическое масштабирование.

Key takeaways

Разделение ролей между метриками (Prometheus/Thanos/Cortex) и логами (Loki) является основой устойчивой архитектуры мониторинга.
Thanos обеспечивает глобальные запросы и долговременное хранение, Cortex - мультиарендность и изоляцию, что особенно важно в службах SaaS.
Pushgateway удобен для пакетных задач, но требует дисциплины в дизайне лейблов и политик очистки.
Loki, интегрируясь с Promtail, обеспечивает эффективное хранение и быстрый поиск логов, что облегчает корреляцию с метриками в Grafana.
Сертифицированные паттерны сервис-дискавери и relabeling позволяют минимизировать сложность конфигураций и повысить устойчивость к изменяемым инфраструктурным условиям.
Выбор между Thanos и Cortex должен основываться на требованиях к глобальному доступу к данным, мультиарендности и управлению хранением. В ряде кейсов целесообразна гибридная архитектура.
Экспортеры и корректные конфигурации SD обеспечивают оптимальный охват мониторинга без перегрузки сети и обработки данных.

FAQ

Какой выбор между Thanos и Cortex в современных условиях?

Thanos эффективен для глобального просмотра, объединения данных из нескольких кластеров и долговременного хранения. Cortex - оптимален, когда требуется строгая мультиарендность и управляемая изоляция tenant-данных. В случаях, когда необходима и та, и другая функция, возможно сочетание: Thanos для глобального доступа и Cortex для изоляции отдельных сервисов. Важным критерием является требование к SLA, стоимости инфраструктуры и сложности управления.

Можно ли заменить Loki обычными журналами в Prometheus?

Prometheus не хранит журнальные данные. Loki добавляет слой для обработки логов с эффективной корреляцией. В некоторых сценариях можно обойтись без Loki, если логи не критичны для анализа событий и корреляций. Однако для инцидентов и детального анализа, включая корреляцию с метриками и дашбордами Grafana, Loki существенно упрощает выявление причин.

Какие практические ограничения у Pushgateway?

Pushgateway удобен для пакетных задач, но избегайте использования его для постоянных сервисов, где стабильная метрика должна собираться через scraping. Кардинальность лейблов и частые падения Pushgateway могут привести к перегрузке и ухудшению качества мониторинга. Всегда применяйте чистые шаблоны лейблов и внедрите очистку устаревших данных.

Как организовать мультиарендность в Cortex?

Cortex поддерживает мультиарендность на уровне Tenant. Включение правильной аутентификации и авторизации, а также корректная маршрутизация запросов к данным Tenant-у - ключ к безопасной эксплуатации. В архитектуре нужно предусмотреть Frontend, Distributor/Ingester и Store для каждого арендатора, минимизируя перекрестные запросы и обеспечивая изоляцию.

Какие паттерны сервис-дискавери особенно полезны?

Kubernetes SD является базовым и эффективным в большинстве облачных и on-premises окружений. Также применимы Consul SD и static SD в более статических инфраструктурах. Важно применять relabel_configs для нормализации и подсветки важных лейблов, избегая чрезмерной теплоты и увеличения числа целевых точек.

Какие каналы для интеграции метрик и логов наиболее эффективны?

Связывать логи и метрики через единый интерфейс Grafana - наиболее эффективный путь. Используйте Promtail для логов и Prometheus/Thanos/Cortex для метрик. Важно поддерживать корреляцию по временным меткам и общим лейблам, таким как namespace, job, service, и идентификаторы инцидентов.

Какие опасности бывают при масштабировании?

Основные риски - высокие задержки запросов, перегрузка сети из-за большого объема метрик, избыточное хранение, сложности конфигурации и повышенная сложность эксплуатации. Чтобы снизить риски, применяйте downsampling, retention политик, мониторинг самого мониторинга и автоматизацию перезапуска подов.

Как обеспечить безопасность в Prometheus-экосистеме?

Рекомендуется закрывать внешние точки доступа, использовать TLS, ограничивать доступ к конфигурациям и секретам, внедрять RBAC на уровне Grafana и сервиса просмотра метрик, а также регулярно обновлять версии компонентов и следить за сообщениями об уязвимостях.

Что важно учесть при миграции между кластерами?

Планируйте миграцию поэтапно: сначала перенесите длительное хранение, затем объединяйте запросы через Thanos, протестируйте индексацию и дедупликацию, после чего переходите к мультиарендности. Резервные копии конфигураций и единая политика ретенции помогут избежать потерь данных.

Какие метрики и сигналы индикатора качества мониторинга стоит отслеживать?

Важные сигналы включают задержки запросов к Thanos/Prometheus, уровень дедупликации, доступность хранилища, скорость инжестинга логов в Loki, время на сборку и агрегацию дашбордов Grafana, а также метрики эксплуатации экспортёров. Регулярный аудит конфигураций и SLA по каждому компоненту поддерживает устойчивость всей системы мониторинга.

← Предыдущая статья

CI/CD и инфраструктура как код для мониторинга: конфигурации как код, пайплайны

Следующая статья →

Реальные кейсы внедрения: отраслевые сценарии для разных организаций