Модуль доступен только в Deckhouse Enterprise Edition.
Архитектура Deckhouse Observability Platform
Deckhouse Observability Platform имеет микросервисную архитектуру, в которой вся система разделена на множество компонентов, выполняющих определённую задачу. Эти компоненты могут быть сгруппированы по их назначению.
Ниже приведена принципиальная схема с группами компонентов:
Далее будет предоставлена подробная информация о каждой из групп.
UI + Control-plane
Группа компонентов UI + Control-plane отвечает за управление платформой через пользовательский интерфейс и координацию всех внутренних процессов.
В состав этой группы входят следующие основные компоненты:
- 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 отвечает за выполнение правил, обработку алертов и отправку уведомлений.
В состав этой группы входят следующие основные компоненты:
- Ruler — stateless-компонент, выполняющий PromQL-запросы и сохраняющий результат в виде новой метрики. Также Ruler проверяет триггеры, выполняя PromQL-запросы, и, если выполняется условие срабатывания, передаёт алерт в Alertgate.
- Alertgate — компонент, отвечающий за приём информации о сработавших триггерах. Он сохраняет текущее состояние триггеров в базу данных (PostgreSQL) и отправляет их в Alertmanager. Для некоторых триггеров Alertgate также выполняет дополнительную проверку причин резолвации: исчезновение метрики или успешная резолвация. В случае резолвации продолжает отправлять алерты.
- Alertmanager — stateful-компонент, принимающий оповещения от Ruler. Он производит их группировку и дедупликацию, а также отправляет уведомления в соответствии с настроенными каналами доставки, такими как email, Telegram, webhook и другие.
Metrics Storage
Группа компонентов Metrics Storage выполняет следующие ключевые функции: приём метрик, их преобразование в блоки, отправка в долгосрочное хранилище (Object Storage) и чтение данных — как текущих, так и из долгосрочного хранилища.
В состав этой группы входят следующие основные компоненты:
- 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) и чтение данных — как текущих, так и из долгосрочного хранилища.
В состав этой группы входят следующие основные компоненты:
- 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.