Модуль доступен только в Deckhouse Enterprise Edition.

Архитектура Deckhouse Observability Platform

Deckhouse Observability Platform имеет микросервисную архитектуру, в которой вся система разделена на множество компонентов, выполняющих определённую задачу. Эти компоненты могут быть сгруппированы по их назначению.

Ниже приведена принципиальная схема с группами компонентов:

image

Далее будет предоставлена подробная информация о каждой из групп.

UI + Control-plane

Группа компонентов UI + Control-plane отвечает за управление платформой через пользовательский интерфейс и координацию всех внутренних процессов.

В состав этой группы входят следующие основные компоненты:

image

  • Backend — stateless-компонент, реализующий функциональность личного кабинета пользователя. В бэкенде пользователи могут управлять хранилищем, просматривать дашборды, графики, алерты и триггеры.
  • Config Validator — stateless-компонент, осуществляющий валидацию различных конфигураций и PromQL-выражений в триггерах.
  • Usage Collector — stateless-компонент, собирающий метрики с различных компонентов системы и записывающий их в Metric Storage для дальнейшего отображения статистики.
  • Reconciler — stateless-компонент, занимающийся настройкой всех внутренних компонентов Deckhouse Kubernetes Platform.
  • Grafana — инструмент для визуализации данных и отображения дашбордов, интегрированный в бэкенд системы.
  • Auth — stateless-компонент, осуществляющий аутентификацию всех API-запросов на основании API-токенов. В случае успешной аутентификации запросы направляются в соответствующие компоненты Deckhouse Kubernetes Platform.
  • PostgreSQL — база данных, используемая для хранения конфигурационных данных и других метаданных.

Notification Components

Группа компонентов Notification Components отвечает за выполнение правил, обработку алертов и отправку уведомлений.

В состав этой группы входят следующие основные компоненты:

image

  • Ruler — stateless-компонент, выполняющий PromQL-запросы и сохраняющий результат в виде новой метрики. Также Ruler проверяет триггеры, выполняя PromQL-запросы, и, если выполняется условие срабатывания, передаёт алерт в Alertgate.
  • Alertgate — компонент, отвечающий за приём информации о сработавших триггерах. Он сохраняет текущее состояние триггеров в базу данных (PostgreSQL) и отправляет их в Alertmanager. Для некоторых триггеров Alertgate также выполняет дополнительную проверку причин резолвации: исчезновение метрики или успешная резолвация. В случае резолвации продолжает отправлять алерты.
  • Alertmanager — stateful-компонент, принимающий оповещения от Ruler. Он производит их группировку и дедупликацию, а также отправляет уведомления в соответствии с настроенными каналами доставки, такими как email, Telegram, webhook и другие.

Metrics Storage

Группа компонентов Metrics Storage выполняет следующие ключевые функции: приём метрик, их преобразование в блоки, отправка в долгосрочное хранилище (Object Storage) и чтение данных — как текущих, так и из долгосрочного хранилища.

В состав этой группы входят следующие основные компоненты:

image

  • Metrics Collector — отвечает за приём метрик от opAgent, конвертацию запросов и отправку их в Distributor. Также отвечает за приём исторических данных от opAgent (историческими считаются данные, которые не попадают в текущий активный блок):
    • приём метрик — получает метрики от opAgent, преобразует запросы в необходимый формат и передаёт данные в Distributor;
    • обработка исторических данных — принимает и обрабатывает исторические данные.
  • Nginx — stateless-компонент, используемый для маршрутизации и балансировки нагрузки:
    • маршрутизация запросов — направляет запросы к соответствующим компонентам;
    • балансировка нагрузки — распределяет нагрузку между компонентами для обеспечения высокой производительности и отказоустойчивости.
  • Distributor — stateless-компонент, принимающий метрики и выполняющий их проверку:
    • проверка метрик — проверяет правильность и соответствие метрик установленным ограничениям для данного tenant;
    • шардирование метрик — делит метрики на пакеты с учетом правил шардирования;
    • ограничение скорости — ограничивает скорость входящих данных на основе лимитов проекта;
    • репликация — отправляет копии пакетов на несколько ingester параллельно в соответствии с коэффициентом репликации.
  • Ingester — stateful-компонент, отвечающий за временное хранение и подготовку метрик перед их долговременным хранением:
    • запись в журнал (WAL) — записывает все входящие метрики на диск;
    • формирование блоков — формирует двухчасовые блоки метрик в памяти;
    • хранение блоков — записывает блоки на локальный диск и затем отправляет их в долговременное хранилище (удаляет блоки с локального диска спустя 6 часов).
  • Query-frontend — stateless-компонент, ускоряющий запросы на чтение метрик:
    • разделение запросов — разбивает range-запросы на подзапросы для параллельного выполнения;
    • кэширование — кэширует результаты запросов для ускорения последующих запросов;
    • планирование запросов — добавляет запросы в очередь и передает их Querier для выполнения.
  • Querier — stateless-компонент, отвечающий за выполнение запросов на чтение метрик:
    • извлечение данных — извлекает метрики из Block Storage и ingester;
    • выполнение запросов — выполняет выражения PromQL для получения необходимых данных.
  • Store Gateway — stateful-компонент, обеспечивающий доступ к данным в долговременном хранилище:
    • индексирование блоков — хранит в памяти индекс всех блоков, определяя, какие данные нужны для каждого запроса;
    • извлечение данных — позволяет извлекать только необходимые данные из Block Storage для снижения потребления ресурсов.
  • Compactor — stateless-компонент, оптимизирующий хранение блоков метрик:
    • сжатие блоков — объединяет несколько блоков в один оптимизированный блок большего размера;
    • дедуплицирование данных — устраняет дублирующиеся данные, снижая затраты на хранение;
    • удаление устаревших блоков — удаляет блоки в соответствии с retention policy.
  • Etcd — stateful-компонент для хранения данных, необходимых для репликации и шардирования:
    • хранение метаданных — хранит настройки и метаданные, необходимые для работы системы.

