Модуль observability

Модуль observability расширяет функциональность модуля prometheus и веб-интерфейса Deckhouse, предоставляя дополнительные возможности для гибкого управления метриками, дашбордами и алертами, а также средства разграничения доступа к ним.

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

• Управление дашбордами — модуль позволяет пользователям добавлять собственные дашборды в формате Grafana.
• Управление группами триггеров и метрик — модуль позволяет создавать и настраивать собственные группы триггеров и метрик.
• Настройка уведомлений — модуль позволяет настраивать каналы уведомлений (Telegram, Slack, электронная почта, вебхуки), политики уведомлений, а также дает возможность отключать уведомления при необходимости.
• Работа с алертами — модуль предоставляет информацию об активных алертах, а также сохраняет историю завершенных алертов.
• Предоставление стандартных источников данных.
• Поддержка пользовательских источников данных — модуль дополнительно к предоставляемому набору стандартных источников данных позволяет добавить пользовательские.

Подробнее с описанием модуля можно ознакомиться в разделе документации модуля.

Архитектура модуля

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

Компоненты модуля

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

1. Observability-controller — состоит из одного контейнера observability-controller, управляет жизненным циклом большинства кастомных ресурсов модуля, таких как ObservabilityMetricsRulesGroup, ObservabilityNotificationChannels, ObservabilityNotificationSilence и других. С полным списком ресурсов, которыми управляет модуль, можно ознакомиться в разделе «Кастомные ресурсы» документации модуля.

2. Observability-webhook — состоит из одного контейнера observability-webhook, реализующего вебхук-сервер для проверки и изменения кастомных ресурсов через механизмы Validating/Mutating Admission Controllers.

3. Alert-kube-api — состоит из одного контейнера alert-kube-api, реализует Kubernetes Extension API Server, который расширяет Kubernetes API кастомными ресурсами ObservabilityAlert и ClusterObservabilityAlert. Alert-kube-api позволяет запрашивать алерты как кастомные ресурсы, используя в качестве бэкенда компонент Alertmanager модуля, и кеширует их в памяти для быстрого доступа.

4. Alertmanager — принимает алерты от компонента prometheus-main модуля prometheus, обрабатывает и отправляет их конечным получателям. DKP поддерживает отправку алертов через следующие каналы доставки:

   • Email;
   • Telegram;
   • Slack;
   • Webhook.

   Компонент содержит следующие контейнеры:

   • alertmanager — основной контейнер. В модуле используется в форк оригинального Alertmanager от компании «Флант», поддерживающий мультитенантность: разделение алертов на системные (кластерные) и проектные. Доставка алертов (политики, каналы, сайленсеры) также мультитенантная, что позволяет индивидуально настроить каналы и политики доставки в разных проектах.

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

5. Grafana — компонент, предоставляющий веб-интерфейс для визуализации данных мониторинга. В модуле используется форк Grafana от компании «Флант». Используемая модификация Grafana обладает расширенными возможностями, такими как разграничение доступа к метрикам и дашбордам в рамках мультитенантности. Дашборды Grafana модуля observability интегрированы в веб-интерфейс Deckhouse (управление системой мониторинга из одного окна).

   Компонент содержит следующие контейнеры:

   • grafana — основной контейнер;
   • grafana-kube-storage — сайдкар-контейнер, реализующий бэкенд для контейнера grafana и предоставляющий управление ресурсами Dashboard и чтение ресурсов Datasource API компонента Grafana. Данные ресурсы позволяют просматривать и управлять дашбордами в пределах неймспейсов (проектов), а также подключать пользовательские источники данных;
   • nginx — сайдкар-контейнер, представляющий собой прокси-сервер NGINX, чья основная задача — это раздача статических файлов. Является Open Source-проектом.

6. Label-enforcer — компонент, выполняющий авторизацию и проксирование запросов пользователей к источникам метрик (prometheus-main через сервис label-proxy) и логов (loki через сервис logs-gateway), указанным в ресурсах Datasource API компонента grafana. Label-enforcer проверяет RBAC-доступ к данным мониторинга в зависимости от прав пользователя, получает список доступных неймспейсов и обогащает запросы лейблами для возможности фильтрации запрашиваемых данных в рамках неймспейсов пользователей. Подробнее о разграничении доступа к метрикам можно ознакомиться в документации модуля. Label-enforcer обрабатывает запросы на чтение и запись метрик.

   Состоит из единственного контейнера enforcer.

7. Opagent (DaemonSet) — агент, предназначенный для сбора метрик с операционной системы и прикладного программного обеспечения, установленного на серверы. Разработан компанией «Флант» для Deckhouse Observability Platform (DOP) на основе Okagent (агента Okmeter), входящего в состав системы мониторинга Okmeter.

   В модуле observability opAgent подключается к managed-сервисам, таким как managed-postgres, managed-memcached, managed-kafka и другим (список поддерживаемых сервисов постоянно расширяется), собирает с них метрики, после чего отправляет их в компонент prometheus-main модуля prometheus. Если включен модуль observability-platform, opAgent собирает метрики с узлов кластера и отправляет их в DOP.

   OpAgent отправляет собранные данные по протоколу Prometheus Remote Write:

   • метрики managed-сервисов — в Prometheus через label-enforcer;
   • метрики с узлов кластера — в DOP.

   Состоит из единственного контейнера opagent.

Взаимодействия модуля

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

1. Kube-apiserver:

   • для авторизации запросов к данным мониторинга;
   • для управления кастомными ресурсами модуля.
2. Prometheus-main — использует в качестве источника и приемника данных.
3. Loki — использует в качестве источника данных.
4. Получатели алертов — отправляет алерты.
5. Deckhouse Observability Platform — использует в качестве приемника данных (метрики узлов).

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

1. Kube-apiserver:

   • выполняет проверку и изменение кастомных ресурсов модуля (с помощью validating- и mutating-вебхуков);
   • пересылает в alert-kube-api запросы на кастомные ресурсы ObservabilityAlert и ClusterObservabilityAlert.
2. Prometheus-main — отправляет алерты в Alertmanager.
3. Веб-интерфейс Deckhouse — использует Grafana для визуализации данных мониторинга.

Дополнительные ресурсы

• Документация модуля console
• Документация модуля managed-kafka
• Документация модуля managed-memcached
• Документация модуля managed-postgres
• Документация модуля observability
• Документация модуля prometheus