Было бы здорово получить ответ в виде коммента. Ниже будет мое видение ситуации.
Собственно на эти размышления меня натолкнуло чтение книги Дж. Паттона «Пользовательские истории, Искусство гибкой разработки ПО», до этого я злился и смутно представлял как должно это работать. Теперь же начал складываться сюжет и начнём мы его с пользовательских историй глазами нескольких участников процесса сопровождения и эксплуатации сети.
Администратор сети:
Моя работа начинается: если мне прилетел отчёт о отказе узла связи
Зачем я туда лезу?: мне нужно понять какой узел в моей трёхуровневой сети умер и мне не важно есть ли ведомые девайсы за точкой отказа.
Что я вижу?: — вижу пачку алертов, из которых один с повышенной привилегией — ага узел агрегации…
Случай с деградацией каналов связи отдельная история, Всем тем кто на себе знает про явление флуда после грозы жму руки )… точка отказа не известна, нужно выявить косвенные приметы, сработал loopdetect или storm control нагрузка на CPU или интерфейс полезла в пиковые значения.
В общем мне не нужны красивые графики, мне нужно работающее дерево коммутаторов и алерты которые точно прилетят, а ещё я не имею никакого желания знать про то, что ветка дерева коммутаторов отвалилась, Что я хочу видеть?: мне нужен только узел до которого всё хорошо, а после плохо.
Что я собираюсь с делать с этой информацией?: позвоню в городские электросети, затем отправлю техгруппу. Важно то чем быстрее я локализую проблему, тем быстрее можно будет принять меры по устранению.
Помогает мне в этом Zabbix? Конечно да, но избыточная информация и необходимость выписывать дерево через конфиг заббикса утомляют.
Техническая поддержка по телефону:
Моя работа начинается в момент поступления звонка от абонента. Я имею доступ к системе мониторинга и мне приходится просматривать события в zabbix чтоб понять с чем пришёл клиент и с какой стороны абонентского кабеля проблема.
Помогает мне Zabbix? конечно да, но мне нужен список отказов оборудования, и вот ещё момент, вы видели как быстро меняется этот список в моменты великого флуда...?
Мне было бы легче получая звонок иметь всю информацию о точке подключения абонента с точностью до порта и не тратить время на поиск.
Выездная техническая поддержка
Моя работа начинается в двух случаях, Администратор определил точку отказа и не может устранить причины удалённо, Техническая поддержка по телефону выявила неисправность «последней мили».
Помогает мне zabbiz? да, я могу по количеству отказавших узлов понять, что нужно заправить авто.
Мне было бы легче имей я оперативную информацию о моих манипуляциях на стороне клиента или отказавшем узле связи к примеру наличие ошибок на портах устройства до и после моих манипуляций и при этом желательно не таскать с собой ноут с консольным шнурком и не бегать от компьютера абонента к коммутатору.
Абонент
Мне всё равно была гроза, или зеленстрой пилит деревья, или электросети выключили половину города, я хочу знать что с моей услугой и когда её восстановят. Я хочу понимать что это проблема с моим маршрутизатором или оператор опять, и если меня не устроят сроки, я уйду к конкурентам…
Исходя из этих историй видно, что оперативность играет важную роль в услугах. Современный пользователь не хочет ждать и вникать в проблемы оператора, он хочет услугу.
Универсальный мониторинг в рассмотренных историях способен только дать вектор для дальнейшей работы, но не помогает решать задачи.
Это и привело меня к умозаключению, что универсальный мониторинг — отстой!
А каково Ваше мнение на этот счёт?
Комментарии (17)
elve
10.10.2018 18:40Все неудобности, т.к. вы не кастомизируете морду мониторилки под себя. Штатный веб-интерфейс заббикса может быть не очень удобен, но можно же дергать данные прямо из базы в свою страничку =).
На моем нынешнем месте работы в crm первой линии данные об оборудовании абонента в живом режиме из базы заббикса. Ну это как пример. Так-то он много куда интегрирован.
zabuldon
10.10.2018 19:08в zabbix есть отличная штука, trigger dependency, позволяет не получать алерты от узлов за точкой отказа.
Fox_exe
10.10.2018 19:24Собственно, вы просто не умеете «готовить» заббикс (Или другие системы мониторинга).
Один из вариантов — как написали выше: Зависимости триггеров и данных, дабы не видеть ошибки от устройств, что расположены дальше проблемного узла.
Другой вариант — карта сети. Всмысле графическое представление со всеми связями, по которой легко отследить всю цепочку проблем от начала и до конца.
Ps: Лично я в Zabbix вообще оставил один только триггеры и оповещания на мыло, телеграм и смс. А всякие няшные графики для отчетов руководству сделал в Grafana (С плагином для Zabbix)DRVTiny
11.10.2018 10:45Зависимости триггеров актуальны и удобны в рамках одного шаблона. За рамками шаблонов trigger dependencies предполагают индивидуальное создание для каждого хоста. Понятно, что можно их понасоздавать скриптом, но можно ведь и стол из молекул собрать. Стандартная методология zabbix не позволяет делать это удобным образом: нельзя пробросить dependency за границу шаблона, и уж тем паче — между шаблонами.
maxzhurkin
10.10.2018 19:27+1Какую задачу решает администратор сети в 2к устройств L2 разнесённую географически на площадь города
Первая задача здравомыслящего администратора в такой ситуации — перестроить эту сеть, но процесс этот будет достаточно долгий, так что неизбежно появляется задача обеспечения доживания сети до завершения этого нелёгкого процесса. Ведь одна единственная петля способна положить всю эту сеть, а найти её при этом будет довольно нелегко или даже невозможно
Встречный вопрос: если это был вопрос, где же соответствующий знак вопроса?
P.S. Кажется, следовало прочитать статью целиком, прежде чем публиковать этот комментарий
wlr398
10.10.2018 20:02К сожалению, не бывает универсальных систем мониторинга. В большой сети мониторинг превращается в нагромождение из десятков, если не сотен систем мониторинга, от опенсорсных и самодельных до вендорских и платных целой в сотни тысяч долларов, плюс к этому сидят люди и пишут всякую интеграцию, так как такое количество систем по отдельности невозможно как-то реально охватывать силами персонала.
Coocos
10.10.2018 20:42Универсальные средства мониторинга хорошо решают задачу в большинстве случаев. У вас особый случай. Для провайдеров пишут специализированные системы мониторинга.
elve
10.10.2018 21:16+1В провайдерах он тоже прекрасно работает. Достаточно знать что конкретно мониторить и написать пару десятков шаблонов =). С нуля заббикс это полено и каждый может сделать из него своего Буратино, если не пропьет его своему приятелю Карло =). Вот автор пока рубанок в руки брать не хочет и жалуется =).
iwram
11.10.2018 02:43«Универсальный мониторинг» — признаюсь, что редко встречал 2 понятия вместе (вернее не встречал). В данном случае, здесь рассматривается мониторинг сетевой инфраструктуры. Также можно мониторить наличие молока в холодильнике. Присоединяюсь к комментариям выше из серии «Вы просто не умеете их готовить». Нередко встречал когда люди жалуются на систему мониторинга «И вообще все сделано неудобно». А когда начинаешь копать, выясняется, что документация неактуальна или она держится в голове великого бога-админа который немного подзабыл. Просто добавить мониторинг по snmp сетевых железяк недостаточно, необходима топология и вменяемая схема, в случае сети- это карты 1 и 2 уровня. Поэтому автору статьи рекомендую взять волю (и рубанок тоже) в кулак и сделать так, как положено. Если крупные компании с 500к+ устройств используют тот же заббикс для мониторинга вероятно есть на это причины…
barbos6
11.10.2018 09:35Автор, похоже, прав касаемо заббиксов и нагиосов.
В конечном счете их настройка/допиливание под требования конкретных служб, интеграция со специфичными для этих подразделений инструментами (например, база техучета для линейных техников, биллинг/статистика для техподдержки) потребуют ресурсов бОльше, чем написание с нуля специализированных продуктов для соответствующих служб.
duckhawk
11.10.2018 12:34Нет, интеграция заббикса со своими системами потребует ресурсов меньших, проверено собственным опытом. Вот систем инвентаризации сети толковых нет, это да.
rjhdby
11.10.2018 10:17Зачем я туда лезу: мне нужно понять какой узел в моей трёхуровневой сети умер и мне не важно есть ли ведомые девайсы за точкой отказа.
Если конкретно вам это не нужно, то это не значит, что не нужно никому.
Администраторам систем необходимо знать, что их работоспособность нарушена и(!) знать причину этой неработоспособности.
Руководству от бизнеса необходимо представлять масштабы трагедии (список неработоспособных систем), причину ее возникновения и прогноз по восстановлению (далеко не все решится простым восстановлением связи).
duckhawk
11.10.2018 11:31Вы что-то смешиваете теплое с мягким.
Заббикс — это не система инвентаризации.
Если вы хотите учет топологии — тут придется пилить свою дашборду, мы так и сделали.
В целом — функционал у заббикса достаточно широкий, нам для мониторинга сети хватает.
Dr_Wut
11.10.2018 22:24Мне кажется что у вас неверное представление что такое «универсальный мониторинг». На мой взгляд это скорее PRTG или SolarWind. Zabbix/nagios это скорее «фреймфорки мониторинга»
PerlPower
Есть легкие альтернативы nagious, которые можно засунуть прямо в папку проекта, которые будут пускаться хоть по крону, и к которым легко добавлять модули мониторинга? Желательно чтобы был отточенный API для уведомлений через джаббер и почту, а уж сам мониторинг целиком ложился на плечи пользователя.