Logs Storage

Группа компонентов Logs Storage выполняет следующие ключевые функции: приём логов, их преобразование в блоки, отправка в долгосрочное хранилище (Object Storage) и чтение данных — как текущих, так и из долгосрочного хранилища.

В состав этой группы входят следующие основные компоненты:

image

  • Gateway — stateless-компонент, реализованный на базе Nginx, осуществляющий маршрутизацию всех входящих запросов:
    • маршрутизация — направляет входящие запросы к соответствующим компонентам системы для дальнейшей обработки.
  • Distributor — stateless-компонент, обрабатывающий входящие запросы на запись от клиентов. Он является первым шагом на пути записи данных журнала. Его основные задачи:
    • проверка — проверяет каждый поток на правильность и соответствие установленным ограничениям для проекта;
    • предварительная обработка — выполняет нормализацию меток для кэширования и хеширования;
    • ограничение скорости — ограничивает скорость входящих данных на основе лимитов проекта;
    • пересылка — отправляет проверенные данные в несколько ingester параллельно, используя коэффициент репликации.
  • Ingester — stateful-компонент, отвечающий за сохранение логов и их отправку в долгосрочное хранилище:
    • запись в журнал (WAL) — записывает все входящие метрики на диск;
    • формирование блоков — формирует двухчасовые блоки метрик в памяти;
    • хранение блоков — записывает блоки на локальный диск и затем отправляет их в долговременное хранилище.
  • Query-frontend — опциональный сервис, ускоряющий выполнение запросов на чтение логов:
    • разделение запросов — разбивает запросы на подзапросы для параллельного выполнения;
    • кэширование — кэширует результаты запросов для ускорения последующих операций;
    • планирование запросов — использует внутреннюю очередь для обработки запросов.
  • Querier — stateless-компонент, выполняющий запросы на чтение логов:
    • извлечение данных — извлекает логи из ingester и долговременного хранилища;
    • выполнение запросов — обрабатывает запросы на языке запросов журналов (LogQL).
  • Index Gateway — компонент, отвечающий за обработку и обслуживание запросов метаданных:
    • обработка запросов — обрабатывает запросы на поиск данных в индексе;
    • кэширование — кэширует результаты запросов для повышения производительности.
  • Compactor — компонент, оптимизирующий хранение и удаление устаревших данных:
    • сжатие данных — объединяет несколько файлов индекса в один оптимизированный файл;
    • удаление данных — очищает старые и ненужные файлы в соответствии с политикой хранения.
  • Etcd — stateful-компонент, используемый для хранения метаданных, необходимых для работы репликации и шардирования:
    • хранение метаданных — сохраняет настройки и метаданные, необходимые для работы системы.
  • Index-curator — stateless-компонент, анализирующий занятое место в долгосрочном хранилище и публикующий статистику по проектам в виде метрик.

Agent Distribution

Группа компонентов Agent Distribution отвечает за обновление, распространение и сбор логов от opAgent.

В состав этой группы входят следующие основные компоненты:

  • agent-updater — stateless-компонент, отвечающий за стратегию обновления opAgent. Он контролирует текущую версию opAgent и поддерживает возможность канареечного обновления агентов.
  • docker-registry — stateful-компонент, занимающийся раздачей opAgent-чарта и Docker-образов с opAgent.
  • logs-collector — stateless-компонент, принимающий логи от всех агентов, обогащающий их дополнительной информацией и выводящий их в stdout.

Примечание: подробное описание каждой из подсистем будет предоставлено в соответствующих разделах документации.

Block Storage (S3)

Block Storage (S3) — это stateful-компонент, являющийся S3-совместимым хранилищем данных, используемым для долгосрочного хранения метрик. Этот компонент реализован на базе Ceph S3 и разворачивается с помощью ceph-operator, который устанавливается отдельным модулем Deckhouse Kubernetes Platform.

Компонент включает в себя следующие элементы:

  • Manager — отвечает за управление кластером Ceph, включая его настройку и мониторинг.
  • Monitor — собирает и отображает метрики состояния кластера Ceph в реальном времени.
  • OSD — хранит данные пользователей и выполняет задачи по репликации, восстановлению и балансировке данных внутри кластера.
  • RADOS Gateway — обеспечивает S3-совместимый интерфейс для доступа к объектному хранилищу Ceph, предоставляя RESTful API, совместимый с Amazon S3.
  • Ceph-tools — набор утилит для диагностики и управления кластером Ceph, включая инструменты для администрирования и мониторинга.
  • Rook-webhook — mutating webhook для всех компонентов Ceph, обеспечивает их работу в restricted mode.