Собрал SaaS-мониторинг сайтов: движок проверок, биллинг и статус-страницы

Что было

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

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

Что сделали

Продукт спроектирован вокруг подрядчика. Статус-страница выносится на домен клиента, сервисы на ней называются словами клиента – «Оплата», а не prod-lb-03. Отчёт по аптайму уходит клиенту первого числа сам. Инциденты хранятся с причиной и длительностью и работают как доказательство, а не как воспоминание.

Проверок восемь, и каждая отвечает на свой вопрос. Аптайм ловит недоступность. Проверка по ключевому слову – случай, который аптайм пропускает: страница отдаёт 200 OK и показывает ошибку базы. SSL-проверка открывает TLS-соединение и читает сам сертификат: срок, цепочку, соответствие имени. Срок домена спрашивается у реестра напрямую по RDAP с откатом на WHOIS. DNS-проверка ловит и кривую миграцию, и угон домена. Плюс TCP-порт, ping и heartbeat – для ночных задач, у которых нет публичного адреса.

Отдельная работа – сделать так, чтобы алертам можно было верить. Одна неудача не поднимает тревогу: проверка повторяется через тридцать секунд. Перед тем как поверить в сбой, сервис проверяет собственную связность по эталонным хостам. И если одновременно падает больше трети всего, что он наблюдает, – считает виноватым себя: держит алерты и будит собственных операторов. Мониторинг, который будит зря, перестают читать через неделю.

Как устроено технически

WordPress используется как платформа, но продукт – это четыре собственных плагина и тема. Ядро: движок проверок, диспетчер, машина состояний с подтверждением сбоя, инциденты, watchdog самоконтроля, агрегатор статистики, статус-страницы, серверная проверка лимитов, шифрование, очередь уведомлений, окна обслуживания и CLI. Отдельно – аккаунты с двухфакторной аутентификацией и REST API, биллинг на Paddle и слой доставки уведомлений в пять каналов.

Три решения, которые стоили дороже остальных.

Планировщик WordPress отключён намеренно. Он срабатывает только когда кто-то открыл сайт – такое расписание проспало бы любую ночную аварию. Проверки идут из системного крона раз в минуту.

Доступ к платному плану выдаётся только по подписанному вебхуку платёжного провайдера, никогда по редиректу после оплаты: до страницы «спасибо» можно дойти кнопкой «назад» в браузере. Вебхук обязан отвечать 401 на неподписанный запрос – 200 там означал бы, что любой желающий может выдать себе платный план.

Лимиты плана проверяются на сервере при каждом создании монитора, каждой смене интервала и каждом вызове API. Заблокированная кнопка в интерфейсе – вежливость, а не защита: то, что останавливает пользователя только в браузере, не останавливает никого.

Результат

Сервис работает и продаётся по подписке: от бесплатного плана на десять мониторов до пятисот мониторов с командой и SLA-отчётами. Бесплатный план разрешён к коммерческому использованию – им можно вести клиентские сайты, и это заявлено прямо.

Побочный, но не менее важный результат – открытая страница о боте: User-Agent, IP-адреса, инструкции по добавлению в исключения для Cloudflare, Nginx, Apache и Wordfence. Половина ложных срабатываний в мониторинге вообще – это фаервол, отвечающий проверяющему капчей.

Как сервис выглядит для пользователя – на странице Acme Pulse в экосистеме. Что и в каком порядке заводить на клиентском сайте – в отдельном разборе.