Доступно в редакциях:  CE, BE, SE, SE+, EE, CSE Lite (1.67), CSE Pro (1.67)

Веб-интерфейсы, связанные с модулем: grafana

Модуль разворачивает стек мониторинга с предустановленными параметрами для Deckhouse Kubernetes Platform (DKP) и приложений, что упрощает начальную настройку.

Ключевые возможности:

  • В комплекте — готовые триггеры и дашборды, поддерживается push и pull-модель сбора метрик. Нагрузка оптимизирована за счет использования кешей и Deсkhouse Prom++. Есть возможность хранить исторические данные с помощью даунсемплинга.
  • Нагрузка оптимизирована за счет использования кешей и Deckhouse Prom++.
  • Есть возможность хранить исторические данные с помощью даунсемплинга.
  • Модуль покрывает все основные задачи базового мониторинга платформы и приложений.

Модуль покрывает все основные задачи базового мониторинга DKP и приложений.

Мониторинг аппаратных ресурсов

Реализовано отслеживание загрузки аппаратных ресурсов кластера с графиками по утилизации:

  • процессора;
  • памяти;
  • диска;
  • сети.

Графики доступны с агрегацией:

  • по подам;
  • контроллерам;
  • пространствам имен;
  • узлам.

Мониторинг Kubernetes

Deckhouse настраивает мониторинг параметров «здоровья» Kubernetes и таких его компонентов, как:

  • общая утилизация кластера;
  • связанность узлов Kubernetes между собой (измеряется rtt между всеми узлами);
  • доступность и работоспособность компонентов control plane:
    • etcd;
    • coredns и kube-dns;
    • kube-apiserver и др.
  • синхронизация времени на узлах и др.

Мониторинг Ingress

Подробное описание здесь

Режим расширенного мониторинга

В Deckhouse возможно использование режима расширенного мониторинга, который предоставляет алерты по дополнительным метрикам:

  • свободному месту и inode на дисках узлов,
  • утилизации узлов,
  • доступности подов и образов контейнеров,
  • истечении действия сертификатов,
  • другим событиям кластера.

Алертинг в режиме расширенного мониторинга

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

  • значения свободного места и inodes на диске;
  • утилизация CPU узлов и контейнера;
  • процент ошибок с кодом 5xx на ingress-nginx;
  • количество возможных недоступных подов в Deployment, StatefulSet, DaemonSet.

Управление мониторингом как кодом (IaC подход)

Возможности системы мониторинга DKP могут быть расширены за счёт использования модуля Observability. С его помощью реализуется:

  • управление алертами;
  • разграничение прав доступа к настройкам и данным мониторинга;
  • централизованное управление дашбордами.

Алерты

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

Отправка алертов во внешние системы

Deckhouse поддерживает отправку алертов с помощью Alertmanager:

  • по протоколу SMTP;
  • в PagerDuty;
  • в Slack;
  • в Telegram;
  • посредством Webhook;
  • по любым другим каналам, поддерживаемым в Alertmanager.

Архитектура

Схема взаимодействия

Базовые компоненты мониторинга

Компонент Описание
prometheus-main Основной Prometheus, который выполняет scrape каждые 30 секунд (с помощью параметра scrapeInterval можно изменить это значение). Он обрабатывает все правила, отправляет алерты и является основным источником данных.
prometheus-longterm Просмотр и анализ исторических трендов.
trickster Кеширующий прокси, снижающий нагрузку на Prometheus.
aggregating-proxy Агрегирующий и кеширующий прокси, снижающий нагрузку на Prometheus и объединяющий main и longterm в один источник.
memcached Сервис кеширования данных в оперативной памяти.
grafana Управляемая платформа визуализации данных. Включает подготовленные dashboard’ы для всех модулей DKP и некоторых популярных приложений. Grafana умеет работать в режиме высокой доступности, не хранит состояние и настраивается с помощью CRD.
metrics-adapter Компонент, соединяющий Prometheus и Kubernetes metrics API. Включает поддержку HPA в кластере Kubernetes.
vertical-pod-autoscaler Компонент, позволяющий автоматически изменять размер запрошенных ресурсов для подов с целью оптимальной утилизации CPU и памяти.
Различные exporter’ы Подготовленные и подключенные к Prometheus exporter’ы. Список включает множество exporter’ов для всех необходимых метрик: kube-state-metrics, node-exporter, oomkill-exporter, image-availability-exporter и многие другие.
Push/pull модель сбора метрик Мониторинг по умолчанию использует pull-модель — данные собираются с приложений по инициативе системы мониторинга. Также поддерживается push-модель: метрики можно передавать через протокол Prometheus Remote Write или с помощью Prometheus Pushgateway.

Внешние компоненты

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

Название Описание
Alertmanagers Alertmanager’ы могут быть подключены к Prometheus и Grafana и находиться как в кластере Deckhouse, так и за его пределами.
Long-term metrics storages Используя протокол remote write, возможно отсылать метрики из Deckhouse в большое количество хранилищ, включающее Cortex, Thanos, VictoriaMetrics.

Режим отказоустойчивости и высокой доступности мониторинга (HA)

Модуль мониторинга обеспечивает встроенную отказоустойчивость всех ключевых компонентов DKP. Все сервисы мониторинга (Prometheus-серверы, системы хранения, прокси и прочие важные компоненты) по умолчанию развертываются в нескольких копиях. Это гарантирует, что в случае сбоя отдельного экземпляра сервис продолжит работу без потери данных и доступности.

Prometheus — основной компонент сбора метрик — запускается минимум в двух копиях (при наличии достаточного количества узлов в кластере). Оба инстанса Prometheus используют одинаковую конфигурацию и получают одни и те же данные. Чтобы обеспечить бесшовную работу при отказе одной из копий для обращения к Prometheus используется специальный компонент — aggregation-proxy. Он позволяет объединять метрики обоих Prometheus-инстансов и всегда возвращать наиболее полные и актуальные данные, даже если одна из копий временно недоступна.