Роль системы мониторинга

Журнал «Вестник связи», №9, 2007
РОЛЬ СИСТЕМЫ МОНИТОРИНГА
В ИНФРАСТРУКТУРЕ ОПЕРАТОРА МГ/МН СВЯЗИ
П.Е. Литягин, руководитель отдела мониторинга ОАО "Арктел"
Опубликованные в ВС статьи "Эволюция распределенного мониторинга сети
ОКС-7" (№ 12, 2006 г.) и "Распределенный мониторинг сети ОКС-7" (№ 2, 2007 г.),
обобщающие накопленный в Северной столице опыт работы в этом направлении
оператора "ПетербургТранзитТелеком", вызвали значительный читательский интерес.
К тому же, важность системы мониторинга уже обсуждалась ранее на страницах журнала
и аргументировалась там тезисом из Екклезиаста: "Благоразумный видит беду и
укрывается, а неопытный идет вперед и наказывается". В этом выпуске журнала
редакция представляет еще один взгляд на систему мониторинга сети ОКС-7,
принадлежащий другому, уже не региональному, а федеральному оператору "Арктел".
Эволюция технологии: от ТОМ к IP
Как практически и все операторы связи, первоначально компания "Арктел" строила
свою сеть на TDM-коммутаторах, где использовались протоколы сигнализации EDSS-1
(PRI ISDN) и ISUP (ОКС-7). На тот момент для решения задач, связанных с
мониторингом качества прохождения трафика по этим протоколам, а также для
своевременного выявления и устранения неисправностей на сети, компания
использовала стандартные внутристанционные технические средства.
По мере развития технической базы сети связи применение только этих средств уже не
позволяло оперативно решать перечисленные задачи. По этой причине в 2004 г. было
принято решение о развертывании системы распределенного мониторинга (в качестве
которой была выбрана петербургская система "Спайдер"), включающей в себя такие
приложения, как:
 on-line/history-мониторинг сигнальной информации;
 система анализа качества QoS;
 CDR-обозреватель;
 детектор злонамеренных вызовов FMS;
 и другие приложения, предназначенные для работы с протоколами ОКС-7 и DSS1.
