"На вкус и цвет все фломастеры разные"). Для небольшой и компании Zabbix нормальный такой комбайн, в котором все есть. Пользовательский интерфейс и его красота/удобство - не главное для системы мониторинга, хотя большинство прельщают цветастые и стильные диаграммы. Графану в этом плане пока никто еще не переплюнул. Но Графана - это не система мониторинга, это лишь средство визуализации данных. Консоль алертов на мой взгляд главный интерфейс системы мониторинга для крупной компании, в которой работает круглосуточная дежурная служба. Под капотом у большинства систем мониторинга похожая начинка. Так что тут дело вкуса и привычки. Для крупных компаний важна возможность кастомизации, масштабирования и интеграции с внешними системами.
Какой-то сумбур. Много лозунгов, общих фраз, перечислений технологий и продуктов давно известных всем, кто занимается мониторингом. То что могло быть интересным, например, как была реализована интеграция с CMDB и Service Desk (какие, кстати продукты использовали?), обогащение и корреляции алертов остались за кадром. Замечания:
Если мониторинг работает только как сервис для команд разработки может получится много маленьких мониторингов не связанных друг с другом. Компания (руководство) не будет иметь общей картины, сколько не накладывай все данные на один дашборд. Группе мониторинга все равно понадобится хотя бы поверхностная экспертиза по работе сервисов, которые ставятся на мониторинг, и формировать обобщенные показатели их здоровья. Ну и разумеется еще нужно контролировать самих разработчиков, чтобы они не завалили ваш мониторинг бесполезными логами, метриками, проверками и алертами - вычищать мусор.
Сами по себе метрики приложений и их временные ряды это первичная сырая информация, которая может быть полезна для разбора уже произошедших сбоев. И это не мониторинг, - скорее это просто самописец или видеокамера. Вы же не будете все их выводить на дашборды, в реальном времени просматривать глазами и определять аномалии? Получится то, что у вас на картинке в самом начале статьи. Нужны автоматические проверки (триггеры) на основе порогов, условий или бейзлайнов, которые формируют алерты, обогащаются и трансформируются в инциденты. Вот это уже будет мониторинг.
Доверять автомату исправлять аварии - порочная практика - рано или поздно "выстрелите себе в ногу". Вообще это не задача мониторинга. Нужно добиваться того, чтобы типовых аварий не было вообще. Авторестарты и "автопинки" пусть делают разработчики сервиса, пока не сумели найти решение корневой проблемы.
Заниматься проактивным мониторингом можно начинать тогда, когда реактивный мониторинг у вас работает на 5 с плюсом. При этом необходима достаточная статистика и аналитика по метрикам и соответствующим сбоям. И надо готовится к тому, что построенная модель предсказания будет ошибаться - будете получать false positive алерты или пропуски сбоев, т.к. работаете с вероятностями. На мой взгляд AI и ML в мониторинге это buzzwords. Т.е. производители многих продуктов заявляют что они обладают такой функциональностью скорее для того, чтобы продвинуть свой продукт на рынке. То что они называют ML может быть далеко от классического понимания этого термина, и на практике оказывается какими-нибудь параметризованными детерминированными зависимостями или простыми бейзлайнами.
Автоматические ежемесячные отчеты по потреблению электроэнергии, если установлены электросчетчики. Также создаем отчеты по климату для некоторых клиентов.
Выгрузки сырых данных по энергопотреблению в стойках и датчикам температуры/влажности - по запросу клиента.
У нас два кластерных ресурса DRBD dr_inst{1,2}_ms в режиме master/slave, где для ресурса dr_inst1_ms мастером является хост node-1, а для dr_inst2_ms хост node-2. На них и работают инстансы Nagios. В split brain не уходили. Во всяком случае мне об этом неизвестно. Наши администраторы Linux помогали настраивать кластер.
Вопрос еще в стоимости решения. У NFC расстояние взаимодействия между меткой и считывателем порядка 10 см. Один юнит это примерно 4,5 см. Т.е. ридер должен стоять на каждом втором юните. Итого ~20 ридеров на стойку. Что будет дешевле: поставить в каждую из 5000 стоек по 20 NFC ридеров, или нанять еще десяток дежурных инженеров для проведения регулярных инвентаризаций?)
И да, всю инфраструктуру из считывателей и меток нужно еще обслуживать.
Спасибо за идею. Да, на монтажном профиле можно установить сенсоры и поюнитово пронумеровать их. Как только устанавливается оборудование, соответствующий сенсор замыкается. Данная информация передается дежурному. Остается еще задача автоматизации определения id установленного оборудования.
Если все процедуры и регламенты четко исполняются, то проблем нет. Но это все ручная работа и всегда есть человеческий фактор. Хотелось бы разгрузить наших дежурных инженеров, а также повысить достоверность и полноту данных в CMDB за счет автоматизации рутинных процедур.
Приветствую! А почему не воспользовались Veeam REST API? Почему решили из БД брать данные? API хорошо задокументирован на сайте вендора.
"На вкус и цвет все фломастеры разные"). Для небольшой и компании Zabbix нормальный такой комбайн, в котором все есть. Пользовательский интерфейс и его красота/удобство - не главное для системы мониторинга, хотя большинство прельщают цветастые и стильные диаграммы. Графану в этом плане пока никто еще не переплюнул. Но Графана - это не система мониторинга, это лишь средство визуализации данных. Консоль алертов на мой взгляд главный интерфейс системы мониторинга для крупной компании, в которой работает круглосуточная дежурная служба.
Под капотом у большинства систем мониторинга похожая начинка. Так что тут дело вкуса и привычки. Для крупных компаний важна возможность кастомизации, масштабирования и интеграции с внешними системами.
Какой-то сумбур. Много лозунгов, общих фраз, перечислений технологий и продуктов давно известных всем, кто занимается мониторингом. То что могло быть интересным, например, как была реализована интеграция с CMDB и Service Desk (какие, кстати продукты использовали?), обогащение и корреляции алертов остались за кадром. Замечания:
Если мониторинг работает только как сервис для команд разработки может получится много маленьких мониторингов не связанных друг с другом. Компания (руководство) не будет иметь общей картины, сколько не накладывай все данные на один дашборд. Группе мониторинга все равно понадобится хотя бы поверхностная экспертиза по работе сервисов, которые ставятся на мониторинг, и формировать обобщенные показатели их здоровья. Ну и разумеется еще нужно контролировать самих разработчиков, чтобы они не завалили ваш мониторинг бесполезными логами, метриками, проверками и алертами - вычищать мусор.
Сами по себе метрики приложений и их временные ряды это первичная сырая информация, которая может быть полезна для разбора уже произошедших сбоев. И это не мониторинг, - скорее это просто самописец или видеокамера. Вы же не будете все их выводить на дашборды, в реальном времени просматривать глазами и определять аномалии? Получится то, что у вас на картинке в самом начале статьи. Нужны автоматические проверки (триггеры) на основе порогов, условий или бейзлайнов, которые формируют алерты, обогащаются и трансформируются в инциденты. Вот это уже будет мониторинг.
Доверять автомату исправлять аварии - порочная практика - рано или поздно "выстрелите себе в ногу". Вообще это не задача мониторинга. Нужно добиваться того, чтобы типовых аварий не было вообще. Авторестарты и "автопинки" пусть делают разработчики сервиса, пока не сумели найти решение корневой проблемы.
Заниматься проактивным мониторингом можно начинать тогда, когда реактивный мониторинг у вас работает на 5 с плюсом. При этом необходима достаточная статистика и аналитика по метрикам и соответствующим сбоям. И надо готовится к тому, что построенная модель предсказания будет ошибаться - будете получать false positive алерты или пропуски сбоев, т.к. работаете с вероятностями. На мой взгляд AI и ML в мониторинге это buzzwords. Т.е. производители многих продуктов заявляют что они обладают такой функциональностью скорее для того, чтобы продвинуть свой продукт на рынке. То что они называют ML может быть далеко от классического понимания этого термина, и на практике оказывается какими-нибудь параметризованными детерминированными зависимостями или простыми бейзлайнами.
Да, такие возможности есть. Варианты:
Автоматические ежемесячные отчеты по потреблению электроэнергии, если установлены электросчетчики. Также создаем отчеты по климату для некоторых клиентов.
Выгрузки сырых данных по энергопотреблению в стойках и датчикам температуры/влажности - по запросу клиента.
Общие данные по дата-центру на странице и в мобильном приложении:
https://www.dtln.ru/tsods-online/ost1
У нас два кластерных ресурса DRBD dr_inst{1,2}_ms в режиме master/slave, где для ресурса dr_inst1_ms мастером является хост node-1, а для dr_inst2_ms хост node-2. На них и работают инстансы Nagios. В split brain не уходили. Во всяком случае мне об этом неизвестно. Наши администраторы Linux помогали настраивать кластер.
И да, всю инфраструктуру из считывателей и меток нужно еще обслуживать.