Подсистема Observability

В данном подразделе описывается архитектура подсистемы Observability (подсистемы наблюдаемости) Deckhouse Kubernetes Platform (DKP).

В подсистему Observability входят следующие модули:

• prometheus — разворачивает стек мониторинга с предустановленными параметрами для DKP и приложений, что упрощает начальную настройку;
• operator-prometheus — устанавливает Prometheus Operator, который автоматизирует развёртывание и управление инстансами Prometheus;
• prometheus-metrics-adapter — позволяет автоскейлерам HPA и VPA использовать метрики мониторинга для принятия решений о масштабировании;
• log-shipper — упрощает настройку сбора логов в Kubernetes-кластере;
• loki — разворачивает в кластере хранилище оперативных логов на базе Grafana Loki;
• observability — расширяет функциональность модулей prometheus и console, предоставляя дополнительные возможности для гибкого управления визуализацией метрик и разграничения доступа к ним;
• extended-monitoring — расширяет возможности мониторинга кластера за счёт дополнительных Prometheus-экспортеров, которые позволяют выявлять потенциальные проблемы до того, как они скажутся на работе сервисов;
• monitoring-custom — упрощает настройку мониторинга пользовательских приложений, требуя только указания определенного лейбла для нужного приложения;
• monitoring-deckhouse — обеспечивает мониторинг компонентов и сервисов DKP;
• monitoring-kubernetes — обеспечивает прозрачный и своевременный контроль состояния всех узлов кластера и ключевых инфраструктурных компонентов;
• monitoring-kubernetes-control-plane — организует безопасный сбор метрик и предоставляет базовый набор правил мониторинга компонентов control plane кластера;
• upmeter — проверяет доступность платформы и состояние компонентов кластера в реальном времени и выводит информацию на соответствующие дашборды.

В подразделе на данный момент описаны:

• архитектура мониторинга в DKP;
• модули логирования.

DKP может интегрироваться с большим количеством разнообразных решений следующими способами:

Prometheus собирает метрики и выполняет правила:

• Для каждого target (цели мониторинга) с заданной периодичностью scrape_interval Prometheus выполняет HTTP-запрос на этот target, получает в ответ метрики в собственном формате и сохраняет их в свою базу данных.
• Каждый evaluation_interval обрабатывает правила (rules), на основании чего:

- отправляет алерты;

- или сохраняет новые метрики (результат выполнения правил) в свою базу данных.

Prometheus устанавливается модулем prometheus-operator DKP, который выполняет следующие функции:

• определяет следующие кастомные ресурсы:

- Prometheus — определяет инсталляцию (кластер) Prometheus;

- ServiceMonitor — определяет, как собирать метрики с сервисов;

- Alertmanager — определяет кластер Alertmanager‘ов;

- PrometheusRule — определяет список Prometheus rules.

• следит за этими ресурсами, а также:

- генерирует StatefulSet с самим Prometheus;

- создает секреты с необходимыми для работы Prometheus конфигурационными файлами (prometheus.yaml — конфигурация Prometheus, и configmaps.json — конфигурация для prometheus-config-reloader);

- следит за ресурсами ServiceMonitor и PrometheusRule и на их основании обновляет конфигурационные файлы Prometheus через внесение изменений в секреты.

Два контейнера:

• prometheus — сам Prometheus;
• prometheus-config-reloader — обвязка, которая:

- следит за изменениями prometheus.yaml и, при необходимости, вызывает reload конфигурации Prometheus’у (специальным HTTP-запросом, см. подробнее ниже);

- следит за PrometheusRule’ами (см. подробнее ниже) и по необходимости скачивает их и перезапускает Prometheus.

• Pod использует три volume:

- config — примонтированный secret (два файла: prometheus.yaml и configmaps.json). Подключен в оба контейнера;

- rules — emptyDir, который наполняет prometheus-config-reloader, а читает prometheus. Подключен в оба контейнера, но в prometheus в режиме read only;

- data — данные Prometheus. Подмонтирован только в prometheus.

• У сервера Prometheus есть config и есть rule files (файлы с правилами);
• В config имеются следующие секции:

- scrape_configs — настройки поиска target’ов (целей для мониторинга, см. подробней следующий раздел);

- rule_files — список директорий, в которых лежат rule’ы, которые необходимо загружать:

• alerting — настройки поиска Alert Manager’ов, в которые слать алерты. Секция очень похожа на scrape_configs, только результатом ее работы является список endpoint’ов, в которые Prometheus будет слать алерты.

• В целом Prometheus работает следующим образом:

(1) Prometheus читает секцию конфига scrape_configs, согласно которой настраивает свой внутренний механизм Service Discovery;