В процессе эксплуатации выбранная система проходила различные стадии эволюции
одновременно с развитием технологий, используемых в сети "Арктел". Так, с
внедрением VoIP-технологий и приобретением коммутаторов SX 3000 (производства
Huawei), архитектура которых строится на данных технологиях, появилась
необходимость мониторинга протоколов VoIP (H.323 и SIP) и Sigtran (DSS1 ISDN и
ISUP ОКС-7 over IP). В связи с этим возникла потребность в системе, которая способна
решать задачи анализа качества при использовании этих протоколов и совместима с
имеющейся уже системой мониторинга. Решение было найдено путем добавления
соответствующих функциональных модулей в уже имеющийся и успешно работающий
комплекс оборудования.
В настоящее время при помощи системы распределенного мониторинга "Спайдер"
осуществляется мониторинг и анализ качества сети связи Московского филиала ОАО
Журнал «Вестник связи», №9, 2007
"Арктел", а до конца 2007 г. планируется охватить ею все центральные
коммутационные узлы регионов, входящие в единую взаимоувязанную МГ/МН сеть
"Арктел", т. е. контролировать весь междугородный и международный трафик.
От мониторинга протоколов к контролю качества и SLA
Выбранная для нашей сети система мониторинга имеет ряд функциональных
возможностей, реализуемых специализированными приложениями, которые
распределение выполняются на серверах системы и рабочих станциях сотрудников
компании. Рассмотрим основные из них.
Конфигуратор. Работа с системой мониторинга "Спайдер" начинается с приложения
"Конфигуратор", в котором осуществляются основные пользовательские настройки
системы. Этот процесс является, по существу, инвентаризацией ресурсов,
контролируемых системой, и если ошибиться на этом этапе, то весь последующий
анализ качества связи будет неполным или ошибочным.
В данном приложении в графическом виде строится карта контролируемой сети или ее
участков – так называемых Пользовательских видов. Созданная таким образом
логическая карта является интерактивной и может по-своему использоваться
сотрудниками разных отделов в зависимости от круга решаемых ими задач, например,
для оперативного анализа исправности элементов сети посредством приложения
"Монитор состояния сети", о котором будет рассказано далее. При этом, ответственные
за определенный участок сети сотрудники могут контролировать на карте только
"свои" объекты, не отвлекаясь на другие участки.
Конфигуратор, помимо своей основной задачи – настройки объектов для
последующего анализа, – выполняет функцию учета ресурсов, т. е. используя
Конфигуратор можно быстро найти объект и просмотреть его характеристики
(например, по названию оператора получить типы используемых им АТС, коды их
пунктов сигнализации в случае ОКС-7 и IP-адреса в случае VoIP, реквизиты
контактных лиц, телефоны и т. д.).
В первую очередь данное приложение необходимо для администратора системы,
однако имеющиеся в нем сведения используются и службой эксплуатации.
Детектор злонамеренных вызовов (FMS). Самым, на наш взгляд, удачным
приложением для оперативного выявления проблем на сети с помощью
пользовательских настроек является "Детектор злонамеренных вызовов".
Это единственное приложение, которое выведено на большой экран в помещении, где
находится круглосуточная дежурная смена. Выполняемые им задачи уже давно не те,
которые можно было бы представить, прочитав название. Применив встроенные в
приложение гибкие и удобные настойки, мы используем это средство обнаружения
проблем на сети для следующих целей.
Журнал «Вестник связи», №9, 2007
Выявление проблем с прохождением трафика через операторов (провайдеров).
Не секрет, что разные типы коммутаторов выдают различные типы причин отклонения
вызовов на одно и то же событие в сети в соответствии со своим внутренним
протоколом обработки сигнальных сообщений. А если учесть, что сейчас широко
начинают внедряться коммутаторы, где объединены протоколы стандартной телефонии
и VoIP (в частности, Softswitch), то результат работы в них алгоритма обработки
сигнальных сообщений по разным видам сигнализации при их взаимодействии
становится заранее трудно предсказуемым. Применение системы анализа вызовов в
этом случае существенно облегчает работу.
В отличие от систем просмотра событий, где мы работаем с показателями качества,
используемыми в отчетах, здесь мы можем более гибко настраивать критерии с
помощью параметров и значений сигнальных сообщений. Например, можно "завести"
конкретную причину или группу причин на определенного оператора (оператор N,
DPC=8 и Cause=34, нет доступных каналов, порог срабатывания 20 вызовов в минуту,
сортировка по DPC). Если завести такие критерии на всех операторов по причинам,
входящим в группу показателя качества RU (недоступность ресурса), то данная
проблема будет закрыта.
Сообщения приложения FMS приходят в on-line режиме и по ним фиксируются номера
Б. Это еще одно полезное свойство детектора – возможность "раскрытия" сообщения и
просмотра полей конкретных CDR, которые и послужили причиной появления
события.
Практически все события, произошедшие в сети и зарегистрированные по созданным
нами критериям, были проанализированы и признаны опасными.
Исключения составляют критерии, связанные с появлением на сети А-номера, Бномера или списка номеров, которые мы хотели своевременно видеть, – этот список
можно создать заранее и далее только редактировать.
Мы применяем правила "черного списка" для отслеживания вызовов от наших
клиентов на номера, на которые клиенту запрещено звонить в соответствии с
заключенным с ним договором.
Похожее применение – это поиск "длинных", возможно зависших вызовов. Такое
происходит, когда ни от одной из сторон не приходит сигнальное сообщение
разъединения, в этом случае отбивается тот коммутатор, на котором установлено
меньшее время ожидания данного сообщения, но на некоторых коммутаторах этого
ограничения сделать нельзя по причинам технических особенностей или же
организационных запретов. В этом случае помогает данное приложение. Настройкой
одного критерия времени разговора ">1ч" мы сможем отследить все вызовы, имеющие
соответствующую продолжительность разговора, и сообщить службе эксплуатации о
необходимости разъединения данного вызова вручную. Можно отфильтровать (по
номерам А) вызовы, которые бы вы не хотели, чтобы отображались, например,
модемные соединения.
Журнал «Вестник связи», №9, 2007
Немаловажное применение данного приложения – это отслеживание, так называемых,
петель трафика (looping) через сопряженных операторов. Петли бывают двух типов:
простая и сложная.
Простая петля – это ситуация с одним вызовом, когда он приходит от оператора X к
оператору Y, а затем отправляется от оператораY к оператору X. Такая ошибка
маршрутизации приводит к тому, что данный вызов может "гулять" до тех пор, пока
есть доступные каналы между этими двумя операторами.
Сложная или неявная петля – это случай, когда один вызов приходит от оператора X к
оператору Y, а затем отправляется от оператора Y к оператору Z, который, в свою
очередь, отсылает этот вызов к оператору X, после чего цикл может повториться. В
данном случае решить проблему можно только с помощью оператора, инициирующего
вызов.
Возможны еще более запутанные петли, например, когда вызов приходит от оператора
X к оператору Y, затем отправляется от оператора Y к оператору Z, после чего
приходит от оператора Z к оператору N. Может так случиться, что в петле будет
задействовано и большее количество операторов. На практике у нас их количество
доходило до пяти. Как выявлять такие петли с помощью приложения FMS?
Довольно просто это делается для вызовов, которые закончились разговором. Для этого
задаем: длительность разговора > 1 мс, DPC (или IP-адрес адресата) вашего
коммутатора (шлюз), фильтрацию по модифицированному Б-номеру, период
срабатывания – 2 вызова за период времени 5 с.
Если же вызовы – несостоявшиеся, тогда повторяем те же действия, но устанавливаем
время разговора = 0. В этом случае алгоритм выявления петли будет не совсем точным,
так как на различных коммутаторах есть возможность, так называемого, "переанализа
по качеству".
Последнее означает, что в случае отклонения вызова по одной из причин группы RU
(недоступность ресурса) коммутатор может направить данный вызов на второй и
третий маршруты, а если доступен только один маршрут, то система может направлять
один и тот же вызов несколько раз подряд на ваш адрес. Существуют специальные
программы анализа качества для VoIP-маршрутизаторов, которые, получив отказ,
могут выдавать до 10 вызовов подряд с интервалом в 1 с. Определить образовалась ли
петля в данном случае или работает система анализа качества становится
затруднительно, а для дежурной смены такая информация – головная боль.
Поэтому, чтобы не отвлекать на подробный анализ трафика круглосуточную дежурную
смену, сотрудники которой помимо этого тестируют направления, принимают и сдают
заявки, выдаваемая системой мониторинга информация должна быть краткой, но
детально информативной по глобальным проблемам на сети, а события должны иметь
названия, раскрывающие конкретную аварию (например, "Петля через оператора N",
"Cause 34 оператор N") и цветовую индикацию уровня опасности.
Журнал «Вестник связи», №9, 2007
Обнаруженные системой события можно вывести в виде отчетов за определенные
периоды времени.
Но мы у себя практически их не используем, за исключением "черного списка",
предпочитая отчеты из CDR-браузеров, формат которых, на наш взгляд, удобнее для
просмотра.
Приложение FMS используется для работы отделом мониторинга и статистики,
диспетчерской службой (отделом технической поддержки клиентов), Helpdesk-ом
(инженерами круглосуточной дежурной смены), а также в редких случаях службой
эксплуатации.
Монитор состояния сети
Монитор состояния сети представляет собой графическое воплощение связей объектов
мониторинга между собой. Если с помощью системы мониторинга контролируется
трафик основных коммутационных узлов, то это приложение показывает состояние
сети с точки зрения качества прохождения трафика через эти узлы как глобально, так и
на отдельных участках с помощью пользовательских видов (эти пользовательские виды
создаются в Конфигураторе). Графическое отображение проблемных участков сети
вместе с окном событий позволяют наиболее эффективно реагировать на возникшую
проблему и квалифицировать ее по степени опасности.
Список событий, отображаемых при наведении на соответствующий объект карты,
можно вывести как "за последние 2 часа", так и без ограничения по времени (50
последних записей по направлению). В случае, когда событие попадает в категорию
тревожных (например, низкий ASR), луч-направление окрашивается в красный цвет,
при восстановлении – в зеленый, при наведении курсора на направление выводятся все
события в зависимости от выбранного временного интервала. На карте монитора
состояния сети можно увидеть и краткую техническую характеристику элементов сети
(коммутаторов, шлюзов), заведенную в Конфигураторе.
На графической схеме сети разными цветами показываются возникновения событий в
соответствии с заведенными нами правилами в Системе анализа качества (QoS). У нас
на сети работают два основных варианта правил.
Первый – событие возникает при ASR < 10 % и количестве вызовов
TotalCalls > 30. Для таких событий выбираем шаг расчета (15 мин.; 1 ч или 1 день) и
задаем степень опасности. После этого, если трафик, маршрутизируемый, например, на
оператора N, имеет ASR < 10 % по региону 812 при количестве вызовов больше 30, то
это событие появится в списке, окрашенном в заданный нами цвет. В зависимости от
установленной степени опасности, данное событие будет влиять на окраску линий
сигнального маршрута. При изменении состояния работает обратное правило, которое
также задается пользователем. Для того же примера, трафик на оператора N имеет ASR
> 10 % по региону 812, при количестве вызовов более 30, событие окрашивается в
другой цвет (например, зеленый).
Журнал «Вестник связи», №9, 2007
Второй вариант – событие возникает при количестве вызовов TotalCalls > 30, параметр
RU (resource unavailable) > 50 %, шаг ставим тот же; т. е. если трафик,
маршрутизируемый, например, на оператора "Ростелеком" имеет параметр RU > 50 %
по региону 812 при количестве вызовов более 30, то система генерирует событие, а
результат будет отображен на карте.
В нашей компании, чтобы сотрудникам было проще разбираться с возникающими
событиями, для дежурной смены применяются только простые правила, но они
созданы таким образом, чтобы эффект от них был максимальным.
При создании сложного правила из комбинации нескольких критериев зачастую
приходится тратить больше времени на анализ проблемы, чем при использовании
одного или нескольких простых. На наш взгляд, целесообразно выбрать 2 – 3 правила,
содержащих не более 2 – 3 критериев, которые способны наиболее эффективно
отобразить в виде событий важнейшие или часто возникающие сетевые проблемы, с
сохранением возможности реагирования на них в кратчайшие сроки. Сложные правила
применяются для решения нетривиальных задач опытными аналитиками.
Данное приложение в нашей компании используется для работы сотрудниками,
контролирующими качественные показатели на сети связи, – отделом мониторинга и
статистики, диспетчерской службой (отделом технической поддержки клиентов) и
Helpdesk-ом, а также, в редких случаях, службой эксплуатации.
CDR-обозреватели
CDR-обозреватели – это приложения для работы с детализированными записями о
вызовах по различным протоколам. У нас на сети применяются обозреватели для
протоколов ISUP (ОКС-7 и Sigtran), DSS1 (PRI и Sigtran), H.323 и SIP. Все они
позволяют оперативно получать отчеты, как по отдельным вызовам, так и по группам
вызовов, комбинировать в фильтрах все основные значения информационных
элементов сигнальных сообщений, анализировать прохождение трафика на примере
конкретных вызовов, а также работать с детальной трассировкой вызова.
В данных приложениях настраиваются таблицы трансляций, где находятся коды и
названия регионов, разбитые по типам номеров (международные, междугородные,
местные). Здесь же определяются правила трансляции номеров: ведь не секрет, что не
все операторы работают в соответствии с международными рекомендациями
трансляции географических кодов стран и населенных пунктов (кто-то добавляет
префикс 8 и 810, кто-то требует транслировать МГ-трафик без 8 и т. д.), для VoIP
характерно добавление тэч-префиксов. Чтобы результаты анализа правильно
отображались в отчетах по QoS, требуется создать правила, с помощью которых
система мониторинга формирует модифицированные номера, приведенные к единому
стандарту.
Непосредственно из окна CDR-обозревателя доступны для просмотра результаты
трассировки вызовов (так называемое побитовое декодирование) в виде, удобном, как
для анализа проблемы на своей сети, так и для отправки в техническую службу
оператора в качестве доказательства существования проблемы.
Журнал «Вестник связи», №9, 2007
Отчеты по CDR важны для сопоставления с данными биллинга; в случае ошибки или
сбоя в биллинговой программе, данные по CDR можно восстановить из базы данных
системы "Спайдер". Как правило, в биллинге хранятся данные только по состоявшимся
вызовам, в то время как в случае запроса, например, из правоохранительных органов
или из собственной службы безопасности всю необходимую информацию о
прохождении любого вызова через сеть можно получить с помощью настоящего
приложения из БД системы мониторинга. Причем вне зависимости от того, состоялся
разговор или нет.
CDR-обозреватели используют в своей работе отделы мониторинга и статистики,
служба эксплуатации и Helpdesk (инженеры круглосуточной дежурной смены).
Диспетчерской службой (отделом технической поддержки клиентов) используется
редко – только для обнаружения вызова без проведения детального анализа.
Отчеты QoS
Создание регулярных отчетов по качеству предоставления услуг связи (QoS) играет
важную роль в круглосуточном глобальном видении состояния сети компании в
реальном времени, так как на основе отчетов строится стратегия маршрутизации
трафика. По нашей просьбе отчеты, доступные через пользовательский интерфейс,
были продублированы и на web-страничке. Не всем пользователям системы "Спайдер"
нужен доступ к довольно мощному средству анализа – приложению "Система анализа
качества" (QoS), которое, к тому же, требует осознанных действий специалистааналитика по постепенному раскрытию (drill-down) информации с целью поиска
первопричины аномального события.
С помощью автоматически создаваемых отчетов по операторам и регионам, доступных
через web-интерфейс, сотрудники компании оперативно получают информацию о
прохождении трафика по тому или иному региону через того или иного оператора.
Через web-интерфейс администратор создает папки отчетов, разделенные на две
группы: Регионы и Операторы.
Каждая группа папок администратором настраивается отдельно. В папках "Операторы"
за определенный период (15 мин., 1 ч, 1 день, 1 неделя, 1 месяц) с разделением по типу
отчета (протокола сигнализации) выбирается название нужного оператора, и при
раскрытии выводится таблица со значениями основных качественных показателей. Для
папок "Регионы" характерно обратное правило: раскрытие происходит по кодуназванию региона, построчно выводятся названия операторов, через которых данный
трафик направлялся. Низкие показатели качества окрашиваются в соответствующий
цвет. Все отчеты могут быть сохранены в Excel и HTML-форматах.
Данное приложение необходимо для отдела мониторинга, отдела по межоператорским
отношениям, для сотрудников, которые принимают решения о перемаршрутизации
трафика, для менеджеров, которые "ведут" крупных корпоративных VIP-клиентов и
отслеживают состояние трафика от них, для дежурной смены и диспетчерской службы.
В редких случаях это приложение может быть интересно и службе эксплуатации.
Журнал «Вестник связи», №9, 2007
Система анализа качества (QoS)
В данном приложении настраиваются счетчики и показатели, осуществляются
настройки монитора состояния сети и системы просмотра событий, создаются
пользовательские объекты (отчеты). Созданные пользователями отчеты представляют
собой логические комбинации из отдельных элементов основных системных объектов
анализа: Операторов, Регионов, Направлений.
Указав автоматическую генерацию отчета за период от 15 мин. до 1 месяца, можно
добиться того, что будут автоматически создаваться любые отчеты, которые затем
рассылаются соответствующим сотрудникам компании для анализа. У нас создаются
отчеты следующих видов:
 суммарные отчеты по регионам и операторам (направлениям) за час и задень,
