Компания в которой я работаю, производит разнообразные веб сервисы. Мы используем как свои собственные разработки, так и всяческие открытые инструменты и фреймворки.
Предисловие вышло длинное, так что кому лень читать, можно перейти сразу к сути.
Классический веб сервис на базе любого распостраненного бекенд-фреймворка, имеет, обычно, несколько внешних вспомогательных систем, от которых он зависит: база данных, какое-нибудь KV хранилище, внешние веб сервисы, например для почтовых рассылок, и так далее.
Когда продукт становится достаточно большим и обслуживает большое количество пользователей, приходит пора масштабирования и наращивания отказоустойчивости. Тогда базы данных и KV хранилища приобретают реплики, а то и шардируются. Внешние хранилища превращаются из простых NFS шар в какие-нибудь распределенные хранилища типа Ceph или GlusterFS. Взаимодействие с внешними сервисами приходится, например, диверсифицировать, подключать три сервиса SMS рассылок вместо одного, на случай если основной ляжет.
Затем, как правило, приходит момент распределения проекта по различным датацентрам, настройка какого-то внешнего DNS сервиса способного простукивать все точки входа и направлять трафик только на живые, реплицировать базы данных не только внутри одного ДЦ, но и как-то выстраивать гео реплики, и так далее, количество челленджей быстро растет. :)
Опять вернемся к первому абзацу: что же делать с мониторингом? Ну понятно, что на первом этапе нам хватало обычного хосттрекера, который начинал теребить админа если сайт становился недоступен. Когда у вас все на одном сервере, найти корень проблемы обычно труда не составляет, хотя и все равно требует, конечно, времени.
Но что будет когда проект разрастается? Дебаг становится все более и более сложным, если понятно что проблема с базой данных, то где именно она кроется - в отваливашейся репликации, или в отсутствии каких-то данных по причине проблем с внешним сервисом? Может быть еще где-то?
Современные системы мониторинга позволяют заранее предвидеть основные проблемы, например Prometheus алертит что места на дисках виртуалок, при текущем темпе заполнения, хватит на сутки. Или что количество 404-х кодов ответа от веб сервиса подозрительно выросло. Или, даже, что лаг репликации базы превышает допустимое значение.
Но гарантирует ли это, например, что репликация работает корректно (она может по какой-то причине не работать, даже при отсутствии определяемого лага) и может обслуживать клиентов? Что данные в таблицы поступают и записи актуальны?
Очень важный (или даже важнейший) фактор мониторинга: некоторые проблемы можно отследить только извне системы. У вас может быть все прекрасно со всеми сервисами на дорогом хостинге в Европе, но пользователи из Сингапура не смогут попасть к вам на сайт, потому что прилегли транзитные каналы Европа-Азия, или на них сильно выросли задержки (частое true story!).
Либо: у вас внезапно кончились деньги на акаунте во внешнем DNS сервисе, и как следствие отвалились его хелсчеки, и он перестал снимать с трафика проблемные ДЦ. А иногда подобные проблемы еще и накладываются друг на друга. :)
Классические монолитные приложения на открытых фреймворках часто не имеют встроенных хелсчеков, а если и имеют, то они не покрывают смежных систем - например баз данных, внешних хранилищ. Да и как дела именно со стороны пользователя, такие хелсчеки в любом случае проверить не смогут.
Для того чтобы быть всегда уверенными что пользователи не испытывают проблем, веб сервисы обвешиваются скриптами, проверяющими их работоспособность. Эти скрипты часто располагаются на какой-то внешней VPS-ке (много ресурсов им не нужно), запускаются по обычному крону, и представляют из себя несколько десятков строчек кода с простейшей логикой вида "если упал вызов курл, шлем алерт через API телеграм".
Те хелсчеки, которые могут быть выполнены только изнутри (например проверка живости репликаций БД) могут располагаться тут же рядом на веб сервере, или в лучшем случае на отдельной виртуалочке в доверенном контуре.
Этот подход хорошо работал много лет, но с ростом количества разнообразных сервисов, выявилось много его (подхода) недостатков.
Отсутствие логики управления оповещениями.
В случае каких-то серьезных проблем начинает валиться толстенный поток оповещений в телеграм, среди которых отследить что-то нужное проблематично.
Как следствие, становится очень сложно разделить оповещения по severity и ответственным лицам. Количество служебных чатов в телеграме просто зашкаливает, например у меня их сейчас с десяток. В них настроены разные политики оповещений, разруливать все это на каждом конкретном клиенте очень сложно. В какой-то момент разработчикам надоедает, они мьютят чат (т.к считают что их то сервис точно не завалится, а если что - админ то никогда не спит), и как результат, при появлении серьезных проблем их может никто не заметить.
Отсутствие единой политики конфигурации оповещений.
Никто никогда не знает достоверно что наворочено в разложенных по куче разных мест хелсчек скриптах, их сложно между собой синхронизировать. Разработчики разных продуктов могут использовать разные каналы оповещений (например слать их к себе в личку в слаке), а со стороны остальной команды и админов в результате не видно целостной картины.
Принципиальное отсутствие средств управления.
Когда понятно что упал весь хостинг, нет смысла видеть все остальные алерты. Приходится обходить все впс-ки и отключать сервис крона, иначе справиться никак с алерт-штормом нельзя. Не стоит и говорить, что включить крон потом забывают, что выливается в кросс-проверки, когда разные впс-ки проверяют друг друга, и алертят, если давно не было срабатываний.
Пока почти все выглядит как задача для Pagerduty (и аналогов), да? :)
Тут тоже кроется несколько проблем:
Все подобные сервисы платные, и довольно недешевые.
Политически сложно заставить всех, в том числе удаленщиков, ставить приложение и корректно его настраивать. Отследить это невозможно. А пакеты смс-ок в этих сервисах очень дорогие (смс-ки представляют хоть какие-то гарантии прочтения).
Эти сервисы не решают проблемы в целом, да они прекрасно умеют управлять непосредственно оповещениями, но вопрос самих хелсчеков и интеграции скриптов с API сервисов остается открытым.
В общем, в какой-то момент звезды сошлись в очень удобное положение: у меня появилось достаточно свободного времени в связи с пандемией и просевшим количеством рутинных задач, и я решил его инвестировать сразу в двух направлениях: попытаться-таки каким-то образом решить давние головные боли с хелсчеками и алертами, и одновременно прокачать свои навыки в программировании. Очень хотелось изучить Golang, который мне виделся прекрасным инструментом для этой задачи. Да и вообще программист я никакой, практика всегда полезна.
Все это вылилось в проект Checker (по-русски я его называю Чекалкой).
Ридми в проекте говорит само за себя, статья и так получилась очень длинной, я признаться, такого не планировал, поэтому постараюсь только вкратце пояснить как я решил описанные выше проблемы.
Итак, Checker статически собирается компилятором Go в один бинарник, и не требует никаких зависимостей. Конкретные алгоритмы проверки реализованы в виде отдельных package-й, и могут быть легко реализоване как новые проверки в рамках текущих классов, так и добавлены совершенно новые классы проверок. К примеру проверки брокеров сообщений (очередей Kafka, RabbitMQ) у меня висят в TODO, но руки до них пока не дошли, т.к. в наших условиях критичных сервисов такого типа пока нет.
Конфигурация проверок описывается в виде yaml/json/hcl/toml файла, который может загружаться из локальной файловой системы, Consul KV/Consul Catalog, S3. Конфиг постоянно мониторится на предмет изменений, и не требует перезапуска для подхвата новой конфигурации.
На данный момент реализованы два канала оповещений: Telegram и Slack/Mattermost (плюс, конечно, логи). Важно то, что Checker не просто отсылает оповещения, но и работает как бот, на оповещения ему можно отвечать, либо отсылать управляющие команды в чат. Таким образом можно заглушить оповещения по конкретной проверке, конкретному проекту, либо вообще все оповещения (проверки все равно проводятся, но результат попадает только в лог). Еще более важно то, что при наличии заглушенных оповещений, Checker периодически отправляет в чат отчет о их наличии. Вы просто не можете забыть "включить кроны". :)
Проблема замьюченных чатов решается опциональным добавлением mention к каждому алерту. Можно перечислить ответственных за проект лиц, и во все алерты связанные с конкретным проектом будет добавляться подзаголовок вида @vasilich @noc-admin.
Для уменьшения потока оповещений от проблемных внешних сервисов реализована логика толерантности, для каждой проверки можно настроить политику срабатываний алертов, и указать, например, что первые 2 срабатывания нужно игнорировать (т.е. только логировать), а собственно алерты прислать начиная с третьего.
Для каждого выполнения каждой проверки формируется уникальный UUID, который может быть отслежен по логу. Каждая проверка логируется и строчки по конкретному выполнению в логе помечаются этим UUID. Также этот UUID присутствует в алерте. Можно его скопировать из чата, и быстро поиском по логам (например в кибане) найти нужный ивент.
Начата реализация механизма акторов, хочется иметь возможность не только отсылать алерты, но и например запускать внешние скрипты или дергать какие-то внешние API, к примеру это позволит выстроить собственное управление DNS зоной и отключение выпавших балансеров.
В Checker встроен экспортер метрик в формате Prometheus, что позволяет дополнительно отслеживать статистику, и, возможно, подключать Alertmanager который обратит внимание на какие-то проблемы самой чекалки.
В конце небольшой disclaimer: я не профессиональный программист, так что уверен на 100%, что в проекте присутствуют архитектурные просчеты и достаточное количество багов, хотя это уже и 4 или 5 итерация переписывания с нуля. :) У меня в эксплуатации утилита уже несколько месяцев, и все критичное что нашлось я зачистил.
Также я понял, что у меня в issue в гитлабе висят несколько десятков открытых issue по новому функционалу (которые я сам же себе и открывал), и объем работы уже несколько превышает мои возможности по свободному времени. Если полировать и дальше в одиночку, то эта история никогда не закончится.
Так что буду благодарен за участие в проекте, если он покажется вам полезным. Как говорится, присылайте ваших PR-ов. :)
Также очень пригодилась бы помощь в переводе Readme на английский. Я по-глупости начал его вести на русском, а такой большой объем с нуля мне не перевести. Сейчас в проекте лежит надмозговый вариант перевода от Google Translate, хотя бы его причесать было бы очень хорошо.
Ну и собсно ссылка на проект: https://github.com/imcitius/checker
Образ на Docker Hub: https://hub.docker.com/r/imcitius/checker
Можно очень просто и быстро запустить себе экземпляр чекалки на Heroku по инструкции, нажав кнопку в Readme.
Бесплатного тарифа Heroku чекалке вполне хватает для работы, но учитывайте, пожалуйста, его ограничения.
