Пришло письмо от читателя по имени Денис по форме обратной связи. Поскольку никаких данных для связи с ним Денис не оставил, отвечу здесь.
Привожу письмо полностью (надеюсь, автор не против):
Александр, здравствуйте! Не смог найти вашу электропочту, пишу через форму обратной связи вашего домена на рег.ру :)
С огромным удовольствием читаю твой блог, очень жаль, что больше не обновляешь его.
Помоги, пожалуйста, советом. У меня примерно 12 виртуальных серверов с небольшими микросервисами, на каждом из серверов поставил CollectD и StatsD, плюс на отдельном сервере развёрнул go-carbon - whisper - graphite-api - Grafana.
Сейчас хочу как-то опрашивать эти микросервисы извне (HTTP, HTTPS) и мониторить коды их ответов (200 - всё хорошо, иной ответ - всё плохо, нужно алертить по смс). Как это лучше сделать? Первое, что мне пришло в голову - написать свой костыльный bash-скрипт, который будет по очереди все нужные эндпоинты опрашивать и в go-carbon->whisper пулять… Второе, что пришло в голову - опять же написать свой костыльный плагин к CollectD :)
Но очень не хочется переизобретать велосипед, наверняка же есть какие-то удобные готовые инструменты для этого? Что для данной задачи использовать? Nagios, Icinga2, Zabbix, Sensu, что-то другое?
Я правильно понимаю, что для этой задачи time-seried БД подходит плохо, т.к. длительность ответа микросервиса всегда немного разная и очень трудно настроить задержку (sleep) в том же bash-скрипте, чтобы попасть ровно одним реквестом в каждый агрегируемый интервал 10 сек для collectd/whisper. Т.е. лучше опрашивать не строго через каждые 10 сек, а неважно через какие промежутки, можно даже не совсем одинаковые (плюс-минус пара секунд), но для ответов использовать ещё какое-то хранилище аварийных events? Если да, то какое? Elasticsearch ещё прикрутить и из него в графану дашборд для алертинга?
P.S.: наверное, лучше всего чтобы сам микросервис коды ответов на реквесты в StatsD отсылал? но вопрос именно про готовый внешний “проверяльщик” здоровья системы, чем бы воспользовался лично ты для решения такой задачи?
Я бы для решения подобной задачи не стал городить велосипеды, а воспользовался бы Icinga2 с плагином check_http из пакета Nagios-plugins, или каким-то более продвинутым плагином с Icinga exchange. Можно конечно и обычный Nagios использовать, но Icinga2 умеет из коробки писать результаты проверок в Graphite, который у Дениса уже есть.
Идея с микросервисом, отсылающим данные в StatsD, мне не нравится, так как polling на таких масштабах сильно проще, его проще тестировать и проверять из любого места, и микросервису не нужно знать ничего про сервис монторинга - это сильно упрощает конфигурирование. Если хочется собирать данные на уровне микросервиса (инструментировать) - можно посмотреть в сторону Prometheus, так как в любом случае нужно что-то, что будет реагировать на отсутствие heartbeat от сервиса.
Time-series DB для такой задачи подходит нормально, а Elasticsearch в любом случае было бы отлично прикрутить для логов. К тому же с ним можно использовать Packetbeat для того же мониторинга (если нагрузка небольшая, конечно).
Ну и немного о том, почему я давно ничего тут не пишу. Дело в том, что в любой крупной IT-компании типа Google/Facebook/Amazon/MailRU/Yandex бо́льшая часть инфраструктуры своя, а решаемые задачи в силу масштабов не сильно интересны нормальным компаниям и стартапам. Кроме того, трудовой договор подразумевает согласование любых открытий кода с юристами (что совершенно логично). Так что этот блог я пытаюсь преобразовать в более персональный - пока без особого успеха, как можно заметить.