Мониторинг сервисов

Модуль observability позволяет собирать метрики и отслеживать состояние управляемых сервисов, запущенных в кластере DKP.

Мониторинг сервисов включён по умолчанию при выполнении следующих требований:

• DKP версии 1.76.0 или выше;
• модуль prompp версии 3.7.10 или выше (если он используется).

Поддерживаемые сервисы

В данный момент модуль поддерживает мониторинг следующих управляемых сервисов:

Подключение инстанса PostgreSQL

Чтобы модуль мог собирать метрики с инстанса PostgreSQL, выполните на этом инстансе от имени суперпользователя (или другой роли, у которой уже есть полный доступ к представлениям pg_stat_*) следующие команды:

CREATE ROLE okagent WITH LOGIN;
CREATE SCHEMA okmeter; -- Отделяет вспомогательную функцию от остальной схемы.
GRANT USAGE ON SCHEMA okmeter TO okagent; -- Даёт okagent доступ к вспомогательной схеме.
CREATE OR REPLACE FUNCTION okmeter.pg_stats(text) RETURNS SETOF RECORD AS
$$
DECLARE r record;
BEGIN
    FOR r IN EXECUTE 'SELECT r FROM pg_' || $1 || ' r' LOOP RETURN NEXT r;
    END LOOP;
    RETURN;
END
$$ LANGUAGE plpgsql SECURITY DEFINER; -- Позволяет okagent читать защищённые представления pg_stat_* без дополнительных прав.

Агент модуля (opagent) обращается к PostgreSQL через локальный unix-сокет на той же ноде, по пути /controller/run, и подключается без пароля — pg_hba.conf должен разрешать okagent локальное подключение без проверки пароля.

Более простой вариант для PostgreSQL 10 и новее

Начиная с PostgreSQL 10, встроенная роль pg_monitor даёт тот же уровень доступа для мониторинга, что и функция okmeter.pg_stats выше, без создания отдельной схемы и функции:

CREATE ROLE okagent WITH LOGIN;
GRANT pg_monitor TO okagent;

Используйте этот вариант вместо схемы и функции, если все ваши инстансы работают на PostgreSQL 10 или новее. Функция okmeter.pg_stats выше дополнительно работает и на версиях PostgreSQL старше 10, где роли pg_monitor ещё не существует.

PostgreSQL 16 и новее

Необязательно: без зарезервированного соединения okagent получит отказ точно так же, как и любой другой клиент, если у инстанса закончатся свободные соединения. Начиная с PostgreSQL 16 выдайте okagent встроенную роль pg_use_reserved_connections и зарезервируйте для неё хотя бы одно соединение — superuser_reserved_connections на несуперпользовательские роли не распространяется:

GRANT pg_use_reserved_connections TO okagent;
ALTER SYSTEM SET reserved_connections = 1;

Одного зарезервированного соединения достаточно — okagent не держит больше одного подключения к инстансу одновременно. Недоступно на версиях PostgreSQL младше 16.

Дашборды

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

Алерты

Для сервисов PostgreSQL доступны следующие алерты:

Отключение мониторинга

Мониторинг сервисов управляется лейблом observability.deckhouse.io/servicemonitoring. Его можно задать на неймспейсе (для всех инстансов в проекте) или на конкретном поде (для отдельного инстанса).

Допустимые значения:

Если лейбл отсутствует или содержит неподдерживаемое значение, используется режим enabled.

Пример конфигурации:

apiVersion: v1
kind: Namespace
metadata:
  name: project-a
  labels:
    observability.deckhouse.io/servicemonitoring: no-alerts

Лейбл на поде может только ужесточить ограничение, заданное на неймспейсе, но не ослабить его. Эффективное значение для инстанса определяется по наиболее строгому правилу: enabled < no-alerts < disabled. В таблице ниже показано, как определяется эффективное значение в зависимости от значений лейбла на неймспейсе проекта и поде.

Где запускается агент

Агент разворачивается как DaemonSet, но только на узлах, где есть хотя бы один сервис с включённым мониторингом (см. Отключение мониторинга). Такие узлы модуль отмечает лейблом observability.deckhouse.io/opagent: он ставится, когда на узел планируется первый отслеживаемый сервис, и снимается через пару минут после того, как узел покинул последний. Лейбл управляется автоматически — не ставьте и не снимайте его вручную, модуль вернёт его в нужное состояние.

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