Хабр, привет!

Это история о том, как желание просто проверить, жив ли мой блог, привело к трём дням танцев с бубном вокруг SSL-сертификата, а затем — к созданию собственного сервиса мониторинга, который теперь используют сотни разработчиков. Расскажу, почему существующие решения перестали устраивать, как мы реализовали поддержку UDP и ICMP в облаке и почему мониторинг должен быть «скучным».

Предыстория: как я стал сисадмином мониторинга

Год назад у меня была простая задача: настроить уведомления о падении личного блога и API пары пет-проектов. Думал, уложусь в 15 минут.

Спойлер: не уложился.

Я решил попробовать self-hosted решение — Uptime Kuma. Отличный опенсорс-проект, ничего не скажешь. Но:

1. Нужен был сервер (или хотя бы VPS).

2. Настройка Docker + обратный прокси + Let's Encrypt для статус-страницы заняла вечер.

3. Через месяц пришло обновление, которое сломало совместимость с моей версией Node.js.

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

Боль существующих решений (субъективно, но честно)

Я прошерстил всё, что есть на рынке, и выделил ключевые проблемы.

1. UptimeRobot

Плюсы: Бесплатный порог входа, простой.
Минусы: Алерты приходят с задержкой 5-10 минут. Для продакшна это критично. За 5 минут пользователи успевают уйти к конкурентам, а поисковые боты - задетектить падение. Плюс - только HTTP и TCP. Ни UDP, ни ICMP.

2. Pingdom

Плюсы: Надёжный, много фич.
Минусы: Цена. $20/мес за мониторинг небольшого проекта - жирновато. Кредитка для триала - отдельный раздражитель.

3. Self-hosted (Uptime Kuma, Prometheus + Alertmanager)

Плюсы: Полный контроль, гибкость.
Минусы: Требует инфраструктуры и времени на поддержку. Обновления, безопасность, бэкапы - всё ложится на вас. Если у вас нет выделенного DevOps-инженера, это оверхед.

4. Better Stack

Плюсы: Красивый интерфейс, хорошие интеграции.
Минусы: Ценовая политика. UDP-мониторинг и многие другие «нишевые» фичи - только в дорогих тарифах.

5. Отдельная боль - UDP и ICMP

Большинство SaaS-мониторов вообще не умеют работать с UDP. А если умеют - это enterprise-функция за долларов в месяц.

Зачем вообще нужен UDP-мониторинг?

• Игровые сервера (Minecraft, CS:GO, Rust) - работают поверх UDP.

• DNS-серверы - без UDP они не живут.

• Собственные приложения на UDP (например, syslog-коллекторы, трекеры).

• Просто проверить, отвечает ли хост на ICMP-запросы (ping), чтобы понять, жив ли сервер, даже если веб-сервер упал.

Как мы строили PingZen

Я решил, что хочу инструмент, который:

• не требует моей инфраструктуры;

• поддерживает HTTP, TCP, UDP и ICMP «из коробки»;

• шлёт алерты мгновенно;

• и при этом остаётся бесплатным для небольших проектов.

Так родился PingZen.

Архитектура (кратко)

Мы используем распределённую сеть проверок из нескольких регионов (сейчас AWS + Fly.io), чтобы минимизировать ложные срабатывания и обеспечить глобальный охват.

Как работает UDP-мониторинг:

1. Пользователь указывает хост и порт (например, mc.example.com:25565 для Minecraft).

2. Наш checker формирует UDP-пакет (для Minecraft - специальный handshake-пакет, для DNS - запрос типа A).

3. Если в течение таймаута приходит ответ - сервис жив. Если нет - фиксируем даунтайм.

4. Важно: мы учитываем, что UDP - протокол без гарантии доставки, поэтому делаем несколько ретраев с разных нод, прежде чем подтвердить проблему.

ICMP-мониторинг реализован через сырые сокеты с правами CAP_NET_RAW (в контейнерах это отдельная история, но мы решили).

HTTP(S) и TCP - стандартно, с проверкой кодов ответа, таймаутов и валидацией тела (например, поиск подстроки в JSON-ответе).

Стек технологий

• Бэкенд: Go (микросервисы checker'ов), Node.js (API)

• Брокер сообщений: RabbitMQ (для очередей проверок и алертов)

• База данных: PostgreSQL + TimescaleDB (для хранения временных рядов)

• Кэш: Redis

• Инфраструктура: Docker, Kubernetes, AWS (EC2, EKS), Fly.io

Особенности реализации

1. Мгновенные алерты - никаких батчей. Как только кворум нод подтверждает проблему, событие летит в очередь, откуда его забирают воркеры уведомлений.

2. Поддержка множества каналов - Telegram, Discord, Slack, Webhooks. Мы используем общий интерфейс Notifier, под который можно подписать любой новый канал.

3. Публичные статус-страницы - генерируются статически и раздаются через CDN. Никакой нагрузки на базу. Пользователь может привязать свой домен, мы автоматически выдаём SSL через Let's Encrypt.

Технические детали для интересующихся

Как мы боремся с false positives

У нас есть настройка Confirmation Count - сколько последовательных неудачных проверок с разных нод нужно, чтобы считать сервис упавшим. По умолчанию - 2. Это позволяет отсекать случайные сетевые глюки.

Мониторинг UDP на практике

Чтобы проверить Minecraft-сервер, мы отправляем пакет 0xFE (server list ping) и ждём ответа с описанием сервера. Для DNS - отправляем запрос типа A на google.com и ждём ответ с кодом NOERROR.

JSON-валидация для API

Можно указать JSONPath (например, $.status) и ожидаемое значение (ok). Если ответ не соответствует - монитор падает.

Что дальше

Сейчас PingZen мониторит больше 500 проектов - от портфолио до продакшн-бэкендов. Мы активно собираем фидбек и планируем:

• добавить проверки по GraphQL;

• сделать более глубокую интеграцию с PagerDuty и Opsgenie;

• реализовать «умные» эскалации (если через 5 минут не ответил в Telegram — дублируем в SMS).

Но главное - мы хотим, чтобы сервис оставался простым и полезным.

Сам по себе pingzen.dev бесплатный на данный момент и еще долго будет. Он все еще на стадии разработки. Ноо, уже сейчас можете создать неограниченное количество мониторов и использовать весь функционал. Основа в рабочем состоянии.

Так что, если заинтересованы - это отличная возможность попробовать что-то новое и упростить себе жизнь.

Мне очень интересна обратная связь.

• Что используете для мониторинга сейчас?

• Какие фичи вам реально нужны?

Возможно есть что-то еще ,что я могу сделать чтобы наша жизнь стала чуточку проще :-)

Я отвечу на все вопросы. Спасибо, что дочитали! ?