Аннотация
Даже если вы не используете VoIP в своей системе, или это не основное ваше направление, вас может заинтересовать сам метод мониторинга с помощью прогнозирования потому, что его можно успешно применять не только для транзитного VoIP. Метод мониторинга рассматривается на примере приложения к транзитному VoIP потому, что данная задача — яркий пример его использования. Стандартными методами задача не решается, а мониторинг методом прогнозирования реализуется сравнительно просто. То, что написано ниже, это не теоретические изыскания, это уже несколько месяцев успешно используется на практике.
Введение
Большинство современных активных систем мониторинга IT инфраструктуры используют одинаковый принцип. Система мониторинга неким образом опрашивает оборудование или программное обеспечение, получает результат и сравнивает его либо с шаблоном, либо с заранее заданными предельно допустимыми значениями.
К примеру, для определения доступности SMTP сервера, система мониторинга должна подключиться к серверу на 25 порт TCP, передать строку “helo my.monitoring.com” получить в ответ строку и отключиться от SMTP сервера. Далее проверить содержит ли строка ответа сервера в начале трёхзначный код, начинающийся с цифры 2. Если это так, то сервер живой, если нет, система должна дать оповещение. Фактически это метод сравнения по шаблону.
Другой пример — проверка загрузки процессора. Система мониторинга, чаше всего по SNMP, опрашивает сервер, получает значение текущей загрузки процессора, и сравнивает его с предельно допустимым максимальным значением, допустим 80. Если процессор загружен более чем на 80%, система мониторинга должна дать оповещение. Это метод проверки предельно допустимых значений опрашиваемых величин.
В любом случае, в процессе конфигурирования системы мониторинга вам необходимо задавать четкие критерии того, что надо считать нормальной работой вашего оборудования или программного обеспечения, а что – сбоем, или ситуацией, которая может привести к сбою в ближайшем будущем.
Такой принцип мониторинга работает в большинстве случаев. Однако порой, задать критерии того, что считать сбоем, а что нормальной работой, слишком сложно или вообще не возможно.
Одной из задач мониторинга, которая не решается стандартными методами является задача мониторинга количественных и качественных параметров транзитного VoIP. Прежде чем описывать, как работает система мониторинга, основанная на прогнозировании, необходимо описать, как работает транзитный VoIP провайдер.
Транзитный VoIP, как это работает
Как и в любом деле, в транзитном VoIP, существует много нюансов, объяснять которые слишком долго, да и ни к чему. Поэтому описание будет на примитивном уровне, что называется, на пальцах.
Рассматривать этот вопрос следует не на уровне конечного потребителя – человека который звонит, а на уровне компаний, которые предоставляют VoIP услугу. С этой точки зрения в предоставлении услуги участвуют две компании. Первая, компания A, является потребителем VoIP трафика, клиент которой инициирует звонок, вторая, компания B — поставщиком, который терминирует звонок.
Поставщик обычно поставляет одно или несколько направлений. Направлением называют группу телефонных кодов, продаваемую по определённой цене. Пример направлений: Russia Mobile BeeLine, Spain Madrid, Kazakhstan Almaty. В настоящий момент в мире насчитывается около 1300 направлений.
Компания потребитель обычно предоставляет своим клиентам все направления – это называется A-to-Z. Поэтому потребителю необходимо заключить контракты со многими поставщиками различных направлений, после чего маршрутизировать направления на различных поставщиков. Сделать это довольно сложно.
С другой стороны, поставщик заинтересован в привлечении к себе как можно большего объёма трафика. Однако это сопряжено с большим количеством контрактов и потенциальными финансовыми рисками, к примеру, одна или несколько из многих компаний может не заплатить за потребленный трафик.
Поэтому как поставщикам, так и потребителям, выгодно работать с компанией посредником — транзитником, которая, строго говоря, сама не генерирует и не поставляет VoIP трафик, но связывает их между собой.
Фактически, вместо много связанной структуры взаимодействия между поставщиками и потребителями получается структура звезда, в центре которой транзитник.
Чаще всего транзитник проксирует через себя и сигнализацию и голос.
У компании, в которой развернута описываемая система мониторинга порядка 250 поставщиков и 250 потребителей. Компания предоставляет A-to-Z направления, всего в биллинге прописано около 1500 названий направлений.
Транзитнику крайне важно осуществлять мониторинг того, как работают потребители, поставщики и направления. Причем делать это в разрезе каждого потребителя, поставщика и направления. В краткосрочной перспективе, в случае сбоя транзитник теряет маржу. В долгосрочной перспективе — все заинтересованы в высоком уровне сервиса.
Теперь, после того как в общих чертах обрисована схема работы транзитника, сформулирую задачу системы мониторинга.
Задача системы мониторинга
Когда заходит речь о мониторинге VoIP, обычно подразумевается мониторинг таких параметров, как jitter, задержки, потери пакетов, MOS. Сильная технология есть у Cisco, 4 года назад я уже писал об этом.
Однако, для транзитного VoIP оператора, использование подобных технологий и анализ подобных метрик не подходит. Естественно, транзитник анализирует и процент потери пакетов, и jitter-ы и задержки, до партнеров, но делает это только после обнаружения сбоя. Сами же сбои выявляются путём анализа других параметров, как то:
• Общее количество минут.
• Общее количество звонков.
• ASR (Answer Seizure Ratio) определяется как отношение успешных звонков с ненулевой длительностью к общему количеству звонков.
• ACD (Average Call Duration) средняя длительность звонка.
Первые два параметра количественные, последние два – качественные. Можно долго объяснять, почему анализируются именно эти параметры, однако это выйдет за рамки статьи.
Необходимо так же отметить, что обычно системы мониторинга опрашивают удаленные устройства тем либо иным способом, описываемая система мониторинга в качестве источника данных использует CDR-ы (Call Details Records). Файл CDR-ов представляет собой текст, в каждой строке которого записана информация по одному звонку или попытке совершить звонок. Уровень детализации по конкретному звонку может быть разным, все зависит от того, какое оборудование пишет CDR-ы. Качественный CDR может содержать около 100 параметров, в нем содержится не только информация о том, кто звонил, куда звонил, длительность звонка и код завершения звонка, но так же, если речь идет о VoIP, такие параметры, как jitter, кодеки, потери пакетов, MOS и прочие.
Давайте посчитаем, сколько всего величин должна проверять на наличие потенциального сбоя система мониторинга. Необходимо анализировать параметры по 250 поставщикам, 250 потребителям и 1500 направлениям. Для каждого поставщика, потребителя и направления надо проверять 4 величины, итого у нас получится:
250*4+250*4+1500*4 = 8000
Но дело тут не в сравнительно большом количестве величин, которые необходимо проверять. Дело в том, каждый из партнеров и каждое направление по своему уникальны, более того, параметры работы каждого из партнеров и направлений очень сильно зависят от времени суток.
Чтобы не быть голословным рассмотрим несколько примеров построенных по данным реального трафика.
На графике показано распределение трафика по минутам двух партнёров расположенных в одной географической зоне. Величины на графике — количество минут потребленных партнёром за 15 минутный интервал времени. Если для первого партнёра после 8 до 22 часов нормой потребления является порядка 2500 минут за 15 минут, то для второго, не больше 500. Если первый партнёр с 8 до 18 часов начнёт потреблять меньше 1500 или больше 4000 минут, то это может означать, что произошел сбой и надо анализировать причину. Для второго партнёра это не так, для него другие критерии потенциального сбоя.
Другой пример.
На графике показано распределение трафика по звонкам. Величины на графике – количество звонков в 15-ти минутный интервал, совершенных на 3 различных направления с сопоставимым объёмом трафика. Первые два направления в близких географических зонах, третье – географически удалено, то есть в этой стране другой часовой пояс.
Надеюсь, очевидно, что выставлять критерии для мониторинга трафика очень сложно. Задача на практике стандартными методами не решается.
Метод прогнозирования, почему это должно работать
Не смотря на то, что каждое направление и партнёр по своему уникальны, количественные и качественные параметры работы поддаются прогнозированию. К примеру, рассмотрим график работы одного из направлений за трое последовательных суток, для наглядности изобразим каждые сутки на одном и том же графике разным цветом.
Логично предположить, что подобным же образом будут распределяться звонки на направление и на четвёртый день. Фактически можно спрогнозировать как должно вести себя направление, и, если направление ведёт себя не так, как прогнозировано, давать оповещение о потенциальном сбое.
Таким образом, задачу можно решить, написав программное обеспечение, которое умеет прогнозировать. Методов прогнозирования на текущий момент разработано много. Однако программно реализовать один из методов прогнозирования довольно сложно, выгодней использовать готовый продукт.
Функционал прогнозирования встроен в очень известный и популярный продукт – rrdtool, который распространяется под GPL.
Метод прогнозирования реализованный в rrdtool
Не смотря на то, что я активно использую rrdtool на протяжении уже более 10 лет, признаться, до недавнего времени, даже не подозревал, что в него встроен функционал прогнозирования. Сама идея использовать прогнозирование для мониторинга VoIP возникла после прочтения статьи Jake D. Brutlag “Aberrant Behavior Detection in Time Series for Network Monitoring” За что выражаю автору свою признательность.
Метод прогнозирования используется в системе мониторинга cricket. Однако данный программный продукт давно не развивается, кроме того, cricket опрашивает устройства по SNMP, а для мониторинга VoIP трафика, как я писал выше, надо обрабатывать CDR-ы. Есть ещё несколько систем мониторинга, использующих прогнозирование, реализованное в rrdtool, однако ни одна из них не подходила, поэтому пришлось писать свою систему мониторинга с нуля.
Признаться, изначально не было уверенности, что это будет работать. Поэтому сначала метод мониторинга был опробован на IP трафике. Простейшими скриптами опрашивались счетчики интерфейсов, полученными значениями заполнялась специальным образом сформированные базы rrd. После того, как методом прогнозирования было выявлено несколько глобальных сбоев, стало окончательно ясно, что метод работает корректно.
В статье Jake D. Brutlag, есть формулы, которые используются для прогнозирования и много полезной информации, однако я объясню, как это работает немного иначе, не вдаваясь в подробности и технические детали.
Для того, чтобы rrdtool начал прогнозировать необходимо определенным образом создать базу данных rrd. При создании базы данных задаются параметры для прогнозирования, как то длительность сезона, и различные коэффициенты, влияющие на прогноз. Далее, вы просто заполняете базу данных rrd значениями измерений, а работу по прогнозированию и выявлению потенциальных сбоев берет на себя rrdtool.
В rrdtool реализован метод прогнозирования Хольта-Винтерса, кроме того, реализован механизм обнаружения аберраций измеряемой величины по отношению к спрогнозированным величинам.
Согласно Wikipedia: аберрация — отклонение от нормы; ошибки, нарушения, погрешности (лат. aberratio «уклонение, удаление, отвлечение», от лат. aberrare (лат. ab- «от» + лат. errare «блуждать, заблуждаться») — «удаляться, отклоняться»).
Понять, что такое аберрации можно просто взглянув на рисунок.
В прогнозировании методом Хольта-Винтерса используется понятие сезонов. Для IP и VoIP трафика сезон обычно равен одним суткам. Однако вы можете задать сезон произвольной длительности.
Метод Хольта-Винтерса вычисляет прогноз сразу по двум значениям – первое значение собственно прогноз измеряемой величины, и второе значение – прогноз допустимого отклонения измеряемой величины от спрогнозированных значений (deviation). Фактически вторая величина влияет на ширину коридора допустимых отклонений прогноза от реальных значений.
Ещё один немаловажный факт, метод Хольта-Винтерса является методом краткосрочного прогнозирования, это значит, что прогноз не строится сразу на весь сезон (в нашем случае не сразу на целые сутки). Фактически, при каждом новом измерении величины строится прогноз её следующего значения, для вычисления которого используется история предыдущих измерений и последнее значение измерения. Есть коэффициент, который можно варьировать, от него зависит, в какой мере предыдущая история и последнее измерение влияют на прогноз.
Аберрация выявляется на основании нескольких измерений, при этом используется плавающее окно. То есть, если измерение выбивается за коридор допустимых значений, это не всегда приводит к появлению аберрации. По умолчанию аберрация возникает тогда, когда семь из последних девяти измерений выбиваются из прогнозированного коридора допустимых значений. Однако вы также можете варьировать параметры и выставить, допустим, длину окна равную 3 и количество не попаданий в окно равным 2, тогда аберрация будет возникать, когда два из последних трёх измерений выбиваются из коридора.
Если вы работали с rrdtool, то знаете, насколько это мощное средство для построения графиков. Поясню последние 3 абзаца на графиках. Такие графики строятся в описываемой системе мониторинга.
Синяя линия второй толщины это реальные значения измерений количества минут потреблённых партнёром. Серая площадь – реальные значения, которые были ровно сутки назад. Розовая линия — прогноз. Красная и зелёные линии показывают верхнюю и нижнюю границу коридора допустимых значений. Черная линия в области отрицательных значений – прогноз допустимых отклонений от спрогнозированных значений (deviation). Фактически черная линия задаёт ширину коридора. По умолчанию, нижняя и верхняя границы коридора (отображаемые красной и зелёными линиями) получаются путём сложения, для верхней границы и вычитания для нижней границы спрогнозированной величины и прогноза отклонений умноженного на 2. Золотым цветом показаны аберрации.
Рассмотрим аберрации ближе.
Видно, что аберрация возникла через некоторое время после того, как значения выбились из коридора, в данном случае база данных rrd настроена по умолчанию с длиной окна равным 9 и количеством не попаданий в окно равным 7.
Аберрации легко отобразить на графиках, однако система мониторинга должна сама программно выявлять момент возникновения аберрации, чтобы сигнализировать об этом. Программное выявление возникновения аберраций так же легко реализуется средствами rrdtool
Rrdtool строит графики в виде рисунков, область отображения графика на рисунке имеет постоянные координаты, поэтому не сложно написать процедуру или класс для масштабирования графиков по оси времени по нажатию кнопок мыши. Если вы используете cacti, который собственно является WEB GUI для rrdtool, то можете посмотреть, как там это реализовано java скриптом.
В описываемой системе мониторинга ядром системы является rrdtool. Однако только функционала прогнозирования и выявления потенциальных сбоев не достаточно. Когда система выдала оповещение о сбое, важно быстро получить доступ к данным для анализа ситуации. Поэтому в ней реализованы дополнительные возможности для анализа VoIP трафика. Для того, чтобы просто описать дополнительные возможности системы мониторинга рассмотрим в общих чертах как она устроена.
Как устроена система мониторинга
Схема работы системы мониторинга представлена на рисунке ниже.
Каждые 15 минут обрабатывается новый файл CDR-ов. В файле может быть до 150000 записей. Данные парсятся и заносятся в базу данных postgresql, которая хранит “сырые” CDR-ы в течение 28 дней. В день в базе данных CDR-ов накапливается до 10 миллионов записей, всего – порядка 250 миллионов. Естественно, для увеличения производительности запросов на выборку информации за произвольный период в разрезе партнеров и направлений, также заполняются дополнительные таблицы, содержащие сводную информацию достаточную для формирования отчетов. В сводную таблицу попадает порядка 200 тысяч записей в день, а на таких объемах база данных отрабатывает запросы на выборку, даже за период в несколько недель, очень быстро.
Далее, путем запроса в базу данных CDR-ов, выбираются данные, которыми заполняются значения баз данных rrd хранящих информацию по ASR, ACD, количеству минут и звонков в разрезе поставщиков, потребителей и направлений. Всего обновляется около 8000 баз данных rrd. В силу особенностей работы rrdtool, если на партнера, или направление не было трафика, в базу данных необходимо записать значение равное 0. После обновление баз данных rrd, каждая из них, проверяется модулем алертинга на предмет возникновения новых аберраций. В случае возникновения аберрации, модуль алертинга может послать письмо по почте, кроме того, при появлении новых алертов, пользователям, у которых запущен клиент системы мониторинга, приходит оповещение изменением цвета иконки клиентского приложения, расположенной в трее.
Обработка одного файла CDR-ов, вместе с отсылкой алертов занимает в худшем случае две с половиной минуты. Серверные приложения написаны на python-е и работают под FreeBSD.
В силу личных предпочтений автора, клиент системы мониторинга – не WEB приложение. Клиентское приложение написано на PyQT. Для общения клиента с сервером используется протокол xmlrpc, работающий для безопасности поверх SSL. Для аутентификации клиента используется HTTP Basic Autentification. Серверное приложение, обслуживающее запросы клиентов, многопотоковое.
Подробно описывать интерфейс клиентского приложения в рамках данной статьи не стоит, так как только документация пользователя – документ на более чем 80 страницах. Опишу лишь в общих чертах, что получают пользователи.
Как используется система мониторинга
Когда вы создаете или описываете некий продукт, прежде всего, необходимо его корректно позиционировать. Изначально планировалось реализовать систему, сигнализирующую о потенциальных сбоях, однако в процессе первоначальной эксплуатации выяснилось, что только функционала выявления сбоя не достаточно, необходим еще инструмент для эффективного анализа причины сбоя. Поэтому, в конце концов, все вылилось в систему мониторинга и анализа трафика. Сейчас продукт позиционируется как система мониторинга и анализа VoIP трафика.
Для мониторинга, как писалось выше, используется функционал прогнозирования реализованный в rrdtool. Есть возможность просмотреть список алертов в виде таблицы и по клику на строке алерта, построить график величины, по которой произошел алерт.
Для анализа трафика используются графики, построенные с помощью rrdtool. Пользователь может строить и анализировать графики по величинам, на которых произошел алерт, а так же, легко может найти интересующие его графики в раскрывающемся списке. Графики (строго говоря, базы данных rrd, из которых они строятся) хранят информацию за последние 28 суток и удобно масштабируются по времени с помощью мышки. К примеру, как на рисунке ниже – можно выделить интересующую область левой кнопкой мышки и за десятые доли секунды получить график за интересующий промежуток времени.
В случае необходимости более детально проанализировать параметры VoIP для выбранного на графике времени, пользователь может одним кликом построить сводный отчет по данным отображенным на графике в виде таблицы по ASR, ACD, минутам и звонкам в разрезе потребитель, поставщик, направление.
В сводном отчете отражаются параметры за выбранный интервал времени, кроме того, можно отобразить и параметры, которые были ровно сутки ранее выбранного интервала времени.
Это позволяет быстро понять, что изменилось в трафике, чтобы далее глубже анализировать причину сбоя.
Для более глубокого анализа пользователь может построить таблицу, в которой отражается информация, детализированная на уровне конкретных звонков, включая кодеки jitter-ы, потери пакетов, MOS и многое другое.
В системе мониторинга реализовано еще много других полезных вещей, описание которых займёт много времени.
Благодаря этому, системой мониторинга пользуются все уровни тех поддержки, отдел контроля маршрутизации. Не смотря на то, что система мониторинга не предоставляет данных по ценам и марже, ею так же пользуется отдел продаж, так как их часто интересует качество работы партнёров и направлений.
Теперь рассмотрим недостатки и преимущества мониторинга методом прогнозирования.
Недостатки метода
К недостаткам можно отнести:
• Сравнительно большую реакционность системы мониторинга. Да, метод срабатывает, сбои выявляются, но не быстро. Даже при длине окна 3 и количестве непопаданий в окно 2 проходит довольно большой интервал времени, прежде, чем система выдаст оповещение о сбое.
• Сравнительно большое количество ложных срабатываний. Однако если рассматривать данную конкретную систему мониторинга, это компенсируется тем, что очень просто определить ложность срабатывания благодаря функционалу для анализа трафика.
• Система построена на анализе статистических данных. Статистика работает прекрасно только для большого количества данных. Если, допустим, на какое-либо направление почти не идёт трафик, то и прогнозировать там нечего.
Преимущества метода
Преимущества следующие:
• Система работает полностью автономно. Не надо выставлять критерии для выявления сбоев, система сама их выставляет. Когда изменяется профиль трафика, система даёт оповещение. Если профиль в целом поменялся, система через некоторое время сама подстроится под новый профиль.
• Реализация с помощью rrdtool очень наглядна. Сотрудники, даже с небольшим опытом работы, быстро обучаются.
• IMHO, на текущий момент это единственный возможный метод мониторинга транзитного VoIP, не требующий значительных финансовых и человеческих ресурсов.
Заключение
Не смотря на довольно большой объём, это обзорная статья. Планируется написать несколько статей, посвящённых методу прогнозирования, реализованному в rrdtool, в которых разложить всё по полочкам. Кроме VoIP-а, мы используем его для мониторинга трафика интернет каналов и даже загрузки процессоров на маршрутизаторах Cisco.
P.S.
Кстати, автор популярной системы мониторинга – Munin, планирует реализовать мониторинг также и с помощью прогнозирования. Вот тут есть фраза об этом – “anomality detection with the help of rrd”. Будем надеяться, скоро увидим эту фичу, в любом случае вы уже знаете, о чём это он…