Рецепты мониторинга

Раздел «Рецепты» — готовое подключение мониторинга типовых сервисов: PostgreSQL, MariaDB, nginx, Redis и Docker. Один рецепт — это страница со всем, что нужно, чтобы сервис оказался под наблюдением за несколько минут: готовый конфиг коллектора OpenTelemetry с уже подставленным ключом проекта, живой индикатор «данные приходят», преднастроенные графики по метрикам ресивера и рекомендованные пороги, создающиеся одной кнопкой как обычные правила оповещений по метрикам.

Рецепты не заводят новых сущностей и каналов приёма: метрики сервисов едут тем же OTLP-приёмом, что и в Метриках, пороги — обычные правила оповещений, уведомления — те же каналы проекта, что у Оповещений.

Где находится

Значок графика в левой рельсе → «Метрики» → под-пункт «Рецепты» (или напрямую /projects/{id}/recipes). Список — карточки всех рецептов с бейджем статуса данных и счётчиком созданных порогов; карточка ведёт на страницу рецепта /projects/{id}/recipes/{slug}.

Просмотр открыт любому участнику с доступом к проекту — это чтение телеметрии и справка по подключению, не настройка. Кнопка создания рекомендованных порогов — оператору проекта (участнику команды проекта, а также owner/admin организации — см. Роли и права).

Как подключить сервис

Страница рецепта ведёт по шагам:

1. Установите otelcol-contrib на сервер рядом с сервисом. Это тот же коллектор OpenTelemetry Collector Contrib, что и в инструкции по подключению хостов — официальные .deb/.rpm-пакеты ставят systemd-юнит otelcol-contrib и конфиг в /etc/otelcol-contrib/config.yaml.
2. Скопируйте конфиг со страницы рецепта (кнопка «Скопировать конфиг») и замените им содержимое /etc/otelcol-contrib/config.yaml. Адрес инстанса и активный публичный ключ проекта уже подставлены; значения CHANGE_ME замените на свои (см. требования по сервисам ниже). Если у проекта нет активного публичного ключа, вместо конфига страница покажет подсказку выпустить его в настройках проекта. endpoint экспортёра — базовый URL инстанса, без /v1/metrics: путь дописывает сам экспортёр otlphttp (то же правило, что в Хостах).
3. Перезапустите коллектор (sudo systemctl restart otelcol-contrib). Через минуту-другую бейдж на странице сменится с «Ждём данные» на «Данные приходят».

Как работает детекция. Бейдж «Данные приходят» означает, что сигнатурная метрика рецепта (например, postgresql.backends у PostgreSQL) имеет точки за последние 15 минут. Детекция живая: если сервис или коллектор замолчит дольше этого окна, бейдж вернётся в «Ждём данные» — и это же честный сигнал при первой настройке, что экспорт ещё не дошёл.

Один конфиг — один ресивер: если на сервере живут несколько сервисов из рецептов (или коллектор уже шлёт хостовые метрики), объединяйте секции receivers/processors и пайплайны в одном config.yaml, а не заводите несколько коллекторов.

Требования по сервисам

PostgreSQL

• В username/password конфига — пользователь PostgreSQL для мониторинга. Ему не нужны права на данные, достаточно чтения статистики: заведите отдельного пользователя и выдайте роль pg_monitor.
• Метрика postgresql.deadlocks у ресивера по умолчанию выключена, поэтому сниппет включает её явно (postgresql.deadlocks: {enabled: true}). Не удаляйте эту строку: без неё рекомендованный critical-порог по дедлокам не сработает никогда — метрика просто не будет приходить.
• tls: {insecure: true} в сниппете рассчитан на локальное подключение на том же сервере. Для удалённой БД настройте TLS у ресивера, а не оставляйте insecure: true.

MariaDB

• Рецепт использует ресивер mysql коллектора — он официально поддерживает и MySQL (5.7–9.x), и MariaDB (10.5.x–11.x, LTS 11.4 и 11.8), так что рецепт подойдёт для обоих.
• В username/password конфига — пользователь MariaDB для мониторинга. Права на данные не нужны, достаточно чтения статистики: большинство метрик собирается через SHOW GLOBAL STATUS, а метрикам из performance schema нужен GRANT SELECT ON performance_schema.*.
• Метрика mysql.query.slow.count у ресивера по умолчанию выключена, поэтому сниппет включает её явно (mysql.query.slow.count: {enabled: true}). Не удаляйте эту строку: без неё рекомендованный порог по медленным запросам не сработает никогда — метрика просто не будет приходить.

nginx

• Ресивер читает страницу stub_status — включите её в конфиге nginx:

location /status {
    stub_status;
}

• endpoint ресивера в сниппете — http://localhost:80/status; поправьте хост/порт/путь под ваш сервер.

Redis

• password в конфиге соответствует requirepass вашего Redis. Если Redis работает без requirepass — удалите строку password из конфига целиком (пустое значение ресивер не примет за «без пароля»).

Docker

• Ресивер docker_stats читает докер-сокет unix:///var/run/docker.sock — процессу коллектора нужен доступ к нему: запуск от root либо членство в группе docker.

