Мониторинг

Данный раздел предназначен для пользователей проектов Deckhouse Kubernetes Platform (DKP).

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

По умолчанию в DKP доступен готовый набор дашбордов и алертов, позволяющих отслеживать ключевые показатели состояния приложений. Доступ к ним осуществляется через раздел «Мониторинг» веб-интерфейса Deckhouse.

Кроме того, пользователи могут:

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

Подробнее о расширенных возможностях мониторинга, включая управление дашбордами и метриками, можно прочитать в описании модуля observability.

После установки DKP пользователям по умолчанию доступен базовый набор инструментов для наблюдения за кластером.

Дашборды содержат графики с данными по загрузке CPU, потреблению памяти, а также дисковой и сетевой активности в разрезе подов, узлов или пространств имён.

В разделе «Мониторинг» → «Дашборды» веб-интерфейса Deckhouse у пользователей есть доступ к следующим группам дашбордов:

• Ingress Nginx — метрики по работе Ingress-контроллера, включая информацию о состоянии виртуальных хостов, коды ответов и данные по задержке в обработке запросов.
• Потребление ресурсов (Main) — основные показатели кластера и приложений, включая данные о нагрузке ресурсов, состоянии подов, контроллеров и пространств имён.
• Security — метрики, связанные с безопасностью кластера.

Алерты — это автоматические уведомления, информирующие о событиях, требующих внимания, например, о превышении пороговых значений метрик или проблемах с доступностью компонентов. Порог срабатывания большинства алертов можно переопределять при необходимости.

По умолчанию в кластере DKP включены уведомления о следующих видах событий:

• Истечение срока действия сертификатов, а также ошибки при их выпуске или продлении (модули cert-manager, extended-monitoring, ingress-nginx).
• Недоступность или ошибки при загрузке контейнерных образов, включая проблемы аутентификации, авторизации, некорректный формат имени образа, отсутствие образа в registry или недоступность самого registry (модуль extended-monitoring).
• Ошибки выполнения рабочих нагрузок, таких как CronJob, Deployment, DaemonSet и StatefulSet, включая невозможность создания подов, недоступность реплик и ошибки планирования (модуль extended-monitoring).
• Недоступность экспортеров метрик, из-за чего Prometheus не может получить данные (модуль extended-monitoring).
• Проблемы с дисковым пространством, включая нехватку места или inode на PVC (модуль extended-monitoring).
• Ошибки в работе Ingress-контроллера, включая высокий процент 5xx-ответов от бэкендов (модуль extended-monitoring).
• Проблемы с качеством работы сети (модуль monitoring-ping).

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

• мониторинг пользовательских приложений — можно настроить сбор метрик с приложения, следуя инструкции;
• создание собственных дашбордов — можно добавлять специализированные дашборды, используя ресурс GrafanaDashboardDefinition;
• настройка собственных алертов — можно задать новые правила уведомлений, используя ресурс CustomPrometheusRules.

В этом разделе вы узнаете о работе с дашбордами для анализа состояния Deckhouse Kubernetes Platform (DKP) и запущенных в нем приложений.

Дашборды представляют собой наборы графиков и таблиц с данными о работе приложений. Они содержат информацию о загрузке CPU, потреблении памяти, дисковой и сетевой активности, а также о состоянии подов, контроллеров, узлов и неймспейсов.

В DKP доступны предустановленные дашборды, а также пользовательские дашборды, которые можно создавать несколькими способами.

Пользователям DKP предоставляется доступ к базовому набору дашбордов для наблюдения за состоянием запущенных приложений. Дашборды доступны в веб-интерфейсе Deckhouse в разделе «Мониторинг» → «Дашборды».

Дашборды для мониторинга работы Ingress-контроллера. Содержат метрики, отражающие состояние виртуальных хостов, статистику по HTTP-ответам, а также данные о задержках при обработке запросов.

Доступные дашборды:

• Namespaces — совокупные метрики Ingress-ресурсов по неймспейсам;
• Namespace Detail — детальная информация по Ingress-ресурсам в выбранном неймспейсе;
• VHosts — обзор состояния виртуальных хостов;
• VHost Detail — детальная информация по выбранному виртуальному хосту.

Набор дашбордов для анализа потребления ресурсов приложениями. Дашборды предназначены для оценки нагрузки, поиска проблем с ресурсами и анализа состояния рабочих нагрузок.

Доступные дашборды:

• Namespaces — сводная информация по всем неймспейсам;
• Namespace — основные показатели использования ресурсов в выбранном неймспейсе;
• Namespace / Controller — статистика использования ресурсов контроллерами в рамках выбранного неймспейса;
• Namespace / Controller / Pod — детальные метрики по отдельным подам.

Пользователи DKP могут создавать собственные дашборды несколькими способами, в зависимости от требований к управлению доступом и области видимости дашборда.

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

