«У меня всё открывается» — прекрасная фраза. В ней есть уверенность, оптимизм и результаты мониторинга ровно из одной точки.
Проблемы начинаются, когда у коллеги сайт тоже открывается, а у клиентов из другого региона — уже нет. Сервер работает, процесс запущен, график CPU выглядит образцово. Где-то между этими хорошими новостями потерялась возможность пользоваться сервисом.
Мы развиваем RMON, чтобы такие ситуации было проще замечать и разбирать. Это система мониторинга доступности сайтов, API и сетевых сервисов из разных точек. Вы задаёте, что проверять, откуда и какой ответ считать правильным. Агенты выполняют проверки, RMON собирает результаты, показывает историю и отправляет уведомления.
За последнее время мы заметно обновили продукт: переработали создание проверок и администрирование, добавили контейнерное развёртывание и защищённую передачу результатов с mTLS. Расскажем, что за этим стоит и чем это полезно человеку, которому потом разбираться с красным индикатором
Начнём с самой идеи мониторинга
Допустим, у вас есть API. Проверять, что его сервер отвечает на ping, полезно. Но сервер может исправно отвечать на ping и столь же исправно возвращать пользователям ошибку. У него сегодня такой рабочий процесс.
Поэтому RMON умеет проверять HTTP(S), TCP, Ping, DNS, SMTP и RabbitMQ. Для HTTP можно задать ожидаемый статус и содержимое ответа, следить за временем ответа и сроком действия сертификата. Это позволяет описать более содержательный критерий здоровья: например, API должен отвечать вовремя, возвращать нужный код и ожидаемые данные.
Даже 200 OK заслуживает уточняющего вопроса: «А что именно у вас OK?»
Дальше появляется география. Агенты RMON можно разместить в офисе, дата-центре и внешних сетях, а затем назначить им одну и ту же проверку.
Представим, что из дата-центра API доступен, из одной внешней точки тоже, а из другой — таймаут. Это уже повод исследовать конкретный сетевой путь, фильтрацию или доступность сервиса для этой площадки. Если проблема наблюдается сразу из нескольких независимых точек, картина будет другой.
Поэтому мы переработали создание и редактирование проверок. Теперь процесс разделён на три шага:
Check: что проверяем.
Settings: откуда, как часто и с какими условиями.
Notifications: кому сообщаем о проблеме.
В обновлённой административной части собраны задачи управления пользователями, серверами и SSH-учётными данными. Добавился корпоративный вход через OIDC, чтобы подключить существующего провайдера идентификации.
Агент может работать на удалённой площадке и отправлять измерения через несколько сетей. Для передачи результатов теперь доступны HTTP, HTTPS и HTTPS с mTLS.
При обычном HTTPS агент проверяет сертификат сервера, а обмен защищается шифрованием. При mTLS — mutual TLS — сервер дополнительно требует клиентский сертификат и проверяет его.
Здесь есть важное уточнение: mTLS для обращения к защищённым сайтам уже поддерживался в HTTP-проверках. Новое применение — защита передачи результатов от агентов к RMON Server. Это отдельное соединение со своими настройками.
Параллельно мы добавили контейнерное развёртывание RMON и его компонентов. Для установки доступны Docker, а также Kubernetes с Helm. Это даёт возможность выбрать привычный для команды способ эксплуатации и отдельно разворачивать приёмник результатов, когда этого требует размещение площадок.
В документации появились подробные сценарии установки, обновления, резервного копирования и восстановления. При переносе сохраняются важные для эксплуатации вещи: база, конфигурация, ключи приложения и сертификаты.
Успешно запущенный контейнер радует глаз. Восстановленная из резервной копии система радует значительно больше людей.
После настройки вся эта техническая часть должна помогать обычному рабочему процессу: увидеть проблему, понять её масштаб и сообщить нужной команде.
В RMON для этого есть текущие состояния проверок, графики и история, уведомления через привычные каналы и статус-страницы. Повторные попытки и пороги позволяют настроить реакцию под конкретный сервис. Требовательность проверки приходится выбирать осмысленно: слишком терпеливая пропустит важное, слишком нервная превратит чат в радиостанцию.
Представим итоговый сценарий. Команда следит за API из нескольких площадок. Агенты передают результаты приёмнику по mTLS. При сбое в уведомлении и результатах проверки можно посмотреть, где он наблюдается. В истории — выяснить, когда начался. На статус-странице — показать состояние выбранных сервисов тем, кому нужна эта информация.
Результат такого подхода — больше фактов в начале расследования и понятнее организованная работа с самим мониторингом. Именно ради этого мы обновляем RMON.