Зачем в конфиге transform

В сниппетах PostgreSQL и Docker есть процессор transform/recipe — он обязателен, не удаляйте его.

Причина: приём Gotcha оставляет из resource-атрибутов только service.name, deployment.environment и host.name, остальные отбрасывает (защита от кардинальности — см. Кардинальность). А ресиверы кладут ключи группировки именно в resource-атрибуты: postgresql-ресивер — имя базы (postgresql.database.name), docker_stats — имя контейнера (container.name; каждый контейнер у него — отдельный Resource). Процессор transform продвигает эти атрибуты в datapoint-атрибуты ещё в коллекторе, до экспорта, — и только поэтому графики «по базам» и «по контейнерам» раскладываются на серии. Уберёте transform — те же графики слипнутся в одну безымянную серию.

У MariaDB, nginx и Redis transform не нужен: всё, по чему группируют их графики (например, state у соединений nginx или kind/operation у метрик MariaDB), — родные datapoint-атрибуты самих метрик.

Допущение: один инстанс сервиса на проект

Рецепт рассчитан на один инстанс сервиса на проект: метрики двух PostgreSQL (или двух nginx, Redis…), приезжающие в один проект без различий в deployment.environment, сольются в одну серию — графики и пороги будут считаться по перемешанным данным. Несколько инстансов одного сервиса разносите по окружениям (resourcedetection/OTEL_RESOURCE_ATTRIBUTES с разными deployment.environment) или по разным проектам.

То же касается и под-ресурсов внутри одного инстанса, а не только инстансов. На одном сервере PostgreSQL обычно живёт несколько баз: графики их различают (группировка по базам), но рекомендованный порог — одно правило по метрике, и, например, порог по дедлокам фактически следит за базой с наибольшим накопленным счётчиком. Для точного порога по конкретной базе раскомментируйте строку databases: в конфиге ресивера и сузьте её до одной базы — либо разнесите базы по проектам. У Docker так же с контейнерами: именно поэтому у его рецепта дефолтных порогов нет вовсе.

Графики

Как только данные приходят, страница рецепта показывает преднастроенные графики — свой набор у каждого сервиса: у PostgreSQL это подключения по базам, транзакции commit/rollback, размер баз, чтение блоков, дедлоки и строки live/dead; у MariaDB — треды (подключённые/активные/в кеше), файловые операции InnoDB, страницы buffer pool, операции со строками и блокировки таблиц; у nginx — запросы в секунду и соединения; у Redis — память, клиенты, hit rate кеша, команды и фрагментация; у Docker — CPU, память и сеть по каждому контейнеру.

Окно графиков фиксированное — последние 24 часа; глобальный выбор диапазона времени на них не действует. У сгруппированных графиков показываются самые крупные группы, остальные скрываются с подсказкой. Ссылка «Открыть в метриках» под графиком ведёт на ту же метрику в разделе Метрики — там доступны произвольный диапазон, агрегации и лейблы.

Пока данных нет, блок графиков не показывается вовсе — до первого экспорта он состоял бы из одних пустых карточек.

Рекомендованные пороги

Внизу страницы — таблица рекомендованных порогов рецепта: метрика, условие, окно, важность, пояснение и статус («Создан» / «Будет создан»). Кнопка «Создать рекомендованные пороги» (оператору) создаёт недостающие одним действием — как обычные правила оповещений по метрикам, дальше они живут на странице /projects/{id}/metrics/alerts: там их можно подстроить под себя или удалить (см. Оповещения по метрикам).

Что при этом важно понимать:

• Пороги на счётчики означают «прирост за окно», а не общее количество: «за 5 минут появились новые дедлоки», не «всего дедлоков больше нуля». Дефолты с порогом 0 ловят любой новый случай.
• Числовые дефолты — отправная точка: 80 подключений PostgreSQL и 120 тредов MariaDB подстройте под ваш max_connections, 1000 соединений nginx — под мощность сервера. Пояснение в таблице у каждого порога говорит, что именно крутить.
• Создание идемпотентно. Правило с той же метрикой, агрегацией, условием и лейблом считается «тем же», даже если вы уже подстроили его порог или окно под себя, — повторное нажатие его не перетрёт и не задублирует, а просто пропустит. Правила создаются на все окружения сразу (поле «Окружение» пустое); ваше правило, скоупленное на конкретное окружение, дефолт не блокирует.
• У Docker рекомендованных порогов нет — его метрики пер-контейнерные, разумного общего дефолта «на все контейнеры разом» не существует. Настройте правила по своим контейнерам вручную на странице оповещений по метрикам, страница рецепта честно говорит об этом.

Инциденты, уведомления, гистерезис восстановления и оценщик у созданных правил — ровно те же, что у любых правил оповещений по метрикам: см. Оповещения по метрикам.

Что дальше

• Метрики — приём OTLP, на котором построены рецепты; детальная страница метрики.
• Оповещения по метрикам — как оцениваются и уведомляют созданные пороги.
• Хосты — системные метрики самих серверов; установка того же коллектора.
• Кардинальность — почему приём оставляет лишь часть resource-атрибутов.