Доступно в редакциях: 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-инстансов и всегда возвращать наиболее полные и актуальные данные, даже если одна из копий временно недоступна.