Пришло письмо от читателя по имени Денис по форме обратной связи. Поскольку никаких данных для связи с ним Денис не оставил, отвечу здесь.

Привожу письмо полностью (надеюсь, автор не против):

Александр, здравствуйте! Не смог найти вашу электропочту, пишу через форму обратной связи вашего домена на рег.ру :)

С огромным удовольствием читаю твой блог, очень жаль, что больше не обновляешь его.

Помоги, пожалуйста, советом. У меня примерно 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, или каким-то более продвинутым плагином с exchange.icinga.com. Можно конечно и обычный Nagios использовать, но Icinga2 умеет из коробки писать результаты проверок в Graphite, который у Дениса уже есть.

Идея с микросервисом, отсылающим данные в statsd, мне не нравится, так как polling на таких масштабах сильно проще, его проще тестировать и проверять из любого места, и микросервису не нужно знать ничего про сервис монторинга - это сильно упрощает конфигурирование. Если хочется собирать данные на уровне микросервиса (инструментировать) - можно посмотреть в сторону Prometheus, так как в любом случае нужно что-то, что будет реагировать на отсутствие heartbeat от сервиса.

Time-series DB для такой задачи подходит нормально, а elasticsearch в любом случае было бы отлично прикрутить для логов. К тому же с ним можно использовать Packetbeat для того же мониторинга (если нагрузка небольшая, конечно).

Ну и немного о том, почему я давно ничего тут не пишу. Дело в том, что в любой крупной IT-компании типа Google/Facebook/Amazon/Mail.RU/Yandex бо́льшая часть инфраструктуры своя, а решаемые задачи в силу масштабов не сильно интересны нормальным компаниям и стартапам. Кроме того, трудовой договор подразумевает согласование любых открытий кода с юристами (что совершенно логично). Так что этот блог я пытаюсь преобразовать в более персональный - пока без особого успеха, как можно заметить.


Comments

comments powered by Disqus