Этот пост посвящён пакету мониторинга (management pack) цисок для Microsoft System Center Operations Manager 2007 (далее в тексте SCOM), который родился в недрах нашей компании.
Начну с того, как вообще мы дошли до жизни такой – почему стали писать собственный пакет мониторинга цисок. Дело в том, что SCOM у нас уже был внедрён, серверы он мониторил вполне успешно. Появилось естественное желание свести в единую консоль оператора мониторинг серверов, сетевого оборудования и источников бесперебойного питания. Я занялся исследованием вопроса мониторинга цисок с помощью SCOM. В каталоге на сайте Microsoft для этого предлагается два сторонних пакета (разрабатываемых партнёрами Microsoft и приобретаемыми отдельно). Я ставил и изучал оба – от Quest Software и Jalasoft, показывал их нашим сетевым администраторам… и в итоге мы решили, что их функционал нас не устраивает, и лучше будет написать свой management pack.
Немного расскажу о недостатках сторонних пакетов.
- Они работают совершенно отдельно от SCOM’а. Фактически, на сервер (иногда на отдельный) ставится некая программа, которая постоянно опрашивает циски, а в SCOM перебрасываются уже готовые для визуализации результаты мониторинга. Из-за такого принципа работы конфигурировать пакет приходится не из интерфейса SCOM, а из интерфейса самого пакета, как правило, запутанного и не интуитивного.
- Складывается впечатление, что эти пакеты делают люди далёкие от сетевого администрирования. Пакеты умеют собирать огромное количество параметров, но при этом не умеют собирать именно ту информацию, которая особенно интересна.
- В этих пакетах довольно слабо реализована самая классная фича SCOM’а. Я имею ввиду оповещения. При грамотно настроенных оповещениях в консоль управления SCOM’ом даже заглядывать не нужно, всё ясно из пришедших на e-mail писем, ну или sms на телефон, кому как удобно. У нас сетевики получают SMS о критических на их взгляд событиях и письма о некритических.
- Кастомизация. В сетевом администрировании многое зависит от качества сети и от требований, которые предъявляются к этому самому качеству. Если оставить все настройки пакета по умолчанию, то администраторы рискуют оказаться, либо заваленными SMS-ками, либо получать SMS раз в полгода при том, что конечные пользователи будут недовольны качеством работы сети. Конечно, каждый пользователь пакета может настроить пороги под себя, но иногда порогов недостаточно, нужно менять гораздо более глубокие механизмы.
- Способ распространения. Мониторинг сетей – штука сложная, и внедрить её просто нажав несколько раз NEXT в инсталлере – не реально. Самым разумным способом продажи такой системы мне представляется продажа продукта вместе с проектом по его внедрению и кастомизации. Сторонние пакеты написаны западными компаниями и приехать чтобы его внедрить они либо не смогут, либо смогут за совсем неразумные деньги.
Но довольно лирики, перейдём к обзору нашего пакета.
Во-первых, мы разделили циски на 3 не совсем равноправных класса: Routers, Switches и Firewalls. Самый интересный в плане мониторинга класс – Routers, на втором месте – Switches и замыкает тройку лидеров класс Firewalls.
Передо мной не стоит задача описать в блоге функционал пакета полностью, поэтому я просто приведу скриншоты, а в конце дам несколько таблиц для любителей подробностей.
1. Общий список.
Чтобы окинуть одним взглядом состояние всех ваших цисок пригодится этот вид.
2. Диаграммы.
Чтобы понять, какие компоненты мониторятся в конкретной циске и в каком состоянии эти компоненты находятся в данный момент, подходит это представление. Вот как выглядит один из наших рутеров модели 1841 на диаграмме:
Рутеры более старших моделей конечно же интереснее в плане мониторинга. Вот кусок скрина с диаграммы рутера 2851. Целиком диаграмма не влезла на лист, но на моём 19″ мониторе в консоли оператора SCOM диаграммами пользоваться вполне комфортно.
А вот тут видны наиболее ресурсоёмкие процессы рутера.
Как видите, мониторинг даром не обходится, процессы, связанные с ответами на SNMP запросы попали в топ лист.
Ну и конечно, гордость коллекции – IP SLA мониторы. Их много, поэтому SCOM их разбивает на группы по состоянию.
3. Графики.
Конечно, возможность оценить состояние циски одним взглядом – это очень круто, но иногда хочется узнать подробности. Не всё конечно можно показать на графиках (например, состояние блоков питания на графиках никак не покажешь), но многие вещи на графиках смотреть можно и нужно.
По некоторым объектам можно нарисовать много графиков. Например, для UDP-Jitter’а я оставил только самые необходимые, но всё равно их 13 штук.
На самом деле графиков рисуется довольно много, все скриншотами не охватить. Если кому-то интересен полный список – смотрите таблицу в конце.
4. Алёрты.
Каждое изменение состояния циски в положительную и отрицательную сторону вызывает появление алёрта или закрытие алёрта. Чтобы узнать, какие алёрты в данный момент открыты (или какие вообще возникали за N дней) открываем соответствующее представление.
5. Оповещения.
Естественно хочется получать по почте или на телефон уведомления о наиболее важных события. И это мы тоже можем, причём в довольно информативном виде.
Видим, что процессор был перегружен (>75%) , видим насколько сильно (81%). Видим список процессов, которые грузили процессор в этот момент (SNMP Engine), видим, какая часть процессора была занята обработкой прерываний (84%). Сразу можно сделать заключение, в чём причина высокой загрузки процессора. Тут немного хромает арифметика (2%+84%=81%). Небольшая погрешность возникает из-за того, что загрузка процессора, связанная с прерываниями, к сожалению, отдаётся циской только в мгновенном виде.
Тут у нас ощутимые потери на канале. Из 10 семплов в среднем не проходит 13% пакетов. Порог в 12% и количество усредняемых семплов – переопределяемые значения.
В оповещении не видно, но тут мы тоже не ориентируемся на мгновенные показания. Канал считается упавшим, если не подаёт признаков жизни 2 семпла подряд. Само-собой количество семплов легко переопределяется.
6. Модели состояния.
Чтобы узнать, почему циска стала красной в сводном списке, и почему на диаграмме у неё пожелтел один из модулей, можно конечно открыть почту и прочитать оповещения или глянуть в список алёртов, но иногда удобнее открыть модель состояния.
Видим, что данная циска пожелтела потому, что у неё вентилятор перешёл в состояние shutdown. Ещё видим, что этот вентилятор умер не до конца, иногда он переходит в состояние ок.
7. Syslog.
Ну и конечно мониторинг логов, куда же мы без этого. Наиболее важные события попадают в почту и в список алёртов:
8. Кастомизация.
Не всегда удобно следить за состоянием канала по общему списку цисок. Вполне может быть, что туннель задублирован на нескольких цисках. В этом случае нам приходит на помощь кастомизация под конкретную задачу.
9. Отчёты.
Если есть желание показать начальству, как классно у вас работали каналы между офисами в течение квартала, можно сгенерировать отчёт доступности. Например, такой:
А теперь обещанные таблицы.
Routers
Графики | Алёрты/уведомления | |
Memory (ОЗУ) | % свободной памяти, % занятой памяти, количество свободной памяти (МБ), количество занятой памяти (МБ) | В случае если % свободной памяти меньше порогового значения. |
CPU (Процессор) | Средняя загрузка за 1 минуту, средняя загрузка за 5 минут, средняя загрузка за 30 секунд, мгновенная загрузка по прерываниям | В случае если % среднего использования процессора за 1 минуту больше порогового значения. |
Process (Процесс) | Среднее использование процессора за 1 минуту, среднее использование процессора за 5 минут, среднее использование процессора за 30 секунд | Нет |
Fan (Вентилятор) | Нет | Если вентилятор переходит в состояние отличное от OK. |
Temperature (Температура) | Температура в градусах Цельсия | Если температура превышает порог, заданный в самой циске. |
Network Interface (Сетевой интерфейс) | Трафик через интерфейс (входящий, исходящий, суммарный) | Нет |
Power Unit (Блок питания) | Нет | Если блок питания переходит в состояние отличное от OK. |
IP SLA Jitter | rttMonLatestJitterOperRTTMin, rttMonLatestJitterOperRTTMax, rttMonLatestJitterOperPacketOutOfSequence, rttMonLatestJitterOperSense, rttMonLatestJitterOperAvgDSJ, rttMonLatestJitterOperAvgJitter, rttMonLatestJitterOperAvgSDJ, rttMonLatestJitterOperPacketLateArrival, rttMonLatestJitterOperPacketLossDS, rttMonLatestJitterOperPacketLossSD, rttMonLatestJitterOperPercentOfLostPackets | Если количество потерянных пакетов в ходе N замеров превышает порог, если результат нескольких замеров подряд отличен от OK. |
IP SLA Echo | rttMonLatestRttOperCompletionTime, rttMonLatestRttOperSense | Нет |
IP SLA UDP Echo | rttMonLatestRttOperCompletionTime, rttMonLatestRttOperSense | Нет |
IP SLA PathEcho | rttMonLatestRttOperCompletionTime, rttMonLatestRttOperSense | Нет |
Switches
Графики | Алёрты/уведомления | |
Memory (ОЗУ) | % свободной памяти, % занятой памяти, количество свободной памяти (МБ), количество занятой памяти (МБ) | В случае если % свободной памяти меньше порогового значения. |
CPU (Процессор) | Средняя загрузка за 1 минуту, средняя загрузка за 5 минут, средняя загрузка за 30 секунд, мгновенная загрузка по прерываниям | В случае если % среднего использования процессора за 1 минуту больше порогового значени. |
Process (Процесс) | Среднее использование процессора за 1 минуту, среднее использование процессора за 5 минут, среднее использование процессора за 30 секунд | Нет |
Fan (Вентилятор) | Нет | Если вентилятор переходит в состояние отличное от OK. |
Temperature (Температура) | Температура в градусах Цельсия | Если температура превышает порог заданный в самой циске. |
Network Interface (Сетевой интерфейс) | Трафик через интерфейс (входящий, исходящий, суммарный) | Нет |
Power Unit (Блок питания) | Нет | Если блок питания переходит в состояние отличное от OK. |
Firewalls
Графики | Алёрты/уведомления | |
Memory (ОЗУ) | % свободной памяти, % занятой памяти, количество свободной памяти (МБ), количество занятой памяти (МБ) | В случае если % свободной памяти меньше порогового значения. |
CPU (Процессор) | Средняя загрузка за 1 минуту, средняя загрузка за 5 минут, средняя загрузка за 30 секунд, мгновенная загрузка по прерываниям | В случае если % среднего использования процессора за 1 минуту больше порогового значения. |
Management pack, получившийся в результате почти года разработки нравится мне самому, и устраивает наш сетевой отдел. Фактически, у нас получилось уйти от недостатков сторонних пакетов мониторинга цисок. Перечислю в кратце достоинства конечного продукта.
-
Наш пакет не требует установки отдельных приложений для своей работы. Он фактически является таким же обычным пакетом мониторинга, как пакеты для MS SQL или MS Exchange. Его внедрение сводится к тому, что нужно стандартным образом импортировать пакет в SCOM и задискаверить в SCOMе циски как обычные сетевые устройства. Пакет сам разберётся, что это циски, сам отнесёт их к нужным классам, выяснит, какие модули в этих цисках есть, и, собственно, начнётся таинство мониторинга.
-
Инициаторами разработки пакета и активными участниками проекта были сетевые администраторы. Поэтому пакет мониторит только то, что нужно им, а не то, что в принципе можно мониторить. Я несколько раз порывался встроить мониторинг всяких штук, которые есть в пакетах от Jalasoft и Quest, но в итоге не сделал этого, потому что это оказывалось не нужно конечным пользователям – сетевым администраторам.
-
Система алёртинга делалась с учётом российских реалий. Пакет не предназначался изначально для идеальной европейской сети, в которой не бывает неожиданных пропаданий соединения на несколько секунд или регулярной потери нескольких процентов пакетов на каком-нибудь канале. Наш пакет тестировался в обычных российских сетях и уверяю вас, даже если оставить всё по умолчанию, вы не будете завалены тысячей сообщений, а получите только действительно имеющие смысл уведомления. В тоже время никто не мешает конечному пользователю переопределить пороги так, чтобы пакет на любое икание сети разражался десятком смс-сообщений.
-
Главный плюс пакета для русских клиентов – то, что его разработчики находятся в России. Мы готовы заниматься его внедрением, кастомизацией и даже наращивать его функционал по желанию заказчика.
Работы над пакетом продолжаются. Вот фичи, которые скорее всего появятся в очередных новых версиях:
-
Собственные отчёты. В данный момент можно использовать стандартные отчёты SCOM, но иногда их не достаточно.
-
Визуализация схемы сети. Всё просто – рисуете в Visio схему вашей сети (наверняка такая схема у вас уже есть) пристыковываете её к SCOMу и схема оживает красными, жёлтыми и зелёными огоньками.
Да … большой обьем работы …
Правда с таким же подходом все это можно было бы сделать используя, например, Nagios. Внедрить SLA, дешборд для ServiceDesk и т п
То что Вы использовали МОМ в качестве единой точки – это похвально.
Теперь Вы можете занятся комерцией и стать партнером компании Майкрософт, предлагая свой MP
Удачи
Собственно, мы и есть партнеры MS и предлагаем свои MP
Вопрос такой, как-то можно поглядеть на ваш софт в рабочем режиме? Взять на тестирование? И сколько будет стоить купить и внедрить?
Эффективнее всего поглядеть на софт в рабочем режиме – приехать к нам и посмотреть на него в реальной продакшен среде. Ну или можно устроить удалённую демонстрацию. В будущем планируем сделать доступ к веб-консоли через интернет. Триальная версия возможно будет, но не в ближайшее время.
Пакет лицензируется на количество устройств, цены зависят от объёма поставки. При покупке от 100 штук цены будут 100-250 долларов в зависимости от роли циски.
По внедрению сложно назвать цены. Зависит от количества устройств, от удалённости места внедрения от Москвы и возможности работать там удалённо через VPDN, а также от сложности инфраструктуры (сколько удалённых офисов нужно мониторить).
К сожалению я нахожусь в Тюмени. Если на CiscoExpo выберусь, то и к вам заеду.
А что насчет удаленной демонстрации?
Можно через WebEx. Звоните, договоримся о времени проведения демострации. Телефон есть в контактах.
Добрый день!
Как сейчас обстоит дело с Вашим МР, возможно ли тетсирование пробной версии?
Сергей, здравствуйте.
Все у нас хорошо, спасибо.
Триалку получить можно без проблем.
Напишите на scom-team@vpn.ru – и все организуем.
Здравствуйте.
Скажите, а разрабатываемый Вами MP для CISCO сложно адаптировать под оборудование Mikrotik?
У нас порядка 20 единиц оборудования.