Мониторинг без лишних хлопот: как мы заменили Uptime Kuma собственным SaaS‑сервисом с поддержкой UDP и ICMP

Почему готовые решения перестали работать

Для большинства небольших проектов достаточно простого «ping»‑проверки доступности сайта. Однако в реальном рабочем процессе появляются требования, которые не укладываются в рамки типовых инструментов. Первоначальная попытка использовать Uptime Kuma выявила три фундаментальные проблемы:

1. Непрозрачное управление SSL‑сертификатами – каждый раз, когда сертификат менялся, приходилось вручную обновлять конфигурацию, что приводило к ошибкам и простоям. Автоматическая проверка статуса сертификата в Uptime Kuma была ограничена только HTTPS‑эндпоинтами, без возможности гибкой настройки.

2. Отсутствие нативной поддержки протоколов уровня сети – большинство сервисов ориентированы на HTTP/HTTPS. При необходимости мониторить UDP‑службы (например, DNS, SNMP) или проверять ICMP‑ответы (обычный ping) приходилось прибегать к «обходным» скриптам, что ухудшало читаемость конфигураций и повышало нагрузку на сервер мониторинга.

3. Неудобный пользовательский интерфейс при масштабировании – при росте количества проверок (сотни до тысяч) администрирование через веб‑UI становилось медленным, а экспорт данных – громоздким. Для CI/CD‑интеграций требовались API‑эндпоинты, которые в Uptime Kuma были ограничены.

Эти ограничения заставили искать альтернативу, способную обслуживать крупные инфраструктурные проекты без лишних «танцев с бубном».

Архитектурный подход к собственному сервису

Для решения обозначенных проблем была разработана облачная платформа мониторинга, построенная на микросервисной архитектуре. Ключевые компоненты:

Все сервисы упакованы в Docker‑контейнеры и оркестрируются Kubernetes, что обеспечивает горизонтальное масштабирование и автоматическое восстановление при сбоях. Важным решением стало использование raw sockets для UDP и ICMP‑пакетов, позволяющее выполнять запросы без привлечения сторонних утилит (например, ping или nc). Это упрощает контроль над тайм‑аутами, размером пакетов и обработкой ответов.

Реализация поддержки UDP и ICMP в облаке

UDP‑проверки

Для UDP‑мониторинга был реализован модуль, способный отправлять произвольные байтовые payload‑ы и ожидать ответ в виде любого пакета от целевого сервера. Конфигурация включает:

• Target address (IP/hostname + порт)
• Payload (hex‑строка или шаблон)
• Expected response pattern (регулярное выражение)
• Timeout (по умолчанию 3 сек)

Модуль использует net.UDPConn с установленным ReadDeadline. При получении ответа сравнивается фактический payload с ожидаемым шаблоном, что позволяет мониторить, к примеру, DNS‑серверы, RTP‑потоки или собственные UDP‑протоколы.

ICMP‑пинг

Для ICMP была выбрана библиотека golang.org/x/net/icmp, позволяющая формировать запросы типа Echo Request и обрабатывать Echo Reply. Особенности реализации:

• Поддержка IPv4 и IPv6 – автоматическое определение типа адреса.
• Настройка размера пакета – полезно для проверки фрагментации.
• Распределение нагрузки – каждый агент может выполнять до 1000 пингов в секунду, благодаря неблокирующей обработке событий.

ICMP‑проверки собирают метрики RTT (round‑trip time), потери пакетов и вариацию задержки, которые сохраняются в TimescaleDB для построения графиков и аналитики.

Автоматизация управления SSL‑сертификатов

Встроенный TLS‑валидатор периодически запрашивает сертификат по HTTPS и проверяет:

• Дату истечения (NotAfter)
• Полную цепочку доверия (корневой, промежуточный)
• Соответствие доменов в SAN

При приближении к окончанию срока действия сервис генерирует предупреждение в системе алертов и автоматически обновляет конфигурацию мониторинга, если используется автоматический сертификат (например, Let's Encrypt). Это устраняет необходимость ручного вмешательства при каждой ротации сертификата.

Пользовательский опыт и интеграция

Интерфейс позволяет создавать проверки за несколько кликов: выбираете тип (HTTP, TCP, UDP, ICMP), указываете цель, задаёте параметры и сохраняете. Для массовой миграции из Uptime Kuma предусмотрен импорт в формате JSON, который автоматически конвертирует старые конфигурации в новую схему.

API‑слой поддерживает:

• Создание/удаление проверок (POST/DELETE /checks)
• Получение текущих статусов (GET /checks/:id/status)
• Запрос исторических данных (GET /metrics?check_id=...&range=24h)

Эти эндпоинты легко интегрировать в CI/CD‑пайплайны, позволяя, к примеру, блокировать деплой, если критический сервис недоступен.

Масштаб и применение

С момента запуска сервисом уже пользуются более 300 компаний, а суммарное количество проверок превышает 150 000 в сутки. Среднее время отклика системы — менее 150 мс, даже при пиковой нагрузке. Благодаря контейнеризации и Kubernetes‑орчестрации платформа выдерживает рост до нескольких миллионов проверок без деградации производительности.

Выводы из разработки собственного мониторинга

Создание собственного SaaS‑решения оказалось оправданным шагом: гибкость настройки UDP и ICMP, автоматическое управление SSL‑сертификатами и масштабируемый API существенно упрощают эксплуатацию инфраструктурных сервисов. При этом микросервисный подход обеспечивает надёжность и возможность быстрых улучшений без влияния на конечных пользователей. Такой подход позволяет сконцентрироваться на бизнес‑логике, а не на «болячках» готовых мониторов, делая процесс наблюдения действительно «скучным», то есть предсказуемым и без лишних сюрпризов.