«Я свой, я агент»: как мы обновили RMON и добавили mTLS для результатов мониторинга

«У меня всё открывается» — прекрасная фраза. В ней есть уверенность, оптимизм и результаты мониторинга ровно из одной точки.

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

Мы развиваем RMON, чтобы такие ситуации было проще замечать и разбирать. Это система мониторинга доступности сайтов, API и сетевых сервисов из разных точек. Вы задаёте, что проверять, откуда и какой ответ считать правильным. Агенты выполняют проверки, RMON собирает результаты, показывает историю и отправляет уведомления.

За последнее время мы заметно обновили продукт: переработали создание проверок и администрирование, добавили контейнерное развёртывание и защищённую передачу результатов с mTLS. Расскажем, что за этим стоит и чем это полезно человеку, которому потом разбираться с красным индикатором

Начнём с самой идеи мониторинга

Допустим, у вас есть API. Проверять, что его сервер отвечает на ping, полезно. Но сервер может исправно отвечать на ping и столь же исправно возвращать пользователям ошибку. У него сегодня такой рабочий процесс.

Поэтому RMON умеет проверять HTTP(S), TCP, Ping, DNS, SMTP и RabbitMQ. Для HTTP можно задать ожидаемый статус и содержимое ответа, следить за временем ответа и сроком действия сертификата. Это позволяет описать более содержательный критерий здоровья: например, API должен отвечать вовремя, возвращать нужный код и ожидаемые данные.

Даже 200 OK заслуживает уточняющего вопроса: «А что именно у вас OK?»

Дальше появляется география. Агенты RMON можно разместить в офисе, дата-центре и внешних сетях, а затем назначить им одну и ту же проверку.

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

Поэтому мы переработали создание и редактирование проверок. Теперь процесс разделён на три шага:

1. Check: что проверяем.

2. Settings: откуда, как часто и с какими условиями.

3. Notifications: кому сообщаем о проблеме.

В обновлённой административной части собраны задачи управления пользователями, серверами и SSH-учётными данными. Добавился корпоративный вход через OIDC, чтобы подключить существующего провайдера идентификации.

Агент может работать на удалённой площадке и отправлять измерения через несколько сетей. Для передачи результатов теперь доступны HTTP, HTTPS и HTTPS с mTLS.

При обычном HTTPS агент проверяет сертификат сервера, а обмен защищается шифрованием. При mTLS — mutual TLS — сервер дополнительно требует клиентский сертификат и проверяет его.

Здесь есть важное уточнение: mTLS для обращения к защищённым сайтам уже поддерживался в HTTP-проверках. Новое применение — защита передачи результатов от агентов к RMON Server. Это отдельное соединение со своими настройками.

Параллельно мы добавили контейнерное развёртывание RMON и его компонентов. Для установки доступны Docker, а также Kubernetes с Helm. Это даёт возможность выбрать привычный для команды способ эксплуатации и отдельно разворачивать приёмник результатов, когда этого требует размещение площадок.

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

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

После настройки вся эта техническая часть должна помогать обычному рабочему процессу: увидеть проблему, понять её масштаб и сообщить нужной команде.

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

Представим итоговый сценарий. Команда следит за API из нескольких площадок. Агенты передают результаты приёмнику по mTLS. При сбое в уведомлении и результатах проверки можно посмотреть, где он наблюдается. В истории — выяснить, когда начался. На статус-странице — показать состояние выбранных сервисов тем, кому нужна эта информация.

Результат такого подхода — больше фактов в начале расследования и понятнее организованная работа с самим мониторингом. Именно ради этого мы обновляем RMON.