Модуль добавляет новые типы дашбордов, включая ресурсы, ограниченные неймспейсом. Это даёт пользователям возможность создавать и управлять собственными дашбордами без необходимости иметь права на объекты кластерного уровня. Кроме того, модуль упрощает редактирование дашбордов — настройка выполняется напрямую в веб-интерфейсе, без необходимости работы с ресурсами вручную.

Для создания дашбордов предусмотрены следующие ресурсы:

• ObservabilityDashboard — дашборды в рамках неймспейса. Отображаются в веб-интерфейсе Deckhouse в разделе «Мониторинг» → «Проекты».

Пример:

• ClusterObservabilityDashboard — дашборды для отображения компонентов кластера. Отображаются в веб-интерфейсе Deckhouse в разделе «Мониторинг» → «Система».

Пример:

• ClusterObservabilityPropagatedDashboard — дашборды, расширяющие список дашбордов из двух предыдущих категорий. Такие дашборды автоматически добавляются в веб-интерфейс Deckhouse и отображаются в разделах «Мониторинг» → «Система» и «Мониторинг» → «Проекты». Они становятся доступны пользователям, обладающим правами на соответствующий неймспейс или системный раздел.

Пример:

Доступ к дашбордам настраивается с помощью механизмов действующей ролевой модели (RBAC).

В зависимости от типа дашборда (системный или пользовательский) права назначаются на следующие ресурсы:

• observabilitydashboards.observability.deckhouse.io — дашборды в рамках неймспейсов;
• clusterobservabilitydashboards.observability.deckhouse.io — системные дашборды;
• clusterobservabilitypropagateddashboards.observability.deckhouse.io — дашборды, распространяемые на всех пользователей.

Для выполнения операций с дашбордами требуются следующие разрешения:

• чтение — get;
• создание и редактирование — create, update, patch, delete.

Доступ к метрикам в дашбордах также контролируется с помощью RBAC. В зависимости от выданных прав фильтрация метрик осуществляется автоматически.

• Поддерживаются следующие сценарии доступа:
• Пользователи неймспейсов получают доступ только к метрикам своего неймспейса. Проверяется RBAC-доступ к ресурсу metrics.observability.deckhouse.io.
• Администраторы DKP получают доступ ко всем системным метрикам:
• метрики Deckhouse (d8-*);
• метрики Kubernetes (kube-*);
• метрики без лейбла namespace.

Используется RBAC-доступ к ресурсу clustermetrics.observability.deckhouse.io.

• Метрики из пользовательских неймспейсов также могут быть доступны администраторам при наличии соответствующих прав на ресурс metrics.observability.deckhouse.io.

Пример настройки ресурсов ClusterRole и RoleBinding для доступа к метрикам и дашбордам на чтение и редактирование:

Чтобы перенести дашборды, созданные с помощью устаревшего ресурса GrafanaDashboardDefinition, в один из форматов модуля observability, отредактируйте каждый манифест соответствующего дашборда вручную. Обратите внимание на важные отличия:

Пример конвертации:

• Старый формат:

• Новый формат:

Чтобы добавить дашборд напрямую в Grafana, используйте ресурс GrafanaDashboardDefinition.

Пример:

При использовании этого способа учитывайте следующие ограничения:

• Дашборды, добавленные через GrafanaDashboardDefinition, нельзя изменить через интерфейс Grafana.
• Алерты, настроенные в панели «Dashboard», не работают с шаблонами datasource — такой дашборд считается невалидным и не импортируется. Начиная с Grafana 9.0, функционал legacy alerting признан устаревшим и заменён на Grafana Alerting. В связи с этим не рекомендуется использовать legacy alerting (оповещения панели мониторинга) в дашбордах.
• Если после применения ресурса дашборд не появляется в Grafana, возможно, в JSON-файле дашборда содержится ошибка. Чтобы просмотреть логи компонента, отвечающего за применение дашбордов, используйте следующую команду:

Deckhouse Kubernetes Platform (DKP) поддерживает четыре способа подключения приложения к системе мониторинга:

1. Убедитесь, что включен модуль monitoring-custom. При необходимости обратитесь к администратору DKP.
2. Убедитесь, что приложение, с которого будут собираться метрики, отдает их в формате Prometheus.
3. Установите лейбл prometheus.deckhouse.io/custom-target на сервис или под, которые необходимо подключить к мониторингу. Значение лейбла определит имя в списке target’ов Prometheus.

Пример:

В качестве значения лейбла prometheus.deckhouse.io/custom-target рекомендуется использовать название приложения, которое позволяет его уникально идентифицировать в кластере.

Формат лейбла должен соответствовать требованиям Kubernetes: не более 63 символов, среди которых могут быть буквенно-цифровые символы ([a-z0-9A-Z]), а также дефисы (-), знаки подчеркивания (_), точки (.).

Если приложение ставится в кластер больше одного раза (staging, testing и т. д.) или даже ставится несколько раз в одно пространство имён, достаточно одного общего названия, так как у всех метрик в любом случае будут лейблы namespace, pod и, если доступ осуществляется через сервис, лейбл service. Это название, которое уникально идентифицирует приложение в кластере, а не его единичную инсталляцию.

