Этот пост посвящён пакету мониторинга (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 диаграммами пользоваться вполне комфортно.

cisco2851 на диаграмме

А вот тут видны наиболее ресурсоёмкие процессы рутера.

Список самых ресурсоёмких процессов

Как видите, мониторинг даром не обходится, процессы, связанные с ответами на SNMP запросы попали в топ лист.

Ну и конечно, гордость коллекции – IP SLA мониторы. Их много, поэтому SCOM их разбивает на группы по состоянию.

С каналом в Самару явно не всё хорошо.

3. Графики.

Конечно, возможность оценить состояние циски одним взглядом – это очень круто, но иногда хочется узнать подробности. Не всё конечно можно показать на графиках (например, состояние блоков питания на графиках никак не покажешь), но многие вещи на графиках смотреть можно и нужно.

Классика жанра - % свободной памяти.

Графики температур нескольких цисок.

Трафик на одном из интерфейсов (in, out и total).

По некоторым объектам можно нарисовать много графиков. Например, для UDP-Jitter’а я оставил только самые необходимые, но всё равно их 13 штук.

% потерянных пакетов.

RTTMax и RTTMin

На самом деле графиков рисуется довольно много, все скриншотами не охватить. Если кому-то интересен полный список – смотрите таблицу в конце.

4. Алёрты.

Каждое изменение состояния циски в положительную и отрицательную сторону вызывает появление алёрта или закрытие алёрта. Чтобы узнать, какие алёрты в данный момент открыты (или какие вообще возникали за N дней) открываем соответствующее представление.

Активные алёрты.

5. Оповещения.

Естественно хочется получать по почте или на телефон уведомления о наиболее важных события. И это мы тоже можем, причём в довольно информативном виде.

Оповещение о высокой загруженности процессора.

Видим, что процессор был перегружен (>75%) , видим насколько сильно (81%). Видим список процессов, которые грузили процессор в этот момент (SNMP Engine), видим, какая часть процессора была занята обработкой прерываний (84%). Сразу можно сделать заключение, в чём причина высокой загрузки процессора. Тут немного хромает арифметика (2%+84%=81%). Небольшая погрешность возникает из-за того, что загрузка процессора, связанная с прерываниями, к сожалению, отдаётся циской только в мгновенном виде.

Канал в Тольятти слегка просел.

Тут у нас ощутимые потери на канале. Из 10 семплов в среднем не проходит 13% пакетов. Порог в 12% и количество усредняемых семплов – переопределяемые значения.

Канал в Новосибирск совсем упал.

В оповещении не видно, но тут мы тоже не ориентируемся на мгновенные показания. Канал считается упавшим, если не подаёт признаков жизни 2 семпла подряд. Само-собой количество семплов легко переопределяется.

6. Модели состояния.

Чтобы узнать, почему циска стала красной в сводном списке, и почему на диаграмме у неё пожелтел один из модулей, можно конечно открыть почту и прочитать оповещения или глянуть в список алёртов, но иногда удобнее открыть модель состояния.

Модель состояния

Видим, что данная циска пожелтела потому, что у неё вентилятор перешёл в состояние shutdown. Ещё видим, что этот вентилятор умер не до конца, иногда он переходит в состояние ок.

7. Syslog.

Ну и конечно мониторинг логов, куда же мы без этого. Наиболее важные события попадают в почту и в список алёртов:

Пользователь подключился по ssh.

8. Кастомизация.

Не всегда удобно следить за состоянием канала по общему списку цисок. Вполне может быть, что туннель задублирован на нескольких цисках. В этом случае нам приходит на помощь кастомизация под конкретную задачу.

А как у нас поживают циски, ответственные за канал в Екатеринбург?

9. Отчёты.

Если есть желание показать начальству, как классно у вас работали каналы между офисами в течение квартала, можно сгенерировать отчёт доступности. Например, такой:

А теперь обещанные таблицы.

Routers

Switches

Firewalls

Management pack, получившийся в результате почти года разработки нравится мне самому, и устраивает наш сетевой отдел. Фактически, у нас получилось уйти от недостатков сторонних пакетов мониторинга цисок. Перечислю в кратце достоинства конечного продукта.

• Наш пакет не требует установки отдельных приложений для своей работы. Он фактически является таким же обычным пакетом мониторинга, как пакеты для MS SQL или MS Exchange. Его внедрение сводится к тому, что нужно стандартным образом импортировать пакет в SCOM и задискаверить в SCOMе циски как обычные сетевые устройства. Пакет сам разберётся, что это циски, сам отнесёт их к нужным классам, выяснит, какие модули в этих цисках есть, и, собственно, начнётся таинство мониторинга.
• Инициаторами разработки пакета и активными участниками проекта были сетевые администраторы. Поэтому пакет мониторит только то, что нужно им, а не то, что в принципе можно мониторить. Я несколько раз порывался встроить мониторинг всяких штук, которые есть в пакетах от Jalasoft и Quest, но в итоге не сделал этого, потому что это оказывалось не нужно конечным пользователям – сетевым администраторам.
• Система алёртинга делалась с учётом российских реалий. Пакет не предназначался изначально для идеальной европейской сети, в которой не бывает неожиданных пропаданий соединения на несколько секунд или регулярной потери нескольких процентов пакетов на каком-нибудь канале. Наш пакет тестировался в обычных российских сетях и уверяю вас, даже если оставить всё по умолчанию, вы не будете завалены тысячей сообщений, а получите только действительно имеющие смысл уведомления. В тоже время никто не мешает конечному пользователю переопределить пороги так, чтобы пакет на любое икание сети разражался десятком смс-сообщений.
• Главный плюс пакета для русских клиентов – то, что его разработчики находятся в России. Мы готовы заниматься его внедрением, кастомизацией и даже наращивать его функционал по желанию заказчика.

Работы над пакетом продолжаются. Вот фичи, которые скорее всего появятся в очередных новых версиях:

• Собственные отчёты. В данный момент можно использовать стандартные отчёты SCOM, но иногда их не достаточно.
• Визуализация схемы сети. Всё просто – рисуете в Visio схему вашей сети (наверняка такая схема у вас уже есть) пристыковываете её к SCOMу и схема оживает красными, жёлтыми и зелёными огоньками.