Comments 19
Интересно, получается rrdtool можно использовать и для прогнозирования загрузки, например, и веб серверов, и вычислять таким образом DOS атаки?
Для работы данной системы необходимо большое количество входных данных, т.к. иначе статистику не подвести.
Проводилась ли оценка минимального количества входных данных при которых будет работать данная система вменяемо? Можете поделиться наблюдениями?
Проводилась ли оценка минимального количества входных данных при которых будет работать данная система вменяемо? Можете поделиться наблюдениями?
Если мы говорим о конкретно данной задаче, то естественно проводилась оценка. Эмпирически выведено, что при трафике на/от партнёра или на направление в среднем за сутки равном или большем 25 минут за 15 минут (то есть в среднем за сутки больше 2-х постоянно активных звонков) система работает корректно. Если я не понятно объяснил, напишите, могу иначе объяснить.
Продукт не распостраняется, как я понял? Или просто ссылку не увидел?
а с выходными как поступаете? у нас в сотовой связи трафик в выходные очень сильно отличается от будних дней… да и по пятницам тоже обычно рост есть по сравнению с неделей. У вас делаются какие-то дополнительные прогнозы по подобным флуктуациям?
вообще крайне интересная и познавательная статья! большое спасибо!
вообще крайне интересная и познавательная статья! большое спасибо!
С выходными ничего делать не надо. Дело в том, что прогнозирование, как я писал, краткосрочное, в прогнозе используется наряду с историей за предыдущие дни ещё и текущие значения. Да, есть вероятность ложного алерта из-за быстрого роста трафика, но она не большая и человек, обрабатывающий алерт быстро понимает в чем дело.
Отличная статья, спасибо! Хотелось бы увидеть продолжение цикла, в частности о практической части на примере мониторинга сетевого трафика.
А скажите почему вы не обсоновав забраковали IP SLA? чем он не подходит для транзитного оператора?
Тут есть несколько причин почему IP SLA не подходит для транзитника.
1) У вас 300 партнеров, даже если у каждого есть CISCO попробуйте договориться с каждым.
2) Опять же у каждого из партнеров может быть несколько шлюзов расположенных в разных подсетях.
3) Партнеры обычно предоставляют несколько направлений, одно может работать, другое в то же самое время, может не работать.
4) Всегда бывают определенные не согласования по кодекам или сигнализации между поставщиками и потребителями трафика. Грубо говоря, если потребитель А успешно потребляет трафик у поставщика В, то совсем не факт, что потребитель С будет так же успешно потреблять у поставщика В.
5) Допустим вы договорились с каждым партнером и настроили IP SLA, думаю ваш маршрутизатор просто загнется если вы сконфигурируете на нем 500 IP SLA тестов.
Не факт, что перечислил все причины.
1) У вас 300 партнеров, даже если у каждого есть CISCO попробуйте договориться с каждым.
2) Опять же у каждого из партнеров может быть несколько шлюзов расположенных в разных подсетях.
3) Партнеры обычно предоставляют несколько направлений, одно может работать, другое в то же самое время, может не работать.
4) Всегда бывают определенные не согласования по кодекам или сигнализации между поставщиками и потребителями трафика. Грубо говоря, если потребитель А успешно потребляет трафик у поставщика В, то совсем не факт, что потребитель С будет так же успешно потреблять у поставщика В.
5) Допустим вы договорились с каждым партнером и настроили IP SLA, думаю ваш маршрутизатор просто загнется если вы сконфигурируете на нем 500 IP SLA тестов.
Не факт, что перечислил все причины.
Но в таком случае для сбора QoS вы полагаетесь на то, что конечные устройства будут использовать RTCP, правильно? а на практике далеко не все устройства испольуют rtcp, соответственно qos метрик может не оказаться в CDR при необходимости.
Возможно и не всегда у партнера включен RTCP, но в основном — включен. Я не готов сказать на сколько часто он не включен. Но, в любом случае софтсвитч проксирует через себя RTP. Вся прелесть RTCP в том, что вы видите не только jitter-ы и потери пакетов отсылаемых на вас, но и знаете о том, что видит вторая сторона. Если даже у партнера не включен RTCP, то вы по меньшей мере можете сказать что происходило на вашей стороне и с этой точки зрения судить о качестве.
Я не говорил, что мы мониторим rfactor, jitter-ы и потери пакетов. Мы просто можем при необходимости это увидеть в CDR-ах, эти поля всегда не нулевые, если был RTP.
Мы мониторим качество на основании значений ASR и ACD.
К примеру, ACD на направлении в среднем был 3 минуты, потом стал 30 секунд. Возможная причина в плохом качестве голоса, конечные потребители — люди которые звонят плохо слышат друг друга и ложат трубку. Получается этот параметр сродни чистого MOS (Mean Opinion Score). При получении алерта по ACD можно быстро проанализировать трафик, протестировать звонками поставщика и, в случае необходимости убрать, поставщика из маршрутизации.
Я уже писал, что тут много тонкостей и они не всегда очевидны, если вы не работаете у транзитника.
Я не говорил, что мы мониторим rfactor, jitter-ы и потери пакетов. Мы просто можем при необходимости это увидеть в CDR-ах, эти поля всегда не нулевые, если был RTP.
Мы мониторим качество на основании значений ASR и ACD.
К примеру, ACD на направлении в среднем был 3 минуты, потом стал 30 секунд. Возможная причина в плохом качестве голоса, конечные потребители — люди которые звонят плохо слышат друг друга и ложат трубку. Получается этот параметр сродни чистого MOS (Mean Opinion Score). При получении алерта по ACD можно быстро проанализировать трафик, протестировать звонками поставщика и, в случае необходимости убрать, поставщика из маршрутизации.
Я уже писал, что тут много тонкостей и они не всегда очевидны, если вы не работаете у транзитника.
И вам не кажется, что логичнее было бы рассматривать для истории прогнозирования не трое предыдущих суток, а один и тот же день недели за предыдущие недели. все таки профиль трафика ( даже аггрегированного) за разные рабочие дни сильно отличается и вторник будет больше похож на вторник прошлой недели, чем на понедельник.
1) Я не рассматриваю 3 последних дня, я рассматриваю 28 последние дней и всю историю по ним, именно так у меня сконфигурировано. В статье рисунок — просто пример того как трафик ведет себя за три дня, мог бы нарисовать за больше, но он был бы не очень понятен.
2) Может быть рассматривать один и тот же день недели и логичней, только не знаю как это реализовать на rrdtool. Да, я бы мог легко на графике выводить не предыдущий день а тот же день прошлой недели. Но это для данной задачи не верно. Цены партнеров могут меняться несколько раз в неделю. Допустим поставщик дал хорошую цену на определенное направление, звонки будут маршрутизироваться на него, транзитник даст хорошую цену потребителю и на поставщика пойдет большой объем трафика, и к примеру он не справится с возросшим объемом. Профиль трафика на направлении и у поставщика и у потребителя быстро поменяется. Наверняка система даст один или несколько алертов. В данном случае для анализа того, почему это произошло необходимо сравнивать с предыдущим днем, а не с тем, что было неделю назад.
2) Может быть рассматривать один и тот же день недели и логичней, только не знаю как это реализовать на rrdtool. Да, я бы мог легко на графике выводить не предыдущий день а тот же день прошлой недели. Но это для данной задачи не верно. Цены партнеров могут меняться несколько раз в неделю. Допустим поставщик дал хорошую цену на определенное направление, звонки будут маршрутизироваться на него, транзитник даст хорошую цену потребителю и на поставщика пойдет большой объем трафика, и к примеру он не справится с возросшим объемом. Профиль трафика на направлении и у поставщика и у потребителя быстро поменяется. Наверняка система даст один или несколько алертов. В данном случае для анализа того, почему это произошло необходимо сравнивать с предыдущим днем, а не с тем, что было неделю назад.
Большое спасибо за статью, она подсказала как решить мою проблему.
Sign up to leave a comment.
Мониторинг транзитного VoIP, методом прогнозирования