Мне кажется, вы немного подменяете понятия. «Система мониторинга» — это абстрактный термин, описывающий весь спектр систем, которые осуществляют мониторинг чего-либо. Абстрактность его в том, что он не говорит нам, ни что мы мониторим, ни как мы это делаем. Соответственно любая 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. (уведомление об определенном событии, может являться или не являться свидетельством случившейся ошибки).
Кстати распределенная обработка событий никак не отличает вашу систему от многих коммерческих, потому что во многих коммерческих системах возможность распределения и горизонтального/вертикального масштабирования существует уже многие годы.
У вас все красиво написано, но терминология и понятия местами вводят в заблуждение. Не совсем корректно называть системами мониторинга по сути Performance Management системы, реализующие активный мониторинг посредством опроса оборудования, а параллельно выделять в отдельный класс системы Fault Management. По сути и FM, и PM являются системами мониторинга. «Система мониторинга» — это обобщенное понятие, надо просто разделять активный и пассивный мониторинг.
Хотя даже тут есть свои нюансы. Например, пинг устройства и сохранение статистики пингов будет представлять собой PM, в то время как периодический пинг устройства и формирование события на основе результата без накапливания статистики (так сказать, мгновенное значение) — в большей степени FM.
Я кстати не противопоставлял бы FM (пассивный мониторинг) и PM (активный мониторинг) системы, так как оба класса систем решают немного разные задачи, но при этом дополняют друг друга.
Также, мне кажется, не совсем корректно деление на Event и Alarm. По сути оба они события, то есть слова вполне могут быть взаимозаменяемыми, просто степень критичности каждого из них разная (и может меняться в зависимости от контекста). Каждый производитель системы мониторинга порой имеет тенденцию называть одно и то же по-разному.
Не знаю, как у HP с этим, а IBM умудряется еще иметь несколько портальных решений в схожих продуктах. И, наоборот, доходит до того, что в рамках одной линейки разные продукты используют одно портальное решение, но разные его версии, что приводит к невозможности использовать все продукты с одним порталом (хотя теоретически это должно работать).
Складывается ощущение, что группы разработчиков, работающие над каждый продуктом, не то, что не общаются с коллегами, а вообще не знают, видимо, порой об их существовании.
Если говорить о линейке Tivoli Netcool (то, что IBM отчасти получила после покупки MicroMuse и еще пары компаний впоследствии), то там много продуктов, каждый из которых имеет и плюсы, и минусы. Из-за приобретений и «конфликтов» с другими собственными продуктами мне сложно даже понять, об автораскрытии каким из продуктов идет речь.
Если речь о Netcool Network Manager IP Edition (Precision IP в девичестве), то он обычно ставится в дополнение к Netcool OMNIbus и WebGUI (он же WebTop). Все вместе это, как Fault Management система, очень даже неплохое решение. Но, как обычно водится, не без нюансов.
Хорошо, начну писать. Быстро не обещаю (работать тоже надо), но постараюсь :)
А пока, если есть вопросы, можете смело задавать в скайпе (есть в моем профайле), по возможности отвечу.
про первые три могу рассказать без проблем.
с ITCAM чуть сложнее, так как у себя мы его не используем, у нас до сих пор стоит его предок — Netcool/ISM, его функционала для задач ad-hoc мониторинга в дополнение ко всем остальным системам нам хватает.
вопрос — в каком формате интересует рассказ о продуктах. базовую информацию всегда можно почерпнуть из официальной документации/описаний. более глубокий анализ — не знаю, насколько он будет интересен общественности (кроме вас). все-таки относительно специализированный (и дорогой) софт.
я в принципе готов ответить на любые вопросы по данным продуктам в формате диалога, а параллельно на основе ответов начать набрасывать черновик статьи.
PS: я — не сотрудник IBM, так что буду и хвалить, и ругать исходя из многолетнего опыта использования достаточно объективно :)
Если не секрет, а где и кого вы учились, что у вас такой предмет был? И что именно вы там изучали?
Любопытно, так как я большую часть своей профессиональной деятельности занимаюсь NMS/OSS системами, но будучи студентом и аспирантом МТУСИ встречал полное непонимание со стороны преподавателей того, чем я занимаюсь на работе.
И bloody, и bloodthirsty переводятся, как кровавый/кровожадный.
Вариант перевода «чертовый», «проклятый», «гребанный» (и другие в том же духе) — это лишь сленговое использование данного слова, но никак не его основное значение.
Нет, все время с момента покупки айфона стоит МТСовская симка.
Cellular data перманентно выключен. Кстати никогда не мог понять, почему, когда он выключен, при открытии Messages айфон предупреждает, что оно выключено. Куда он ломиться-то пытается в этот момент?
Две недели, будучи в гостях у мамы, которая купила не так давно новый LCD телевизор, не мог понять, откуда этот эффект ускоренной съемки. Все грешил на какой-то странный механизм буферизации потока телевизором, а оказывается вот в чем дело :)
Так как сам смотрю последние лет десять все на компе, даже и не знал, что такие технологии стали в телевизоры встраивать.
Например, очень хотелось бы, чтобы механизм формирования ICMP Echo тестов стал аналогичен механизму UDP Jitter в плане частоты повторения теста и его скедулинга, а то есть некоторые проблемы с системами мониторинга, когда нужно именно Echo запустить (когда поднять респондер не представляется возможным).
Но это, так сказать, мечты)
4. IP Base. Минимальный набор. Даже ip sla нет! Я стараюсь IP Base не оставлять.
Не соглашусь, так как, например, для 1751 в IP Base есть IP SLA. Возможно, для каких-то платформ его в IP Base и нет (или есть только респондер), но часть платформ G1 этот функционал все-таки имеет.
Когда я учился, у нас только один случай был, когда препод очень недвусмысленно намекал на необходимость получения взятки путем придирок на защите курсовой типа «у вас тут блока не хватает в схеме» при том, что схема была взята из учебника и перепроверена почти всем потоком многократно в еще десятке источников.
Но это, скорее, своего рода абберация была, ибо в большинстве случаев студенты несли деньги, даже не попытавшись разобраться в предмете.
То, как вы описываете систему 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. (уведомление об определенном событии, может являться или не являться свидетельством случившейся ошибки).
Кстати распределенная обработка событий никак не отличает вашу систему от многих коммерческих, потому что во многих коммерческих системах возможность распределения и горизонтального/вертикального масштабирования существует уже многие годы.
У вас все красиво написано, но терминология и понятия местами вводят в заблуждение. Не совсем корректно называть системами мониторинга по сути Performance Management системы, реализующие активный мониторинг посредством опроса оборудования, а параллельно выделять в отдельный класс системы Fault Management. По сути и FM, и PM являются системами мониторинга. «Система мониторинга» — это обобщенное понятие, надо просто разделять активный и пассивный мониторинг.
Хотя даже тут есть свои нюансы. Например, пинг устройства и сохранение статистики пингов будет представлять собой PM, в то время как периодический пинг устройства и формирование события на основе результата без накапливания статистики (так сказать, мгновенное значение) — в большей степени FM.
Я кстати не противопоставлял бы FM (пассивный мониторинг) и PM (активный мониторинг) системы, так как оба класса систем решают немного разные задачи, но при этом дополняют друг друга.
Также, мне кажется, не совсем корректно деление на Event и Alarm. По сути оба они события, то есть слова вполне могут быть взаимозаменяемыми, просто степень критичности каждого из них разная (и может меняться в зависимости от контекста). Каждый производитель системы мониторинга порой имеет тенденцию называть одно и то же по-разному.
Складывается ощущение, что группы разработчиков, работающие над каждый продуктом, не то, что не общаются с коллегами, а вообще не знают, видимо, порой об их существовании.
Если речь о Netcool Network Manager IP Edition (Precision IP в девичестве), то он обычно ставится в дополнение к Netcool OMNIbus и WebGUI (он же WebTop). Все вместе это, как Fault Management система, очень даже неплохое решение. Но, как обычно водится, не без нюансов.
А пока, если есть вопросы, можете смело задавать в скайпе (есть в моем профайле), по возможности отвечу.
с ITCAM чуть сложнее, так как у себя мы его не используем, у нас до сих пор стоит его предок — Netcool/ISM, его функционала для задач ad-hoc мониторинга в дополнение ко всем остальным системам нам хватает.
вопрос — в каком формате интересует рассказ о продуктах. базовую информацию всегда можно почерпнуть из официальной документации/описаний. более глубокий анализ — не знаю, насколько он будет интересен общественности (кроме вас). все-таки относительно специализированный (и дорогой) софт.
я в принципе готов ответить на любые вопросы по данным продуктам в формате диалога, а параллельно на основе ответов начать набрасывать черновик статьи.
PS: я — не сотрудник IBM, так что буду и хвалить, и ругать исходя из многолетнего опыта использования достаточно объективно :)
У моего научного руководителя примерно такой же был и есть до сих пор.
Сайт руководителя — прям машина времени эдак в 1998 год, когда я поступил в институт и параллельно познакомился с Интернетом :)
Любопытно, так как я большую часть своей профессиональной деятельности занимаюсь NMS/OSS системами, но будучи студентом и аспирантом МТУСИ встречал полное непонимание со стороны преподавателей того, чем я занимаюсь на работе.
Вариант перевода «чертовый», «проклятый», «гребанный» (и другие в том же духе) — это лишь сленговое использование данного слова, но никак не его основное значение.
Cellular data перманентно выключен. Кстати никогда не мог понять, почему, когда он выключен, при открытии Messages айфон предупреждает, что оно выключено. Куда он ломиться-то пытается в этот момент?
Так как сам смотрю последние лет десять все на компе, даже и не знал, что такие технологии стали в телевизоры встраивать.
Но это, так сказать, мечты)
Не соглашусь, так как, например, для 1751 в IP Base есть IP SLA. Возможно, для каких-то платформ его в IP Base и нет (или есть только респондер), но часть платформ G1 этот функционал все-таки имеет.
Когда я учился, у нас только один случай был, когда препод очень недвусмысленно намекал на необходимость получения взятки путем придирок на защите курсовой типа «у вас тут блока не хватает в схеме» при том, что схема была взята из учебника и перепроверена почти всем потоком многократно в еще десятке источников.
Но это, скорее, своего рода абберация была, ибо в большинстве случаев студенты несли деньги, даже не попытавшись разобраться в предмете.