разбитые в соответствии с протоколами сигнализации;
 отчеты по группе регионов (например, СНГ);
 отчеты по отдельным телефонным номерам.
Все эти отчеты востребованы различными подразделениями компании – технической
дирекцией, дирекцией по развитию, дирекцией по межоператорским связям, отделом
технической поддержки клиентов (диспетчерской службой) и др.
В этом же приложении находится и окно событий, где в online режиме автоматически
могут отображаться события согласно описанию приложения "Система просмотра
событий". Окно событий используется круглосуточной дежурной сменой наравне с
окном приложения FMS.
При анализе качества удобен формат вывода событий, открываемый через "Систему
анализа качества" (QoS). В "Системе анализа качества" список событий содержит
следующие поля: оператор, объект анализа, регион, показатель. Последнее поле
содержит показатель(и) качества, для которых мы задали пороговые значения, само
значение порога и шаг (интервал времени анализа события).
В основном, это приложение используется для получения отчетов о качестве работы
сети или в тех случаях, когда необходимо провести сложный анализ показателей
качества в зависимости от настроенных пользователем объектов и, соответственно, это
приложение может быть востребовано аналитиками компании.
Анализатор протоколов (Spider Protocol Analyzer)
Помимо указанных выше приложений, в системе "Спайдер" имеются приложения,
представляющие
собой
аналог
анализатора
протоколов
сигнализации,
унифицированное с ПО анализатора протоколов SNTLite. Мониторинг протоколов
ISUP и DSS1 осуществляется на периферийных серверах, к которым подключены
агенты – устройства для пассивного сбора данных непосредственно из канала
сигнализации. По протоколам Sigtran, SIP и Н.323 используется приложение Spider
Protocol Analyzer, где можно выбрать режимы как Online-мониторинга, так и Historyмониторинга (т. е. можно посмотреть любое событие уровня 2 (канального) и уровня 3
(сетевого), произошедшее в течение, к примеру, как у нас, двух месяцев).
Журнал «Вестник связи», №9, 2007
Данное приложение используется в работе как отделом мониторинга, так и службой
эксплуатации коммутационного оборудования. Мобильное переключение агентов с
одного потока Е1 на другой позволяет решить задачу длительного сбора данных и
применяется в тех случаях, когда необходимо обработать большие объемы данных
(вызовов). Портативные приборы – анализаторы протоколов – из-за ограничения
собственных ресурсов для сохранения информации не могут в этом случае успешно
применяться. В первую очередь, мобильное переключение используется нами для
протокола сигнализации PRI DSS1.
Стратегия применения системы мониторинга
Система мониторинга становится важной, фундаментальной частью общей системы
качества на сети связи любого крупного оператора, особенно, если он предоставляет
услуги междугородной и международной связи. Создаваемые с помощью построенной
в Арктел системы "Спайдер" отчеты QoS вместе со статистическими сведениями,
получаемыми с коммутаторов (шлюзов), позволяют в любой момент получить полное
представление о состоянии сети за различные периоды времени.
Система мониторинга органично интегрирована в общую структуру OSS, создаваемую
в Арктел наравне с мониторингом систем передачи данных, Service Desk, Inventory и
корпоративной отчетностью. В настоящее время IT-дирекцией принято решение
использовать содержимое БД системы "Спайдер" в качестве основного источника
информации для создаваемой единой системы корпоративной отчетности.
На базе системы анализа качественных показателей и CDR из БД системы мониторинга
предполагается также строить и систему автоматического управления трафиком
(автоматическая маршрутизация в соответствии с изменениями качественных
показателей).
Решение о создании единой распределенной системы мониторинга сети связи на базе
выбранной нами системы мониторинга оказалось правильным и эффективным с точки
зрения контроля сети, в которой используется коммутационное оборудование нового
поколения.
Внедрение современных технологий наравне с поддержкой устаревающих требует их
взаимной адаптации, что в значительной степени делает каждый подобный проект
уникальным, требующим доработок со стороны производителя оборудования.
Для выявления проблем адаптации технологий система "Спайдер" проявила себя очень
эффективно, с ее помощью были обнаружены проблемы еще на стадии ввода
оборудования в эксплуатацию, что позволило избежать многих рисков и денежных
потерь. Коррекции, сделанные производителем коммутационного оборудования на
основе данных системы мониторинга, позволили в короткие сроки добиться
ожидаемого эффекта от использования услуг, ставших возможными в связи с
применением новейших технологий.