В данном материале попытаемся рассмотреть такой интересный и полезный элемент ИТ-инфрастуктуры, как си��тема мониторинга VoIP-трафика.
Развитие современных телекоммуникационных сетей поражает: от сигнальных костров они шагнули далеко вперёд, и то, что казалось немыслимым ранее, сейчас является простым и обыденным. И только профессионалы знают, что скрывается за повседневностью и широким использованием достижений отрасли информационных технологий. Разнообразие сред передачи, способов коммутации, протоколов взаимодействия устройств и алгоритмов кодирования поражает сознание обывателя и может стать настоящим кошмаром для любого, кто связан с их исправным и стабильным функционированием: прохождение тональных сигналов или голосового трафика, невозможность регистрации на softswitch, тестирование нового оборудования, составление обращения в support вендора.
Упомянутое выше понятие протокола – это краеугольный камень любой сети связи, от которого будет зависеть её архитектура, состав и сложность составляющих её устройств, перечень предоставляемых ею услуг и многое другое. При этом, очевидной, но очень важной является закономерность, заключающаяся в том, что использование более гибкого протокола сигнализации улучшает масштабируемость сети связи, что влечёт за собой достаточно быстрое увеличение в ней различных сетевых устройств.
При этом даже необходимое и оправданное наращивание числа взаимосвязанных сетевых элементов в рамках отмеченной закономерности влечёт за собой ряд сложностей, связанных с сопровождением сети и её эксплуатацией. Многие специалисты сталкивались с ситуацией, когда снятый дамп не позволяет однозначно локализовать возникшую проблему, т.к. был получен на том участке сети, который не причастен к её появлению.
Такая ситуация особенно характерна для VoIP-сетей, которые включают в себя количество устройств большее, чем одна PBX и несколько IP-телефонов. Например, когда в решении используются несколько пограничных контроллеров сессий, гибких коммутаторов или softswitch один, но функция определения местоположения пользователя отделена от прочих и вынесена на отдельное устройство. Тогда инженеру приходится выбирать для анализа следующий участок, руководствуясь своим эмпирическим опытом или волей случая.
Такой подход крайне утомителен и не продуктивен, так как вынуждает из раза в раз тратить время на борьбу с одними и теми же вопросами: что получится использовать для сбора пакетов, как забрать результат и так далее. С одной стороны, как известно, человек привыкает ко всему. К этому также можно привыкнуть, «набить руку» и натренировать терпение. Однако с другой стороны всё равно присутствует ещё одна сложность, с которой нельзя не считаться – корреляция трассировок, взятых с разных участков. Все вышеперечисленные, а также многие другие задачи анализа сетей связи составляет предмет деятельности многих специалистов, помочь решить которые призваны системы мониторинга трафика.
А вместе — делаем общее дело: ты по-своему, а я по-своему.
Ю. Деточкин
Современные сети передачи медиатрафика проектируются и строятся посредством реализации различных концепций, фундамент которых составляет множество телекоммуникационных протоколов: CAS, SS7, INAP, H.323, SIP и т.д. Система мониторинга трафика (СМТ) – это средство, которое призвано производить захват сообщений, перечисленных выше (и не только) протоколов, и обладает набором удобных, интуитивно понятных и информативных интерфейсов для его анализа. Основное назначение СМТ – сделать сигнальные трассировки и дампы за любой промежуток времени доступными для специалистов в любое время (в том числе в режиме реального времени) без использования специализированных программ (например, Wireshark). С другой стороны, каждый квалифицированный специалист обращает пристальное внимание на вопросы, связанные, например, с безопасностью ИТ-инфраструктуры.
При этом немаловажным аспектом, напрямую связанным с данным вопросом, является возможность данного специалиста «держать руку на пульсе», что может быть достигнуто в том числе с помощью своевременного оповещения о том или ином инциденте. Коль скоро упомянуто о вопросах оповещения, то мы говорим о мониторинге сети связи. Возвращаясь к приведённому выше определению, СМТ позволяет выполнять контроль тех сообщений, ответов и активностей, которые могут свидетельствовать о каком-либо аномальном поведении сети (например, ответы 403 или 408 группы 4хх в SIP или резкое увеличение числа сессий на транке), при этом получить соответствующую инфографику, которая наглядно иллюстрирует происходящее.
Однако следует отметить, что система мониторинга трафика VoIP изначально не является т��й классической Fault Monitoring System, которая позволяет составлять карты сетей, контролировать доступность их элементов, утилизацию ресурсов, периферию и многое другое (например, как Zabbix).
Разобравшись с тем, что представляет собой система мониторинга трафика, и задачах, которые она решает, перейдём к вопросу о том, как же её применить с пользой для дела.
Очевидным является тот факт, что сама по себе СМТ не способна собрать Call Flow «по щучьему велению». Для этого необходимо свести соответствующий трафик со всех используемых устройств в одну точку – Capture Server. Таким образом, написанное определяет характерную особенность системы, которая выражается в необходимости обеспечения централизации места сбора сигнального трафика и позволяет ответить на поставленный выше вопрос: что даёт использование комплекса на эксплуатируемой или внедряемой сети.
Итак, как правило, редко инженер может, что называется, с ходу ответить на вопрос — в каком конкретном месте будет или может находится указанная точка централизации трафика. Для более-менее однозначного ответа специалистам необходимо провести ряд изысканий, связанных с предметным анализом VoIP-сети. Например, повторное уточнение состава оборудования, детальное определение точек его включения, а также возможностей в контексте отправки соответствующего трафика в точку сбора. Кроме того, ясно, что успешность решения рассматриваемого вопроса напрямую зависит от способа организации транспортной IP-сети.
Следовательно, первое, что даёт внедрение СМТ – это та самая, когда-то запланированная, но так и не выполненная ревизия сети. Конечно, вдумчивый читатель сразу задаст вопрос – а при чём тут СМТ? Прямой связи здесь нет и быть не может, но … Психология большинства людей, в том числе и тех, кто связан с миром ИТ, обычно склонна приурочивать такого рода мероприятия к какому-либо событию. Следующий плюс вытекает из предыдущего и заключается в том, что ещё до того, как будет развёрнута СМТ, установлены и настроены Capture Agents, включена отправка RTCP сообщений, вполне могут быть обнаружены какие-либо проблемы, требующие оперативного вмешательства. Например, где-то образовалось «бутылочное горлышко» и это явно видно и без статистики, которую в том числе может предоставлять СМТ, используя данные, предоставляемые, например, RTCP.
Теперь вернёмся к описанному ранее процессу сбора так необходимых нам трассировок и улыбнёмся, вспомнив слова героя, вынесенные в эпиграф данной части. Важной его особенностью, которая не была указана, является то, что, как правило, перечисленные манипуляции может производить персонал достаточной квалификации, например, Core Engineers. С другой стороны, в круг вопросов, решаемых с помощью трассировок, могут входить и так называемые рутинные задачи. Например, определение причины, по которой не регистрируется терминал у инсталлятора или клиента. При этом, становится очевидным, что наличие исключительной возможности снятия дампов у отмеченных специалистов накладывает на них необходимость выполнения данных производственных задач. Это не продуктивно по причине того, что отнимает время от решения других более важных вопросов.
При этом в большинстве компаний, где желательно использование такого продукта, как СМТ, имеется специальное подразделение, в список задач которого как раз и входит выполнение рутинных операций, с целью разгрузки других специалистов – service desk, helpdesk или техническая поддержка. Также я не сделаю для читателя открытие, если отмечу, что доступ инженеров службы технической поддержки из соображений безопасности и стабильности сети к наиболее критичным узлам нежелателен (хотя вполне возможно, что он и не возбраняется), а ведь именно указанные сетевые элементы содержат наиболее выгодный ракурс с точки зрения дампов. СМТ, ввиду того, что является центральным местом сбора трафика и обладает интуитивным и прозрачным интерфейсом, вполне способен решить ряд обозначенных проблем. Единственное условие – организация доступа к интерфейсу с рабочих мест специалистов технической поддержки и, возможно, написание knowledge base статьи по её использованию.
В заключение отметим наиболее известные и интересные продукты, так или иначе выполняющие рассмотренный выше функционал, среди которых: Voipmonitor, HOMER SIP Capture, Oracle Communications Monitor, СПАЙДЕР. Несмотря на имеющийся общий подход к организации и развёртыванию, каждая имеет свои нюансы, субъективные положительные и отрицательные стороны и все заслуживают их отдельного рассмотрения. Что и станет предметом дальнейших материалов. Спасибо за Ваше внимание!
UPD (23.05.2019): к приведённому в заключении списку, стоит добавить ещё один продукт, о котором автору стало известно относительно недавно. SIP3 – молодой, развивающийся представитель из мира систем мониторинга SIP-трафика.
Развитие современных телекоммуникационных сетей поражает: от сигнальных костров они шагнули далеко вперёд, и то, что казалось немыслимым ранее, сейчас является простым и обыденным. И только профессионалы знают, что скрывается за повседневностью и широким использованием достижений отрасли информационных технологий. Разнообразие сред передачи, способов коммутации, протоколов взаимодействия устройств и алгоритмов кодирования поражает сознание обывателя и может стать настоящим кошмаром для любого, кто связан с их исправным и стабильным функционированием: прохождение тональных сигналов или голосового трафика, невозможность регистрации на softswitch, тестирование нового оборудования, составление обращения в support вендора.
Упомянутое выше понятие протокола – это краеугольный камень любой сети связи, от которого будет зависеть её архитектура, состав и сложность составляющих её устройств, перечень предоставляемых ею услуг и многое другое. При этом, очевидной, но очень важной является закономерность, заключающаяся в том, что использование более гибкого протокола сигнализации улучшает масштабируемость сети связи, что влечёт за собой достаточно быстрое увеличение в ней различных сетевых устройств.
При этом даже необходимое и оправданное наращивание числа взаимосвязанных сетевых элементов в рамках отмеченной закономерности влечёт за собой ряд сложностей, связанных с сопровождением сети и её эксплуатацией. Многие специалисты сталкивались с ситуацией, когда снятый дамп не позволяет однозначно локализовать возникшую проблему, т.к. был получен на том участке сети, который не причастен к её появлению.
Такая ситуация особенно характерна для VoIP-сетей, которые включают в себя количество устройств большее, чем одна PBX и несколько IP-телефонов. Например, когда в решении используются несколько пограничных контроллеров сессий, гибких коммутаторов или softswitch один, но функция определения местоположения пользователя отделена от прочих и вынесена на отдельное устройство. Тогда инженеру приходится выбирать для анализа следующий участок, руководствуясь своим эмпирическим опытом или волей случая.
Такой подход крайне утомителен и не продуктивен, так как вынуждает из раза в раз тратить время на борьбу с одними и теми же вопросами: что получится использовать для сбора пакетов, как забрать результат и так далее. С одной стороны, как известно, человек привыкает ко всему. К этому также можно привыкнуть, «набить руку» и натренировать терпение. Однако с другой стороны всё равно присутствует ещё одна сложность, с которой нельзя не считаться – корреляция трассировок, взятых с разных участков. Все вышеперечисленные, а также многие другие задачи анализа сетей связи составляет предмет деятельности многих специалистов, помочь решить которые призваны системы мониторинга трафика.
О системах мониторинга трафика сетей связи
А вместе — делаем общее дело: ты по-своему, а я по-своему.
Ю. Деточкин
Современные сети передачи медиатрафика проектируются и строятся посредством реализации различных концепций, фундамент которых составляет множество телекоммуникационных протоколов: CAS, SS7, INAP, H.323, SIP и т.д. Система мониторинга трафика (СМТ) – это средство, которое призвано производить захват сообщений, перечисленных выше (и не только) протоколов, и обладает набором удобных, интуитивно понятных и информативных интерфейсов для его анализа. Основное назначение СМТ – сделать сигнальные трассировки и дампы за любой промежуток времени доступными для специалистов в любое время (в том числе в режиме реального времени) без использования специализированных программ (например, Wireshark). С другой стороны, каждый квалифицированный специалист обращает пристальное внимание на вопросы, связанные, например, с безопасностью ИТ-инфраструктуры.
При этом немаловажным аспектом, напрямую связанным с данным вопросом, является возможность данного специалиста «держать руку на пульсе», что может быть достигнуто в том числе с помощью своевременного оповещения о том или ином инциденте. Коль скоро упомянуто о вопросах оповещения, то мы говорим о мониторинге сети связи. Возвращаясь к приведённому выше определению, СМТ позволяет выполнять контроль тех сообщений, ответов и активностей, которые могут свидетельствовать о каком-либо аномальном поведении сети (например, ответы 403 или 408 группы 4хх в SIP или резкое увеличение числа сессий на транке), при этом получить соответствующую инфографику, которая наглядно иллюстрирует происходящее.
Однако следует отметить, что система мониторинга трафика VoIP изначально не является т��й классической Fault Monitoring System, которая позволяет составлять карты сетей, контролировать доступность их элементов, утилизацию ресурсов, периферию и многое другое (например, как Zabbix).
Разобравшись с тем, что представляет собой система мониторинга трафика, и задачах, которые она решает, перейдём к вопросу о том, как же её применить с пользой для дела.
Очевидным является тот факт, что сама по себе СМТ не способна собрать Call Flow «по щучьему велению». Для этого необходимо свести соответствующий трафик со всех используемых устройств в одну точку – Capture Server. Таким образом, написанное определяет характерную особенность системы, которая выражается в необходимости обеспечения централизации места сбора сигнального трафика и позволяет ответить на поставленный выше вопрос: что даёт использование комплекса на эксплуатируемой или внедряемой сети.
Итак, как правило, редко инженер может, что называется, с ходу ответить на вопрос — в каком конкретном месте будет или может находится указанная точка централизации трафика. Для более-менее однозначного ответа специалистам необходимо провести ряд изысканий, связанных с предметным анализом VoIP-сети. Например, повторное уточнение состава оборудования, детальное определение точек его включения, а также возможностей в контексте отправки соответствующего трафика в точку сбора. Кроме того, ясно, что успешность решения рассматриваемого вопроса напрямую зависит от способа организации транспортной IP-сети.
Следовательно, первое, что даёт внедрение СМТ – это та самая, когда-то запланированная, но так и не выполненная ревизия сети. Конечно, вдумчивый читатель сразу задаст вопрос – а при чём тут СМТ? Прямой связи здесь нет и быть не может, но … Психология большинства людей, в том числе и тех, кто связан с миром ИТ, обычно склонна приурочивать такого рода мероприятия к какому-либо событию. Следующий плюс вытекает из предыдущего и заключается в том, что ещё до того, как будет развёрнута СМТ, установлены и настроены Capture Agents, включена отправка RTCP сообщений, вполне могут быть обнаружены какие-либо проблемы, требующие оперативного вмешательства. Например, где-то образовалось «бутылочное горлышко» и это явно видно и без статистики, которую в том числе может предоставлять СМТ, используя данные, предоставляемые, например, RTCP.
Теперь вернёмся к описанному ранее процессу сбора так необходимых нам трассировок и улыбнёмся, вспомнив слова героя, вынесенные в эпиграф данной части. Важной его особенностью, которая не была указана, является то, что, как правило, перечисленные манипуляции может производить персонал достаточной квалификации, например, Core Engineers. С другой стороны, в круг вопросов, решаемых с помощью трассировок, могут входить и так называемые рутинные задачи. Например, определение причины, по которой не регистрируется терминал у инсталлятора или клиента. При этом, становится очевидным, что наличие исключительной возможности снятия дампов у отмеченных специалистов накладывает на них необходимость выполнения данных производственных задач. Это не продуктивно по причине того, что отнимает время от решения других более важных вопросов.
При этом в большинстве компаний, где желательно использование такого продукта, как СМТ, имеется специальное подразделение, в список задач которого как раз и входит выполнение рутинных операций, с целью разгрузки других специалистов – service desk, helpdesk или техническая поддержка. Также я не сделаю для читателя открытие, если отмечу, что доступ инженеров службы технической поддержки из соображений безопасности и стабильности сети к наиболее критичным узлам нежелателен (хотя вполне возможно, что он и не возбраняется), а ведь именно указанные сетевые элементы содержат наиболее выгодный ракурс с точки зрения дампов. СМТ, ввиду того, что является центральным местом сбора трафика и обладает интуитивным и прозрачным интерфейсом, вполне способен решить ряд обозначенных проблем. Единственное условие – организация доступа к интерфейсу с рабочих мест специалистов технической поддержки и, возможно, написание knowledge base статьи по её использованию.
В заключение отметим наиболее известные и интересные продукты, так или иначе выполняющие рассмотренный выше функционал, среди которых: Voipmonitor, HOMER SIP Capture, Oracle Communications Monitor, СПАЙДЕР. Несмотря на имеющийся общий подход к организации и развёртыванию, каждая имеет свои нюансы, субъективные положительные и отрицательные стороны и все заслуживают их отдельного рассмотрения. Что и станет предметом дальнейших материалов. Спасибо за Ваше внимание!
UPD (23.05.2019): к приведённому в заключении списку, стоит добавить ещё один продукт, о котором автору стало известно относительно недавно. SIP3 – молодой, развивающийся представитель из мира систем мониторинга SIP-трафика.