(2) Механизм Service Discovery взаимодействует с API Kubernetes (в основном — получает endpoint`ы);

(3) На основании происходящего в Kubernetes механизм Service Discovery обновляет Targets (список target’ов).

• В scrape_configs указан список scrape job’ов (внутреннее понятие Prometheus), каждый из которых определяется следующим образом:

• Таким образом, Prometheus сам отслеживает:

- добавление и удаление Pod’ов (при добавлении/удалении Pod’ов Kubernetes изменяет endpoint’ы, а Prometheus это видит и добавляет/удаляет target’ы);

- добавление и удаление сервисов (точнее endpoint’ов) в указанных пространствах имён;

• Изменение конфига требуется в следующих случаях:

- нужно добавить новый scrape config (обычно — новый вид сервисов, которые надо мониторить);

- нужно изменить список пространств имён.

1. Prometheus Operator читает (а также следит за добавлением/удалением/изменением) Service Monitor’ы (какие именно Service Monitor’ы — указано в самом ресурсе prometheus, см. подробней официальную документацию).
2. Для каждого Service Monitor’а, если в нем НЕ указан конкретный список namespace’ов (указано any: true), Prometheus Operator вычисляет (обращаясь к API Kubernetes) список namespace’ов, в которых есть Service’ы (подходящие под указанные в Service Monitor’е label’ы).
3. На основании прочитанных ресурсов servicemonitor (см. официальную документацию) и на основании вычисленных namespace’ов Prometheus Operator генерирует часть конфига (секцию scrape_configs) и сохраняет конфиг в соответствующий Secret.
4. Штатными средствами самого Kubernetes данные из секрета прилетают в Pod (файл prometheus.yaml обновляется).
5. Изменение файла замечает prometheus-config-reloader, который по HTTP отправляет запрос Prometheus’у на перезагрузку.
6. Prometheus перечитывает конфиг и видит изменения в scrape_configs, которые обрабатывает уже согласно своей логике работы (см. подробнее выше).

1. Prometheus Operator следит за PrometheusRule’ами (подходящими под указанный в ресурсе prometheus ruleSelector).

2. Если появился новый (или был удален существующий) PrometheusRule — Prometheus Operator обновляет prometheus.yaml (а дальше срабатывает логика в точности соответствующая обработке Service Monitor’ов, которая описана выше).

3. Как в случае добавления/удаления PrometheusRule’а, так и при изменении содержимого PrometheusRule’а, Prometheus Operator обновляет ConfigMap prometheus-main-rulefiles-0.

4. Штатными средствами самого Kubernetes данные из ConfigMap прилетают в Pod

5. Изменение файла замечает prometheus-config-reloader, который:

• скачивает изменившиеся ConfigMap’ы в директорию rules (это emptyDir)
• по HTTP отправляет запрос Prometheus’у на перезагрузку

6. Prometheus перечитывает конфиг и видит изменившиеся rule’ы.

Оценка доступности в DKP осуществляется модулем upmeter.

Состав модуля upmeter:

• agent — работает на master-узлах и делает пробы доступности, отправляет результаты на сервер.
• upmeter — собирает результаты и поддерживает API-сервер для их извлечения.
• front:

- status — показывает уровень доступности за последние 10 минут (требует авторизации, но ее можно отключить);

- webui — показывает дашборд со статистикой по пробам и группам доступности (требует авторизации).

• smoke-mini — поддерживает постоянное smoke-тестирование с помощью StatefulSet.

Модуль отправляет около 100 показаний метрик каждые 5 минут. Это значение зависит от количества включенных модулей Deckhouse Kubernetes Platform.

Модуль log-shipper упрощает настройку сбора логов в Kubernetes-кластере. Он позволяет организовать сбор логов как с приложений, запущенных в кластере, так и с самих узлов, а затем отправлять их в любую систему хранения — внутреннюю или внешнюю (например, Loki, Elasticsearch и другие).

Архитектура модуля log-shipper на уровне 2 модели C4 и его взаимодействия с другими компонентами DKP изображены на следующей диаграмме:

Модуль состоит из одного компонента:

• log-shipper-agent (DaemonSet) — на каждом узле кластера запускается отдельный экземпляр log-shipper-agent, который в свою очередь состоит из следующих контейнеров:

- vector — агент логирования на базе Datadog Vector.

Настраивается с помощью кастомных ресурсовClusterLogDestination, ClusterLoggingConfig и PodLoggingConfig.

- vector-reloader — сайдкар-контейнер Reloader, который отслеживает изменения секрета с конфигурацией. При наличии изменений он проверяет обновленную конфигурацию и перезапускает vector для применения обновлений.

- kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к метрикам агента.

Модуль взаимодействует со следующими компонентами:

1. Источники логов в кластере:

• приложения, запущенные в кластере — собирает логи с подов;
• файлы — читает локальные файлы на узлах кластера.

2. Приемники логов:

• внутренние системы хранения логов;
• внешние системы хранения логов и SIEM-системы.

В качестве внутренних и внешних приемников логов могут использоваться Elasticsearch, Kafka, Logstash, Loki, Splunk.

3. Kube-apiserver:

• авторизация запросов на получение метрик;
• отслеживание изменений секрета с конфигурацией vector.

С модулем взаимодействуют следующие внешние компоненты:

Prometheus-main — сбор метрик log-shipper-agent.

В Kubernetes системные логи на узлах хранятся недолго и могут быть утеряны при перезапуске или обновлении узлов. Модуль loki разворачивает в кластере собственное хранилище оперативных логов на базе Grafana Loki.

Возможности модуля:

• системные логи автоматически попадают в Loki без дополнительной настройки;
• доступ к логам реализован через Grafana и веб-интерфейс Deckhouse (модуль console).

Архитектура модуля loki на уровне 2 модели C4 и его взаимодействия с другими компонентами DKP изображены на следующей диаграмме:

Модуль состоит из одного компонента:

• loki — StatefulSet из одной реплики loki-0, которая в свою очередь состоит из следующих контейнеров:

- loki — контейнер с Grafana Loki;

- kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищенного доступа к loki и его метрикам.

С модулем взаимодействуют следующие внешние компоненты:

• vector — отправка логов с системных компонентов в loki;
• console (встроенная в веб-интерфейс Grafana) — использует loki в качестве источника данных для визуализации и анализа логов;
• prometheus-main — сбор метрик loki.