Комментарии 19
Что-то при перечислении API забыли Zabbix. А у него тоже есть.
Оченно полезная штука, когда надо сверить настройки хостов и макросов заббикса и данные из NetBox, например (у которого тоже API).
Много важных и интересных формулировок. Однозначно беру на вооружение. Теперь эта статья будет в моих заметках на равных с "Мониторинг мёртв? — Да здравствует мониторинг" :)
Не нашёл в тексте ответа, поэтому спрошу здесь.
Сколько помню, проблема была в том, что разные подразделения всегда отвечали исключительно за свои домены: клиентские сервисы (b2c, b2b, b2o), телеком-инфраструктура, ИТ-инфраструктура, OSS, BSS... И в каждом домене всегда были свои инструменты мониторинга. Сделать сквозной мониторинг было большой организационной проблемой. Это особенность большинства российских операторов связи.
Вы в статье рассказали о мониторинге сервисов в рамках какого-то из доменов, или вы сделали единую платформу мониторинга инфраструктуры, приложений и сервисов в рамках всего оператора? Какие сервисы вы сейчас мониторите таким образом?
Добрый день
В этом и был смысл, уйти от доменов и понятий, а сделать мониторинг общедоступным и понятным, с акцентом на то, какие сервисы и клиенты, которые пользуются этим сервисом, пострадали.
Сделана единая платформа мониторинга сервисов в рамках оператора. Мониториться в ней будут все клиентские сервисы
То, что вы видите в будущем очень похоже на AIOps и зонтичный мониторинг с сильной автоматизацией. Уже смотрите в сторону каких-нибудь вендоров?
Да. Мы делаем зонтичный мониторинг с очень сильной автоматизацией. Вендоры к нам уже приходили и приходят, но если год назад мы смотрели на их решения открыв рот, сейчас такого нет. Да, с одной стороны они дадут "все в одной коробке", но то, что мы научились и можем делать сейчас - не так уж и сильно отличается от коробочных решений. Зато за нами большая свобода с точки зрения автоматизации.
Мило, разогнать весь техблок передать на аутсорс, а потом обнаружить что оборудование кому-то нужно настраивать, мониторить и обслуживать...а после этого упорно искать сотрудников и обратно строить команду техблока - поэтому вы ребята и в попке не в тройке лидеров.
Какой-то сумбур. Много лозунгов, общих фраз, перечислений технологий и продуктов давно известных всем, кто занимается мониторингом. То что могло быть интересным, например, как была реализована интеграция с CMDB и Service Desk (какие, кстати продукты использовали?), обогащение и корреляции алертов остались за кадром. Замечания:
Если мониторинг работает только как сервис для команд разработки может получится много маленьких мониторингов не связанных друг с другом. Компания (руководство) не будет иметь общей картины, сколько не накладывай все данные на один дашборд. Группе мониторинга все равно понадобится хотя бы поверхностная экспертиза по работе сервисов, которые ставятся на мониторинг, и формировать обобщенные показатели их здоровья. Ну и разумеется еще нужно контролировать самих разработчиков, чтобы они не завалили ваш мониторинг бесполезными логами, метриками, проверками и алертами - вычищать мусор.
Сами по себе метрики приложений и их временные ряды это первичная сырая информация, которая может быть полезна для разбора уже произошедших сбоев. И это не мониторинг, - скорее это просто самописец или видеокамера. Вы же не будете все их выводить на дашборды, в реальном времени просматривать глазами и определять аномалии? Получится то, что у вас на картинке в самом начале статьи. Нужны автоматические проверки (триггеры) на основе порогов, условий или бейзлайнов, которые формируют алерты, обогащаются и трансформируются в инциденты. Вот это уже будет мониторинг.
Доверять автомату исправлять аварии - порочная практика - рано или поздно "выстрелите себе в ногу". Вообще это не задача мониторинга. Нужно добиваться того, чтобы типовых аварий не было вообще. Авторестарты и "автопинки" пусть делают разработчики сервиса, пока не сумели найти решение корневой проблемы.
Заниматься проактивным мониторингом можно начинать тогда, когда реактивный мониторинг у вас работает на 5 с плюсом. При этом необходима достаточная статистика и аналитика по метрикам и соответствующим сбоям. И надо готовится к тому, что построенная модель предсказания будет ошибаться - будете получать false positive алерты или пропуски сбоев, т.к. работаете с вероятностями. На мой взгляд AI и ML в мониторинге это buzzwords. Т.е. производители многих продуктов заявляют что они обладают такой функциональностью скорее для того, чтобы продвинуть свой продукт на рынке. То что они называют ML может быть далеко от классического понимания этого термина, и на практике оказывается какими-нибудь параметризованными детерминированными зависимостями или простыми бейзлайнами.
Спасибо за комментарий
Естественно, что мониторинг ради мониторинга никому не нужен. Интеграция с ServiceDesk есть. При этом инциденты заводятся не просто "куда-то", а на тех специалистов, которые могут решить конкретную проблему (это уже наши наработки в рамках INC mngm). И эти инциденты обогащаются той информацией, которая помогает администраторам их быстро решить. CMDB и INC - на базе продуктов BMC. И это работает и из Zabbix'a и из Grafana. Поэтому широко используются API
Мы строим все вокруг ресурсно-сервисного подхода, когда с помощью триггеров, зависимостей и порогов автоматически создаются и маршрутизируются инциденты на администраторов. А администраторы знают, что с этими инцидентами делать. Это уже внутренние процессы, которым следуют
Более того, мы рекомендуем в мониторинг и не смотреть (ну кроме уже совсем критичных сервисов), как раз пороги и алерты в этом помогают. Надо на алерты реагировать, а не на графики смотреть
Про инциденты, обогащение, возможно, будет в следующий раз :)
Почему, почему мистер Андерсон? Почему вы используете Zabbix?
Никогда не понимал людей, которые его пользую. Он же жутко неудобный. Люди, посмотрите на тот же Zenoss, вот так должен выглядить интерфейс мониторинга, а не эта мешанина из вкладок с отдельными вкладками: список устройств, события, графики, дашбоарды. Благо вроде как в современной версии они от выпадающих списков избавились- это прям совсем днище.
Все вышесказанное ИМХО, не навязываю.
Zabbix бесплатный и жутко расширяемый (в плане мониторинга всяческих нестандартных штук). Ну и масштабируемый.
Конечно, бесплатность во многом кажущаяся, так как нормальный администратор Zabbix, который может запустить и поддерживать мониторинг с миллионами элементов данных и десятками тысяч хостов (+вменяемые админы в подразделениях, которые не мониторят вообще всё, что хост может отдать) стоит вполне себе приличных денег.
И Zabbix-ом можно мониторить адскую помесь ужа и ежа, приправленную жабой, были бы люди, понимающие, какие данные важны, а какие - нет. А красивыми и умными решениями с искусственным интеллектом эффективно можно мониторить, ИМХО, достаточно типовые решения (а в случае давно живущей инфраструктуры надо либо приводить её к каноническому виду, либо мониторить только недавно сделанный по фэн-шую кусок; то и другое плохо, каждое по-своему). Или платить вендору за доработку. И будет ли этот вендор через 10 лет, когда парк железа и софта обновится и перестанет поддерживаться?
"На вкус и цвет все фломастеры разные"). Для небольшой и компании Zabbix нормальный такой комбайн, в котором все есть. Пользовательский интерфейс и его красота/удобство - не главное для системы мониторинга, хотя большинство прельщают цветастые и стильные диаграммы. Графану в этом плане пока никто еще не переплюнул. Но Графана - это не система мониторинга, это лишь средство визуализации данных. Консоль алертов на мой взгляд главный интерфейс системы мониторинга для крупной компании, в которой работает круглосуточная дежурная служба.
Под капотом у большинства систем мониторинга похожая начинка. Так что тут дело вкуса и привычки. Для крупных компаний важна возможность кастомизации, масштабирования и интеграции с внешними системами.
Вы бесспорно правы, вкусы у всех разные. Ну просто я никогда не понимал этой логики и людей которые это терпят.
Вот есть у меня устройство, в одной вкладке я вижу что там есть проблема на нем. Чтобы мне посмотреть мне какой-то график по этому устройству, мне нужно перейти на совсем другую вкладку и там а выпадающем списке найти нужный мне элемент.
Ну неужели только я вижу, что подход когда все элементы привязаны к устройству, а не размазаны по инт-су - самый логичный.
Мне просто кажется что Заббикс просто популярный, люди которые видели Zenoss или NetXMS, никогда не смогут понять логику Заббикса :)
Стоимость решения для компании (TCO). Сравните количество информации по Zabbix, готовых решений и всего прочего (да и просто количество упоминаний) с аналогичными показателями по Zenoss. Каждый второй инженер сталкивался с Zabbix, а вот сколько людей с Zenoss?
Для визуализации нужно(можно) использовать Grafana - это гораздо более эффективное средство для любого мониторинга
Zabbix очень динамично развивается. Посмотрите на путь, который они прошли за последние 3-4 года - это просто пропасть по функционалу продуктов и удобству
В самом мониторинге обычно смотрят критичные алерты/историю, а оповещение - это уже телега/почта/звонки
Такие были надежды, а тут... Краткое содержание - "У нас не было мониторинга, нам было плохо. Сделали базовый - стало лучше. Сделали хороший - стало совсем хорошо. Собираемся сделать мониторинг крутым чтобы было совсем круто!"
сколько хостов/метрик на мониторинге у вас сейчас? какая СУБД под ногами у Zabbix? как ведется учет заказанных хостов и метрик, которые стоят на мониторинге?
Как не работало нормально так и не работает. Отказались от Билайна и на коропративном уровне (интернет и сотовая связь), так и на личном (домашний инет, сотовая). Хуже сервис надо еще поискать.
Как мы мониторим наши сервисы