На протяжении трёх лет мне довелось использовать три сервиса для мониторинга сайтов с Enterprise тарифом. Хочу поделиться информацией о некоторых особенностях, на что обратить при работе с API интерфейсом и какие факапы на проде могут себе позволить некоторые из этих сервисов.

Предисловие

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

Все домены, которые требовалось мониторить, юридически принадлежали клиенту, а управляли ими мы. У нас в мониторинге было около ~130 доменов, а у каждого из доменов могли быть около 2-4 эндпоинтов, например, юридические документы и лицензии, которые по требованию лицензиата должны быть в открытом доступе.

Прайс и функционал

Большая часть функционала всех этих сервисов не требовалась, так как была покрыта собственной системой мониторинга. Но требовалась геораспределенная структура, с возможностью проверять наличие key word на странице и возможностью менеджить все мониторы с помощью API интерфейса.

Uptimerobot

Все сообщения о падении сайта мало информативны. Они не несут никакой дополнительно полезной информации, кроме как самого факта падения:

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

Скриншот отчета

Документация API достаточно полноценная. Есть готовые примеры использования для каждого метода на многих языках. Так как проект достаточно старый, на github существуют различные написанные инструменты для работы с API: bash, python(в том числе и ansible).

Про факапы uptimerobot.

Приблизительно в декабре 2022 года они решили выкатить обновления для своего API. Было оно достаточно хорошим. Хорошим для того, чтобы похоронить все мониторы и положить API на одну рабочую неделю. Следовательно, мы остались без мониторинга, а техпод нам говорил лишь одно "Ну если очень надо, вы можете руками вставить все свои ~130 мониторов". По факту это было 7 дней чистого даунтайма. Никто даже не заикнулся в помощи по восстановлению или финансовой компенсации простоя. В общем то уже и не надо.

Hetrixtools

Алерт весьма информативен. Есть возможность скрыть таргет и оставить только имя монитора, если это требуется (например, ссылка слишком длинная или содержит токен). Сразу видна причина падения и локация.

Отчеты содержат ошибки и traceroute по каждой локации.

Скриншот с MTR

Несмотря на хороший и подробный отчет, в Hetrixtools отсутствует возможность посмотреть заголовки или тело ответа во время сработки. Это достаточно важный аспект, который разработчики, по какой-то причине, посчитали эти сведения ненужными.

Про API и факапы

С первого взгляда, может показаться, что API вполне неплохое. В документации все понятно написано и никакого подвоха нет. Ведь это простые запросы на создание или редактирование.

Ха, не тут то было. Ты хочешь создать монитор? Да не вопрос, вот, создавай. Только некоторые пункты редактировать можно только в web интерфейсе. Например, если тебе нужен алерт по изменению DNS записей, то сходи и включи ручками.

Тебе нужно создать не uptime монитор, а black list монитор? Создай. Только для начала перепиши свой скрипт с передачи json body на передачу параметров. И да, мы еще забыли про это сказать в документации(может уже где то и дописали). Да и документация по API выглядит топорно и с примерами, почему то, на PHP, а не на curl.

Реализовано оно на столько же странно, как и документация. Все HTTP операции проводятся POST запросом на разные эндпоинты add/edit/delete.

[В процессе написания статьи наткнулся на API v3 BETA, где они пытаются сделать красиво]

Ещё стоит сказать, что они свои релизы, скорее всего, тестят напрямую на юзерах.

Ситуация №1: Понедельник, утро. Нужно вывести новую пачку эндпоинтов для мониторинга. Вывод падает, не помню точно текст ошибки, но что то вроде unsupported target. Выяснилось, что после обновления API не могла перекодировать символы. Откат не делали, фиксили часов пять.

Ситуация №2: Two mounth later. Понедельник, утро. Ошибка при выводе "Method not available". Пишу в саппорт, пытаюсь доказать, что люди они не очень. Говорят, что все ок, это на моей стороне проблемы. Пробую своим модулем добавить, пробую curl, пробую с другим api ключом(а вдруг) - ситуация одна и та же. Спустя 2 часа пишу еще раз, доказываю на пальцах, что они вообще не правы. Соглашаются. Пофиксить смогли в конце дня.

Имеются некоторые проблемы с процессом вывода для большого количества мониторов(большое количество API вызовов). При деплое изменений на всех мониторах, не смотря на скорость отправки 20 запросов в минуту, изредка может произойти зависание процесса. Фиксится переключением api на relay api.

StatusСake

У алерта в целом похожий стиль с hetrixtools, только ошибка общая, а не по всем выбранным локациям.

Для идеального отчета не хватает только трассировки маршрута. Он содержит код ответа, заголовки, тело и репорт сервер.

Скриншот с отчетом

Хотелось бы рассказать о том, что если юзер не умеет в API, web интерфейс достаточно удобен для массовых действий. Все свои домены можно хранить в текстовом файле и при помощи "Bulk action" создать/отредактировать пачку типовых мониторов.

На счет внешнего вида, мне кажется, что web интерфейс достаточно непонятно воспринимается на первый взгляд. Да и цветовая гамма на любителя, имхо. Хотя все это не важно, главное, чтобы оно работало без сбоев и алертило, ведь это первостепенная задача. Лично я пару раз за месяц захожу на сам сайт.

Web морда

К сожалению, в последнее время я не использовал StatusСake API, а новая версия вышла в сентябре 2022 года, но опыт был лишь крайне положительным. Вся документация хорошо написана. Каких либо серьезных фейлов ранее обнаружено не было.

Важная особенность проверки key word у statuscake: он не видит KW за пределами тега </html>. Это была основная причина отказа от этого сервиса.

P.S. Что там делает KW - это отдельная и очень страшная история.

Немного итогов

Важное о скорости доставки алертов, проверенное на длительном периоде.

Когда сайт падает, самым первым, чаще всего, приходит алерт от Hetrixtools, следом StatusСake, и с задержкой приблизительно в ~1 минуту Uptimerobot.

Uptimerobot могу порекомендовать лишь в том случае, если нужно мониторить uptime для большого количества эндпоинтов. Дешево и сердито.

Hetrixtools - оптимальный вариант, если готовы смириться с топорным API.

У StatusСake много дополнительных возможностей, например, можно шаблонизировать текст сообщений, создавать page speed и domain мониторы. Но тут стоит задаться вопросом, требуется ли вам это, ведь он стоит значительно дороже, но и более качественный, чем предыдущие два.

На этом у меня все. Спасибо за уделенное время.