Комментарии 20
Напоминает задачу про искуственный интеллект.
Либо это набор известных правил (типа, если не отвечает и http, и ssh, то нужно говорить не о проблемах с ftp/http, а сразу говорить, хост не работает; а если его аплинк не пингуется, то нужно говорить о проблемах в сети, а не о проблемах узла), либо это таки искуственный интеллект. Потому что у меня иногда на диагностику проблемы (особенно в тестовых конфигурациях) может уходить времени раз в цать больше, чем на исправление. И почти всегда диагностика — это почти исследование.
Либо это набор известных правил (типа, если не отвечает и http, и ssh, то нужно говорить не о проблемах с ftp/http, а сразу говорить, хост не работает; а если его аплинк не пингуется, то нужно говорить о проблемах в сети, а не о проблемах узла), либо это таки искуственный интеллект. Потому что у меня иногда на диагностику проблемы (особенно в тестовых конфигурациях) может уходить времени раз в цать больше, чем на исправление. И почти всегда диагностика — это почти исследование.
Не все так плохо
Дима реально прав — исследование может быть для тех кто с такой проблемой не сталкивался, но в огромном количестве случаев просто не хватает экспертной базы и начальной автоматической диагностики, например для Badoo.com — до 90% проблем на самом деле повторяемые (причины могут быть разные, но технически — очень схожи по диагностике и устранению).
Дима реально прав — исследование может быть для тех кто с такой проблемой не сталкивался, но в огромном количестве случаев просто не хватает экспертной базы и начальной автоматической диагностики, например для Badoo.com — до 90% проблем на самом деле повторяемые (причины могут быть разные, но технически — очень схожи по диагностике и устранению).
ИИ — понятие растяжимое. Rule-based система может демонстрировать интеллект ничем не хуже, чем нейронная сеть, при условии, что она не будет статичной и будет обучаться. Если вживую нарисовалась диковинная авария, которую система не обнаружила, проводится небольшое исследование и база знаний обновляется.
В качестве примера — столкнулись с отказом линейной карты на свиче. Посыпалось множество аварий, система, на основании базы знаний свела их аккурат к трем десяткам упавших линков. Инженер, разбирающийся с аварией имеет знания, которых еще нет а базе, а конкретно — по именам портов видит, что все они приходятся на одну карту. Начинает копать детальнее и видит в менеджере событий, что карта действительно упала, но FM ничего не знает про такой тип аварий. Он добавляется в систему и прописывается, что если ушла линейная карта, то все порты на ней упадут. И все — в следующий раз в подобном случае в качестве причины будет видна именно упавшая карта. Кроме того, инженер замечательно знает, что при перезагрузке свича в стеке ситуация повторится, авария моделируется в лабе или без всякой лабы в систему загружается аварийный сценарий. Немного возни, и система будет знать и про аварии в стеке. Дальше, по возможности, остальные проверят аналогичные ситуации на железе других производителей и расширят поддержку для других типов железа.
В качестве примера — столкнулись с отказом линейной карты на свиче. Посыпалось множество аварий, система, на основании базы знаний свела их аккурат к трем десяткам упавших линков. Инженер, разбирающийся с аварией имеет знания, которых еще нет а базе, а конкретно — по именам портов видит, что все они приходятся на одну карту. Начинает копать детальнее и видит в менеджере событий, что карта действительно упала, но FM ничего не знает про такой тип аварий. Он добавляется в систему и прописывается, что если ушла линейная карта, то все порты на ней упадут. И все — в следующий раз в подобном случае в качестве причины будет видна именно упавшая карта. Кроме того, инженер замечательно знает, что при перезагрузке свича в стеке ситуация повторится, авария моделируется в лабе или без всякой лабы в систему загружается аварийный сценарий. Немного возни, и система будет знать и про аварии в стеке. Дальше, по возможности, остальные проверят аналогичные ситуации на железе других производителей и расширят поддержку для других типов железа.
Это работает при условии отсутствия похожих ситуаций. А что если у двух аварий симптомы похожи, но причины различаются, а ложная диагностика при применении соответствующего метода приводит к ещё большим последствиям?
Логичный ответ «нужно головой подумать перед тем, как делать», означает «перепроверь диагноз сам».
Я не спорю, что такие штуки могут быть интересны, но меня действительно пугает ложное срабатывание. 99 раз глазками проверишь, а на сотый раз сделаешь фатальную глупость, поверив системе…
Логичный ответ «нужно головой подумать перед тем, как делать», означает «перепроверь диагноз сам».
Я не спорю, что такие штуки могут быть интересны, но меня действительно пугает ложное срабатывание. 99 раз глазками проверишь, а на сотый раз сделаешь фатальную глупость, поверив системе…
А на этот счет есть диагностические скрипты. Имея под собой подложку в виде развитого модуля Service Activation система может сама зайти в случае аварийной ситуации на железку, провести диагностику и подшить ее к аварии.
В первую очередь для таких систем важна психология. Важно понимать, что аварии — это нормальная часть деятельности любой сети. В сети что-то должно падать и она как-то должна восстанавливаться. Если авария случается раз в месяц, то понятно, что будет мандраж, что система что-то недосмотрела, или что-то не додиагностировала. Если аварии случаются десятками в день и по большей части однотипные, то доверия к системе, как к рабочему инструменту, гораздо больше. Если делать все по старинке ручками, то огромное количество аварий останутся просто незамеченными и без реакции.
Своими глазами наблюдал, как система сходу нашла десяток битых блоков питания. Можно долго рассуждать на тему того, а вдруг реально дохлых не 10, а всего 9, или вдруг она не нашла еще два битых. Но факт остается фактом — как минимум выявлено 10 проблем, которые так или иначе будут решены. А альтернатива — долго сомневаться и не найти ни одной проблемы в итоге.
В первую очередь для таких систем важна психология. Важно понимать, что аварии — это нормальная часть деятельности любой сети. В сети что-то должно падать и она как-то должна восстанавливаться. Если авария случается раз в месяц, то понятно, что будет мандраж, что система что-то недосмотрела, или что-то не додиагностировала. Если аварии случаются десятками в день и по большей части однотипные, то доверия к системе, как к рабочему инструменту, гораздо больше. Если делать все по старинке ручками, то огромное количество аварий останутся просто незамеченными и без реакции.
Своими глазами наблюдал, как система сходу нашла десяток битых блоков питания. Можно долго рассуждать на тему того, а вдруг реально дохлых не 10, а всего 9, или вдруг она не нашла еще два битых. Но факт остается фактом — как минимум выявлено 10 проблем, которые так или иначе будут решены. А альтернатива — долго сомневаться и не найти ни одной проблемы в итоге.
Я понял. Вы говорите про простые случаи, когда ситуация легко локализуется.
В принципе, в терминах «управление авариями» это имеет смысл.
У меня обычно если авария, то это не аппаратный сбой (они практически всегда отрабатываются в софте и приходят как готовые варнинги, я их за аварии не считаю), это ситуация «оно не сработало как надо там, где должно было быть». То есть трудноуловимые баги в софте, race condition, неудачные телодвижения оператора с сильно отложенными последствиями…
Да что там говорить, вот ближайший случай: примерно три недели назад при установке какой-то мелочи я согласился с удалением самописного пакета с нашей системой сбора статистики. Пакет был с багом и при удалении себя не выключал. То есть программа была удалена начисто, но процесс в памяти продолжил работать. Через три недели мы перезапустили БД, процесс отвалился по таймауту.
Авария — не собирается статистика. Я пол-часа искал почему и куда пропало приложение. В ходе этого нашлось ещё несколько мелких багов (например, конфиг не был помечен как conffile и был снесён при удалении пакета).
Это авария. А отказ конкретной железки с переключением на фейловер или вылет диска из рейда — это не авария, это штатная ситуация.
В этих терминах да, умение найти какая конкретно железка навернулась по косвенным признакам может быть полезным для системы мониторинга.
В принципе, в терминах «управление авариями» это имеет смысл.
У меня обычно если авария, то это не аппаратный сбой (они практически всегда отрабатываются в софте и приходят как готовые варнинги, я их за аварии не считаю), это ситуация «оно не сработало как надо там, где должно было быть». То есть трудноуловимые баги в софте, race condition, неудачные телодвижения оператора с сильно отложенными последствиями…
Да что там говорить, вот ближайший случай: примерно три недели назад при установке какой-то мелочи я согласился с удалением самописного пакета с нашей системой сбора статистики. Пакет был с багом и при удалении себя не выключал. То есть программа была удалена начисто, но процесс в памяти продолжил работать. Через три недели мы перезапустили БД, процесс отвалился по таймауту.
Авария — не собирается статистика. Я пол-часа искал почему и куда пропало приложение. В ходе этого нашлось ещё несколько мелких багов (например, конфиг не был помечен как conffile и был снесён при удалении пакета).
Это авария. А отказ конкретной железки с переключением на фейловер или вылет диска из рейда — это не авария, это штатная ситуация.
В этих терминах да, умение найти какая конкретно железка навернулась по косвенным признакам может быть полезным для системы мониторинга.
Вы немного путаете. Мы все-таки говорим про обработку аварий в контексте сетевых технологий,
которые немного отличаются от последствий раздолбайства на серверах :)
И тут часто встречаются сложные наведенные аварии. В качестве примера — крашится процесс rpd на JUNOS, ложатся протоколы маршрутизации. Ящик при этом живой. Выглядит это как падение neighbor'ов на соседних коммутаторах. Причем всех сразу и в сторону одного ящика. В результате должен подняться alarm routing process failure. И таких примеров — масса.
Я не зря давал терминологические определения — вылет винта в рейде требует реакции (в виде замены) и винт можно считать аварийным пока не засинхронизировалась замена.
При нормальной организации процесса любая авария — штатная ситуация, так как вместо паники все работают: инженеры диагностируют, логистика везет замену, контакт-центр отбивается от клиентов, а генеральный подписан на изменение статуса аварии. Разбор полетов обычно откладывает на потом.
которые немного отличаются от последствий раздолбайства на серверах :)
И тут часто встречаются сложные наведенные аварии. В качестве примера — крашится процесс rpd на JUNOS, ложатся протоколы маршрутизации. Ящик при этом живой. Выглядит это как падение neighbor'ов на соседних коммутаторах. Причем всех сразу и в сторону одного ящика. В результате должен подняться alarm routing process failure. И таких примеров — масса.
Я не зря давал терминологические определения — вылет винта в рейде требует реакции (в виде замены) и винт можно считать аварийным пока не засинхронизировалась замена.
При нормальной организации процесса любая авария — штатная ситуация, так как вместо паники все работают: инженеры диагностируют, логистика везет замену, контакт-центр отбивается от клиентов, а генеральный подписан на изменение статуса аварии. Разбор полетов обычно откладывает на потом.
В свете openflow и openwswitch очень трудно отделить софтовые проблемы от проблем оборудования. Например, «кривой SQL» может привести к завороту пакетов не в тот порт на вполне себе железном могучем коммутаторо-маршрутизаторе.
Так в чем проблема-то? Отругается свич на то, что контроллер его игнорирует, а дальше в общем порядке. BRASы точно так же ругаются на завалившийся RADIUS.
Openflow, между нами, все-таки сильно эксперементальная вещь :)
Openflow, между нами, все-таки сильно эксперементальная вещь :)
Не так. Сбой в SQL/контроллере — и трафик идёт просто не туда.
Кстати, openflow у нас в продакте уже почти год.
Кстати, openflow у нас в продакте уже почти год.
Там еще хуже будет, при сбое в контроллере вся сеть задурит. Весьма сомнительное решение, на мой взгляд. Да и с железом проблемы пока. Pica8 ставили?
PS: Мне в этом плане больше нравится движение в сторону TRILL + нормальный статический provisioning сервисов.
PS: Мне в этом плане больше нравится движение в сторону TRILL + нормальный статический provisioning сервисов.
Можно я немного позанудствую? :)
У вас все красиво написано, но терминология и понятия местами вводят в заблуждение. Не совсем корректно называть системами мониторинга по сути Performance Management системы, реализующие активный мониторинг посредством опроса оборудования, а параллельно выделять в отдельный класс системы Fault Management. По сути и FM, и PM являются системами мониторинга. «Система мониторинга» — это обобщенное понятие, надо просто разделять активный и пассивный мониторинг.
Хотя даже тут есть свои нюансы. Например, пинг устройства и сохранение статистики пингов будет представлять собой PM, в то время как периодический пинг устройства и формирование события на основе результата без накапливания статистики (так сказать, мгновенное значение) — в большей степени FM.
Я кстати не противопоставлял бы FM (пассивный мониторинг) и PM (активный мониторинг) системы, так как оба класса систем решают немного разные задачи, но при этом дополняют друг друга.
Также, мне кажется, не совсем корректно деление на Event и Alarm. По сути оба они события, то есть слова вполне могут быть взаимозаменяемыми, просто степень критичности каждого из них разная (и может меняться в зависимости от контекста). Каждый производитель системы мониторинга порой имеет тенденцию называть одно и то же по-разному.
У вас все красиво написано, но терминология и понятия местами вводят в заблуждение. Не совсем корректно называть системами мониторинга по сути Performance Management системы, реализующие активный мониторинг посредством опроса оборудования, а параллельно выделять в отдельный класс системы Fault Management. По сути и FM, и PM являются системами мониторинга. «Система мониторинга» — это обобщенное понятие, надо просто разделять активный и пассивный мониторинг.
Хотя даже тут есть свои нюансы. Например, пинг устройства и сохранение статистики пингов будет представлять собой PM, в то время как периодический пинг устройства и формирование события на основе результата без накапливания статистики (так сказать, мгновенное значение) — в большей степени FM.
Я кстати не противопоставлял бы FM (пассивный мониторинг) и PM (активный мониторинг) системы, так как оба класса систем решают немного разные задачи, но при этом дополняют друг друга.
Также, мне кажется, не совсем корректно деление на Event и Alarm. По сути оба они события, то есть слова вполне могут быть взаимозаменяемыми, просто степень критичности каждого из них разная (и может меняться в зависимости от контекста). Каждый производитель системы мониторинга порой имеет тенденцию называть одно и то же по-разному.
Я занудствую как раз на эту же тему — очень многие называют системами мониторинга именно рисовалки графика, хотя они всего лишь подмножество PM. PM как класс безусловно нужен, но его задача немного отличается от мониторинга в общем понимании. Наш PM в статье мы не рассматривали. В целом, он работает совместно с FM и умеет генерировать свои события и alarm'ы, которые обрабатываются FM в общем порядке.
В этом случае, PM выступает для FM просто еще одним источником событий.
Комбинация FM+PM позволяет отлавливать сложные типы аварий, которые трудно отловить чистым PM или чистым FM. Важно понимать, что даже голый FM в состоянии диагностировать серьезные проблемы, в то время как голый PM, применяемый в целях мониторинга, представляет скорее тормоз в решении проблем.
Касательно Event'ов и Alarm'ов — действительно, в некоторых системах это одно и то же и отличие лишь во флажке или в приоритете. Именно так и работала первая реализация FM в NOC. У такого метода есть как свои достоинства, так и недостатки. Разделение на event'ы и alarm'ы у нас происходит по техническим и по архитектурным причинам.
Мы представляем сеть как процесс, для простоты — дискретный по времени. Фактически — это черный ящик, несмотря на то, что какие-то детали мы знаем. Процесс стохастический и прогнозировать его развитие достаточно затруднительно.
Внутри большого общего процесса деятельности сети можно выделить подпроцессы, которые как-то взаимодействуют между собой. Например, на роутерах крутятся процессы маршрутизации, на серверах — сервисы и так далее. Фактически, для задач FMS можно считать, что каждый из этих подпроцессов — это конечный автомат и в результате работы под действием внешних и внутренних факторов иногда происходит смена состояний. Для наших задач можно считать, что часть состояний процессов является нормальной и рабочей, а часть — аварийной. Все процессы регулярно генерируют логи и кидают трапы, часть из которых несет информацию о смене состояний. FMS принимает весь поток, классифицирует и дальше считает событиями. Реально из всего потока событий для нас важны только смены состояний.
Дальше вступает в работу база знаний. Описывать целиком конечные автоматы для всех возможных видов процесса дело неблагодарное и ненужное для практических применений. Поэтому реально происходящим процессам в базе знаний сопоставляется конечный автомат, состоящий из одного нормального состояния и некоторого количества аварийных. Вот эти аварийные состояния и являются Alarm'ами. Поток Event'ов у нас переключает Alarm'ы.
Вторая мотивация для разделения Event'ов и Alarm'ов не так очевидна: В отличии от многих коммерческих систем, обработка событий у нас распределенная. Сбор событий, их укладка в базу, классификация и корреляция осуществляется разными процессами, которые могут быть географически распределены и находиться на разных серверах. При этом можно варьировать количество процессов разного типа в зависимости от нагрузки. Все данные FM у нас хранятся в mongodb, которая сама по себе содержит хорошие механизмы для репликации и шардинга, что позволяет масштабировать систему как вертикально так и горизонтально. Далее учитываем тот факт, что на 1M событий реально может приходиться 100-200 alarm'ов, события можно и нужно обрабатывать раздельно и в разных местах, а alarm'ы необходимо иметь в одном месте, мы приходим к тому, что валить все в одно место недальновидно
В этом случае, PM выступает для FM просто еще одним источником событий.
Комбинация FM+PM позволяет отлавливать сложные типы аварий, которые трудно отловить чистым PM или чистым FM. Важно понимать, что даже голый FM в состоянии диагностировать серьезные проблемы, в то время как голый PM, применяемый в целях мониторинга, представляет скорее тормоз в решении проблем.
Касательно Event'ов и Alarm'ов — действительно, в некоторых системах это одно и то же и отличие лишь во флажке или в приоритете. Именно так и работала первая реализация FM в NOC. У такого метода есть как свои достоинства, так и недостатки. Разделение на event'ы и alarm'ы у нас происходит по техническим и по архитектурным причинам.
Мы представляем сеть как процесс, для простоты — дискретный по времени. Фактически — это черный ящик, несмотря на то, что какие-то детали мы знаем. Процесс стохастический и прогнозировать его развитие достаточно затруднительно.
Внутри большого общего процесса деятельности сети можно выделить подпроцессы, которые как-то взаимодействуют между собой. Например, на роутерах крутятся процессы маршрутизации, на серверах — сервисы и так далее. Фактически, для задач FMS можно считать, что каждый из этих подпроцессов — это конечный автомат и в результате работы под действием внешних и внутренних факторов иногда происходит смена состояний. Для наших задач можно считать, что часть состояний процессов является нормальной и рабочей, а часть — аварийной. Все процессы регулярно генерируют логи и кидают трапы, часть из которых несет информацию о смене состояний. FMS принимает весь поток, классифицирует и дальше считает событиями. Реально из всего потока событий для нас важны только смены состояний.
Дальше вступает в работу база знаний. Описывать целиком конечные автоматы для всех возможных видов процесса дело неблагодарное и ненужное для практических применений. Поэтому реально происходящим процессам в базе знаний сопоставляется конечный автомат, состоящий из одного нормального состояния и некоторого количества аварийных. Вот эти аварийные состояния и являются Alarm'ами. Поток Event'ов у нас переключает Alarm'ы.
Вторая мотивация для разделения Event'ов и Alarm'ов не так очевидна: В отличии от многих коммерческих систем, обработка событий у нас распределенная. Сбор событий, их укладка в базу, классификация и корреляция осуществляется разными процессами, которые могут быть географически распределены и находиться на разных серверах. При этом можно варьировать количество процессов разного типа в зависимости от нагрузки. Все данные FM у нас хранятся в mongodb, которая сама по себе содержит хорошие механизмы для репликации и шардинга, что позволяет масштабировать систему как вертикально так и горизонтально. Далее учитываем тот факт, что на 1M событий реально может приходиться 100-200 alarm'ов, события можно и нужно обрабатывать раздельно и в разных местах, а alarm'ы необходимо иметь в одном месте, мы приходим к тому, что валить все в одно место недальновидно
Мне кажется, вы немного подменяете понятия. «Система мониторинга» — это абстрактный термин, описывающий весь спектр систем, которые осуществляют мониторинг чего-либо. Абстрактность его в том, что он не говорит нам, ни что мы мониторим, ни как мы это делаем. Соответственно любая FM и PM система является системой мониторинга в общем смысле.
То, как вы описываете систему FM (FMS) является лишь одним из видом реализации системы FM. Если посмотреть на ISOшное описание фреймворка FCAPS (а NOC Project, судя по описания в первом же предложении, основывается и руководствуется этим фреймворком), то там дается более общее описание fault management систем.
Более того, FM — это далеко не всегда экспертная система и не всегда их можно разделить на категории (кстати вы выделяете 4, но перечисляете только три — где-то ошибочка закралась).
Приведу пример. Есть, скажем, сеть оператор связи, у которого есть сети SDH/PDH, IP/MPLS, телефония и еще пара вагонов с маленькими тележками различных технологий, на основе которых предоставляются те или иные сервисы. Оборудование и софт генерят непрерывный поток событий, которые нормализуются и приводятся к некоторому общему унифицированному виду после чего складываются в базу данных FM системы. Отдельный процесс/компонент выполняет обогащение этих событий дополнительной информацией из инвентарных и CRM баз, позволяя определить затронутые сервисы клиентов, а на основе этой информации открываются трабл тикеты, рассылаются уведомления и формируется список наиболее критических событий, который отображается на экранах перед операторами центра управления сетью.
В этом случае FM система не включает в Rule Based, Codebook или нейронную сеть в качетсве базы знаний. Есть просто некоторый workflow, согласно которому события классифицируются, анализируются и выполняются те или иные действия. Формально это не является базой знаний, но так же формально это пример реальной реализации системы FM.
Насчет events и alarms.
У меня в шаговой доступности есть огромная сеть, состоящая из различных технологий и невероятного зоопарка оборудования. У половины представителей этого зоопарка есть свои element и network management systmes (EMS/MNS), которые отправляют события в нашу централизованную FM систему. Так вот производители EMS/NMS, а также и FM систем за долгие годы своего существования так и не пришли к единой терминологии, поэтому одни называют все события event'ами, другие — alarm'ами. С точки зрения каждого из них, да и с лингвистической точки зрения тоже, они правы. Вы тоже правы с вашей точки зрения, когда в конкретной реализации системы считаете весь поток евентами, а значимые события алармами.
Вы выделяете всего две категарии событий, называя общий поток Событиями, а некоторое их подмножество Авариями. А коллеги из ITU-T, написавшие рекомендацию X.733, поступают более логично, не вступая в лингвистический спор о том, какое событие важно и как его надо называть, а выделяя уровни критичности (severity levels) события — clear, indeterminate, warning, minor, major, critical, — что позволяет более гибко классифицировать события, а также осуществлять взаимодействие между различными системами, если таковое требуется.
Кстати в том же документе упоминается следующая стандартизованная терминология:
error — A deviation of a system from normal operation. (отклонение режима работы системы от нормального);
fault — The physical or algorithmic cause of a malfunction. Faults manifest themselves as errors. (физическая или алгоритмическая причина неисправности, проявляющаяся в виде ошибок);
alarm — A notification, of the form defined by this function, of a specific event. An alarm may or may not represent an error. (уведомление об определенном событии, может являться или не являться свидетельством случившейся ошибки).
Кстати распределенная обработка событий никак не отличает вашу систему от многих коммерческих, потому что во многих коммерческих системах возможность распределения и горизонтального/вертикального масштабирования существует уже многие годы.
То, как вы описываете систему FM (FMS) является лишь одним из видом реализации системы FM. Если посмотреть на ISOшное описание фреймворка FCAPS (а NOC Project, судя по описания в первом же предложении, основывается и руководствуется этим фреймворком), то там дается более общее описание fault management систем.
Более того, FM — это далеко не всегда экспертная система и не всегда их можно разделить на категории (кстати вы выделяете 4, но перечисляете только три — где-то ошибочка закралась).
Приведу пример. Есть, скажем, сеть оператор связи, у которого есть сети SDH/PDH, IP/MPLS, телефония и еще пара вагонов с маленькими тележками различных технологий, на основе которых предоставляются те или иные сервисы. Оборудование и софт генерят непрерывный поток событий, которые нормализуются и приводятся к некоторому общему унифицированному виду после чего складываются в базу данных FM системы. Отдельный процесс/компонент выполняет обогащение этих событий дополнительной информацией из инвентарных и CRM баз, позволяя определить затронутые сервисы клиентов, а на основе этой информации открываются трабл тикеты, рассылаются уведомления и формируется список наиболее критических событий, который отображается на экранах перед операторами центра управления сетью.
В этом случае FM система не включает в Rule Based, Codebook или нейронную сеть в качетсве базы знаний. Есть просто некоторый workflow, согласно которому события классифицируются, анализируются и выполняются те или иные действия. Формально это не является базой знаний, но так же формально это пример реальной реализации системы FM.
Насчет events и alarms.
У меня в шаговой доступности есть огромная сеть, состоящая из различных технологий и невероятного зоопарка оборудования. У половины представителей этого зоопарка есть свои element и network management systmes (EMS/MNS), которые отправляют события в нашу централизованную FM систему. Так вот производители EMS/NMS, а также и FM систем за долгие годы своего существования так и не пришли к единой терминологии, поэтому одни называют все события event'ами, другие — alarm'ами. С точки зрения каждого из них, да и с лингвистической точки зрения тоже, они правы. Вы тоже правы с вашей точки зрения, когда в конкретной реализации системы считаете весь поток евентами, а значимые события алармами.
Вы выделяете всего две категарии событий, называя общий поток Событиями, а некоторое их подмножество Авариями. А коллеги из ITU-T, написавшие рекомендацию X.733, поступают более логично, не вступая в лингвистический спор о том, какое событие важно и как его надо называть, а выделяя уровни критичности (severity levels) события — clear, indeterminate, warning, minor, major, critical, — что позволяет более гибко классифицировать события, а также осуществлять взаимодействие между различными системами, если таковое требуется.
Кстати в том же документе упоминается следующая стандартизованная терминология:
error — A deviation of a system from normal operation. (отклонение режима работы системы от нормального);
fault — The physical or algorithmic cause of a malfunction. Faults manifest themselves as errors. (физическая или алгоритмическая причина неисправности, проявляющаяся в виде ошибок);
alarm — A notification, of the form defined by this function, of a specific event. An alarm may or may not represent an error. (уведомление об определенном событии, может являться или не являться свидетельством случившейся ошибки).
Кстати распределенная обработка событий никак не отличает вашу систему от многих коммерческих, потому что во многих коммерческих системах возможность распределения и горизонтального/вертикального масштабирования существует уже многие годы.
Четвертый тип (он же первый), который выпал из описания — graph based, который руководствуется заранее определенными зависимостями между сервисами. В какой-то мере NAGIOS делает похожую работу.
Вы правы относительно того, что терминология и понятия у разных вендоров отличаются. С этим все давно уже смирились :) Наш вариант трактовки терминологии точно также встречается в ряде коммерческих систем. Естественно, у нас в системе есть приоритеты аварий, которые могут изменяться оператором и системой в зависимости от тяжести последствий. Задачи придумать что-то радикально новое в fault management'е мы не ставили. Текущая задача проекта — доведение системы до уровня и функциональных возможностей нормальных промышленных FMS. Задачи отобрать хлеб у игроков, которые находятся на рынке не один десяток лет у нас тоже не стоит.
Распределенная обработка событий в той или иной мере реализована у всех, хотя слишком часто встречаются и откровенные костыли, тянущиеся из технологических решений двадцатилетней давности.
В нашем случае мы руководствовались собственным скромным опытом эксплуатации высоконагруженных систем и применили часть архитектурных решений из этой области в нашем проекте. Важный для многих момент — система работает на обычном дешевом железе и не требует монстров вроде Oracle и сановских гробов, обработку событий можно легко выносить ближе к месту их возникновения, и так далее.
Вы правы относительно того, что терминология и понятия у разных вендоров отличаются. С этим все давно уже смирились :) Наш вариант трактовки терминологии точно также встречается в ряде коммерческих систем. Естественно, у нас в системе есть приоритеты аварий, которые могут изменяться оператором и системой в зависимости от тяжести последствий. Задачи придумать что-то радикально новое в fault management'е мы не ставили. Текущая задача проекта — доведение системы до уровня и функциональных возможностей нормальных промышленных FMS. Задачи отобрать хлеб у игроков, которые находятся на рынке не один десяток лет у нас тоже не стоит.
Распределенная обработка событий в той или иной мере реализована у всех, хотя слишком часто встречаются и откровенные костыли, тянущиеся из технологических решений двадцатилетней давности.
В нашем случае мы руководствовались собственным скромным опытом эксплуатации высоконагруженных систем и применили часть архитектурных решений из этой области в нашем проекте. Важный для многих момент — система работает на обычном дешевом железе и не требует монстров вроде Oracle и сановских гробов, обработку событий можно легко выносить ближе к месту их возникновения, и так далее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NOC: Введение в Fault Management