Как случайно написать систему мониторинга (еще одну)
Интересно как-то у меня выходит — мои пет проекты получаются случайно. Нет финальной цели, есть только импульс: «О! А это звучит интересно, как же это можно сделать?». И все: «сон для слабаков», «пиво в пятницу? конечно не буду!» и все в таком духе. Как говорится — есть только путь. И это история началась примерно так же… Вечерело На работе мне было нечем заняться, нужно было поставить некоторое количество серверов и сервисов на мониторинг, но из-за большой бюрократии в компании сделать это было не просто, да и сама мониторинговая система работала на базе SNMP, вот только где взять SNMP у самописного сервиса? И тут в голову пришла гениальная идея попробовать самому. К тому же сложным это не выглядело: мониторинг портов, http и куда-нибудь отправить алерт. «Почему бы и не да» — подумал я, к тому же больше познаю Python. И так появился он…
Простенький мониторинг, который как-то, что-то делает, что-то показывает и даже консольная тулза есть:
Спустя пару лет я вспомнил о том, что у меня был самопальный мониторинг и почему бы его не добавить в мой основном пет проект, в Roxy-WI. Сказано — сделано. Ведь чем больше функций тем лучше! И так получилось, что со временем мониторингу стало «тесно» в стенах Roxy-WI: с одной стороны надо развивать веб интерфейс, с другой мониторинг, чтобы не было перевеса в одной из сторон я решил вынести мониторинг в отдельный проект. Приветствуйте — RMON! Да… с именами у меня так себе.
RMON история проверок
Пф… еще один мониторинг, какой уже по счету?
100500? Да, пожалуй так, так же наверное говорили про Prometheus в свое время: «Зачем ведь есть Zabbix?!», а до этого и про Zabbix: «Зачем ведь есть SNMP, MRTG и Nagios?!». Да, есть, но почему нет? Вдруг получится сделать в чем-то лучше. Конечно я пока не ставлю RMON в ряды с этими системами мониторинга, пока не ставлю. А вдруг получится сделать чем-то лучше;)?
В чем я вижу «конкурентное преимущество» RMON над существующими системами мониторинга, прежде всего над Prometheus (как промышленный стандарт) и Uptime Kuma (как более близкий по функционалу)? Основным, киллер фичи, как по мне их минимум пять:
Агенты — можно установить несколько штук как внутри периметра, так и снаружи и мониторить доступность из нескольких точек. Агенты можно объединять в «регионы» для балансировки чеков, шарить между группами.
API.
Ролевая модель доступа к агентам.
Простота установки и настройки, Web интерфейс и Status pages.
7 метрик HTTP соединения + мониторинг протухания SSL серта.
RNON Status page
Мы все это уже видели
Да, агенты по сути реализованы в Prometheus и Blackbox exporter: Blackbox exporter-ы тоже можно поставить в разных точках и мониторить от туда, ± тоже самое. Да, Uptime Kuma даже легче поднимается и тоже имеет web интерфейс. API можно заменить тем же Ansible, например. Но есть одно, но — этого нет и там и там. Нельзя отдать playbook человеку и сказать: «Вон на тех экспортерах ничего не создавай, тебе низя!», надо будет поднимать несколько инстансов, чтобы разделить доступ, плюс его надо обучить работать с Ansible. А еще нельзя автоматизировать работу с проверками. Точнее скорей всего можно, но это костыли и высокий уровень входа.
Как итог и тем кто будет писать: «Web отстой, консоль наше все!»
Да, временами так и есть, а временами — нет. Порой даже самые передовые и технологически правильные решения не подходят. Где-то жалко тратить время и ресурсы, где-то неохота погружаться, а где-то надо «через 2 минуты, чтобы все было». А временами передовые решения просто не нужны и удобней работать с тем что попроще. Надо исходить из конкретной ситуации, а не загонять всех в рамки:»%UserName%, используй только %ProgrameName% во всех случаях жизни!».
P.S. если захотите попробовать, то пишите, с удовольствием покажу/объясню :).