4. Для порта, с которого нужно собирать метрики, укажите имя http-metrics и https-metrics для подключения по HTTP или HTTPS соответственно.

Если это невозможно (например, порт уже определен и назван другим именем), используйте следующие аннотации:

• prometheus.deckhouse.io/port: номер_порта — для указания порта;
• prometheus.deckhouse.io/tls: "true" — если сбор метрик будет проходить по HTTPS.

При указании аннотации для сервиса в качестве значения порта необходимо использовать targetPort — порт, который открыт и слушается приложением, а не порт сервиса.

Пример 1:

Пример 2:

При использовании service mesh Istio в режиме STRICT mTLS укажите для сбора метрик аннотацию prometheus.deckhouse.io/istio-mtls: "true" у сервиса или пода. Важно, что метрики приложения должны экспортироваться по протоколу HTTP без TLS.

Пример:

Для более точной настройки мониторинга приложения можно указать дополнительные аннотации для пода или сервиса, для которых настраивается мониторинг:

• prometheus.deckhouse.io/path — путь для сбора метрик (по умолчанию: /metrics);
• prometheus.deckhouse.io/query-param-$name — GET-параметры, которые будут преобразованы в map вида $name=$value (по умолчанию: ''). Можно указать несколько таких аннотаций. Например, prometheus.deckhouse.io/query-param-foo=bar и prometheus.deckhouse.io/query-param-bar=zxc будут преобразованы в запрос вида http://...?foo=bar&bar=zxc;
• prometheus.deckhouse.io/allow-unready-pod — разрешает сбор метрик с подов в любом состоянии (по умолчанию метрики собираются только с подов в состоянии Ready). Эта опция полезна в редких случаях. Например, если ваше приложение запускается очень долго (при старте загружаются данные в базу или прогреваются кеши), но в процессе запуска уже отдаются полезные метрики, которые помогают следить за запуском приложения;
• prometheus.deckhouse.io/sample-limit — сколько семплов разрешено собирать с пода (по умолчанию 5000). Значение по умолчанию защищает от ситуации, когда приложение внезапно начинает отдавать слишком большое количество метрик, что может нарушить работу всего мониторинга. Аннотация должна быть размещена на том же ресурсе, на который добавлен лейбл prometheus.deckhouse.io/custom-target.

DKP поддерживает подключение приложений через два схожих по функциональности ресурса:

• PodMonitor (рекомендуемый вариант) — обнаруживает поды напрямую и собирает метрики с их контейнеров. В большинстве случае это предпочтительный вариант, поскольку он работает напрямую с подами и не зависит от наличия сервисов.
• ServiceMonitor — обнаруживает сервисы и собирает метрики с подов, находящихся за ними. При этом сервисы используются как источник метаданных (например, лейблов), а фактический сбор метрик выполняется с адресов подов, входящих в соответствующие эндпоинты.

Оба ресурса позволяют задавать интервал опроса, пути, TLS-параметры, параметры переписывания лейблов (relabeling) и другие настройки.

Разница между ресурсами заключается в источнике собираемых метрик. Используйте PodMonitor, если требуется сбор метрик напрямую с подов, и ServiceMonitor — если ваше приложение публикует метрики через Service.

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

1. Установите лейбл prometheus.deckhouse.io/monitor-watcher-enabled: "true" в том же пространстве имен, где будет находиться PodMonitor или ServiceMonitor:

2. Создайте ресурс PodMonitor или ServiceMonitor, указав обязательный лейбл prometheus: main, а также перечислив параметры необходимых эндпоинтов.

Пример для PodMonitor:

Пример для ServiceMonitor:

Если вам нужно добавить дополнительные лейблы непосредственно в собираемые метрики, воспользуйтесь правилами переписывания метрик (с помощью параметра metricRelabelings).

Ниже приведен пример ресурса PodMonitor, который добавляет в собираемые метрики лейбл application со значением dotnet:

После применения такого правила в метриках появится дополнительный лейбл:

ScrapeConfig — это кастомный ресурс, который позволяет настраивать раздел конфигурации Prometheus под названием scrape_config для полного контроля над процессом сбора метрик.

Чтобы подключить приложение к системе мониторинга, выполните следующие шаги:

1. Установите лейбл prometheus.deckhouse.io/scrape-configs-watcher-enabled: "true" в пространстве имен, где будет находиться ScrapeConfig:

2. Создайте ресурс ScrapeConfig, указав обязательный лейбл prometheus: main:

DKP поддерживает сбор метрик доступности с blackbox-exporter, который не входит в состав DKP и должен быть установлен отдельно в кластере. Для этого используется кастомный ресурс Probe, который описывает проверки доступности (probes), выполняемые Prometheus.

Чтобы подключить Probe к системе мониторинга DKP, выполните следующие шаги:

1. Установите лейбл prometheus.deckhouse.io/probe-watcher-enabled: "true" в пространстве имен, где будет находиться Probe:

2. Создайте ресурс Probe, указав обязательный лейбл prometheus: main: