ПоделитьсяВведение
Любая сложная информационная система нуждается в постоянном мониторинге — без него она превращается в «черный ящик», где любые неполадки становятся неожиданностью и серьезной угрозой для бизнеса.
При отсутствии мониторинга резко возрастает риск длительных простоев критически важных сервисов. Без системы отслеживания состояния инфраструктуры невозможно вовремя заметить предвестников сбоев, будь то рост нагрузки, утечки памяти или задержки в ответах. Не имея доступа к историческим данным и логам, невозможно восстановить хронологию инцидентов и понять их истинную причину, а значит и предотвратить повторение ситуации.
Отсутствие непрерывного контроля за производительностью ведет к неоптимальному использованию ресурсов: компания либо переплачивает за избыточные мощности, либо сталкивается с «узкими местами», тормозящими работу всей системы. При этом прогнозировать будущую нагрузку и обоснованно планировать масштабирование становится практически невозможно.
Без постоянного контроля доступности и стабильности сервисов отсутствует возможность оперативно реагировать на возникающие проблемы.
Пренебрежение мониторингом оборачивается значительными финансовыми и репутационными потерями, тогда как его внедрение становится важной инвестицией в устойчивость и безопасность ИТ‑инфраструктуры.
Ниже рассмотрены возможности мониторинга систем телефонии компании Eltex.
Peeper
Общая информация
Peeper — система мониторинга программных продуктов Eltex.
Архитектура Peeper состоит из двух частей:
- Клиентская — устанавливается на одном сервере с продуктом, например ECCM, Softswitch или SoftWLC. В ее задачи входит сбор метрик и их отправка на серверную часть.
- Серверная — в ее задачи входит агрегация и хранение метрик и логов, визуализация данных в виде графиков, отправка уведомлений об авариях и оповещений безопасности в Telegram.
Все ПО предоставляются в виде Docker-образов, размещенных в публичных репозиториях, и файлов compose.yml и .env для разворачивания контейнеров.
Для чего необходим Peeper
- Предотвращать появление чрезвычайной ситуации на серверах и приложениях клиента заранее.
- В случае ЧС иметь возможность разрешить инцидент (иметь всю необходимую информацию в одном месте для того, чтобы завершить расследование).
- Иметь возможность оперативно оценить внутреннее состояние системы по ее внешним показателям.
Функции и свойства Peeper
Peeper прост в развертывании и эксплуатации, что важно для системы мониторинга.
Peeper позволяет:
- собирать и хранить метрики и логи;
- визуализировать данные в виде дашбордов, графиков, диаграмм, таблиц;
- высылать уведомления в случае срабатывания триггера по какой-либо метрике.
Архитектура Peeper
В архитектуре Peeper предусмотрено, что для получения метрик со стороны Peeper Client не требуется открывать никаких дополнительных портов на стороне сервера с программным продуктом Eltex. Отправка метрик с этого сервера производится методом Push.
Все входящие запросы в Peeper Server идут по HTTPs через Peeper Proxy по 443 порту.
Peeper построен на базе свободного ПО Grafana и Telegraf. Основную ценность Pepper составляют специально разработанные для ПО Eltex сборщики метрик и информационные панели (дашборды).
Интерфейс пользователя
Интерфейс пользователя Pepper построен на базе общеизвестной системы анализа и отображения данных Grafana, которая позволяет визуализировать данные различными способами.
Информационные панели
Peeper поставляется в комплекте с информационными панелями для наблюдения за операционными системами, на которые устанавливается ПО Eltex и с информационными панелями непосредственно для ПО, такого как ECCM, SoftWLC и SoftSwitch.
Общесистемные дашборды включают, но не ограничиваются:
- дашборды Docker;
- дашборд ОС Linux;
- дашборд безопасности.
Информационные панели SoftSwitch
Дашборды Softwich распределены по трем разделам:
- Основные метрики — раздел мониторинга непосредственно Softswitch;
- Системные метрики — раздел мониторинга свойств окружения, непосредственно связанных с Softswich;
- Дополнительные отладочные метрики — раздел мониторинга взаимодействия компонентов Softswich. Используется при глубоком траблшутинге. Понимание метрик раздела требует понимания внутреннего устройства Softswich и далее в статье рассмотрено не будет.
Ниже описаны подробнее два первых раздела.
Основные метрики
Раздел «Основные метрики» объединяет следующие информационные панели:
- Метрики MSR;
- Метрики SIP;
- Метрики колл-центра;
- Общие метрики SSW;
- Общие метрики вызовов.
Рисунок 1. Метрики MSR
На информационной панели «Метрики MSR» представлены метрики работы Медиасерверов. Загрузка центральных процессоров, количество аудио и видео потоков, MOS оценка качества входящего и исходящего аудиопотоков, данные о джиттере, задержке и потере пакетов.
Рисунок 2. Метрики SIP
На информационной панели «Метрики SIP» представлена статистика работы Softswitch по протоколу SIP. Общее количество SIP-запросов, интенсивность запросов по типам (INVITE, REGISTER, BYE и т. д.), интенсивность новых вызовов, динамика изменения интенсивностей.
Рисунок 3. Метрики колл-центра
На информационной панели «Метрики колл-центра» представлена информация о количестве активных вызовов в разрезе очередей, заполненность очередей ожидающими клиентами, информация о количестве и причинах отбоев по очередям, нагрузка и изменение интенсивности нагрузки на колл-центр.
Рисунок 4. Общие метрики вызовов
На информационной панели «Общие метрики вызовов» отображаются количество активных вызовов, количество отбоев вызовов с разбивкой по причинам, графики количества вызовов по часам и за последний час.
Рисунок 5. Общие метрики SSW
На информационной панели «Общие метрики SSW» собраны основные параметры из остальных разделов, и добавлены такие параметры, как информация о времени затраченном на сбор метрик по типам.
Системные метрики
Раздел «Системные метрики» объединяет следующие дашборды:
- Мониторинг Glusterfs;
- Мониторинг Glusterfs split-brain тома ecss_volume;
- Мониторинг сети между хостами.
Рисунок 6. Мониторинг Glusterfs
На информационной панели «Мониторинг Glusterfs» представлены параметры работы Gluserfs, используемой в Softswitch GlusterFS для раздела /var/lib/ecss/restfs, где находится распределенная БД для хранения медиаресурсов, а именно: Время работы компонентов Glusterfs, заполненность хранилища, общие параметры (количество томов, количество бриков, количество реплик).
Рисунок 7а. Мониторинг Glusterfs split-brain тома ecss_volume. Нормальная работа
Рисунок 7б. Мониторинг Glusterfs split-brain тома ecss_volume. Нарушена синхронизация
Информационная панель «Мониторинг Glusterfs split-brain тома ecss_volume» отображает состояние синхронизации файлов в разделе Glusterfs. В случае нарушения синхронизации отображается количество несинхронизированных файлов.
Рисунок 8. Мониторинг сети между хостами
Информационная панель «Мониторинг сети между хостами» отображает состояние состояние сети внутри кластера Softswitch, потери пакетов, сетевую задержку и джиттер.
Общие информационные панели
При мониторинге подсистем IP-телефонии не следует забывать о мониторинге ресурсов инфраструктуры. Потребление оперативной памяти, загрузка процессора, свободное место на жестких дисках, общая загруженность системы — все эти параметры отображены в дашборде «Linux System Dashboard» раздела «General Dashboards — общие дашборды».
Рисунок 9. Мониторинг операционной системы
Также не стоит забывать о мониторинге самой системы мониторинга. Закончившееся место на хранилище данных или повышенная загрузка операционной системы системы мониторинга могут помешать отследить критическое отклонение параметров или отправить вовремя уведомление администратору. По умолчанию Peeper мониторит сам себя. Собранные данные можно увидеть на тех же дашбордах, что и данные об операционных системах Softswitch.
Рисунок 10. Выбор наблюдаемого устройства
Отказ каналов связи или резкий отказ аппаратного обеспечения системы мониторинга не позволит оповестить администратора о произошедшем. Поэтому разумно также производить хотя бы минимальный мониторинг самого Peeper через внешнюю систему. Это может быть как второй Peeper, так и другая система мониторинга, установленная на другой площадке или имеющая другие каналы выхода в сеть Интернет.
Оповещения
Конечно, информационные панели системы мониторинга можно вывести на отдельный монитор или телевизор и выделить отдельного сотрудника для слежения за параметрами, но информационных панелей много, на каждой панели отображается множество параметров, и отследить отклонение от нормальных значений очень не просто. Для решения этой задачи в Peeper предусмотрена и частично преднастроена система оповещений (Alerting). Для получения оповещений необходимо указать API Token бота и Chat ID получателя оповещений.
Тем не менее стоит периодически просматривать информационные панели. Некоторые тенденции к отклонениям значительно проще определить визуально.
Документация
Документацию по установке и настройке Peeper можно найти в разделе с документацией.
VoIP Monitor
При эксплуатации систем IP-телефонии бывает необходимо провести анализ протоколов сигнализации и оценить качество медиа трафика. В реальном времени часть этих задач можно решить инструментами общего назначения, такими как tcpdump и Wireshark, или специализированными инструментами, например утилита sngrep. Однако зачастую необходимо проанализировать не только то, что происходит сейчас, но и оценить ситуацию в ретроспективе. Для таких случаев рекомендуем использовать систему мониторинга качества VoIP-вызовов VoIP Monitor.
Функции системы
VoIP Monitor производит мониторинг активных вызовов в реальном времени и сохраняет все параметры завершенных вызовов для последующего анализа.
Вся работа с системой осуществляется через удобный web-интерфейс.
История вызовов доступна с детализацией по абонентам, времени и показателям качества. Для всех вызовов рассчитывается MOS по стандарту ITU-T G.107, измеряются количество потерянных пакетов, круговая задержка и вариация круговой задержки (джиттер).
Гибкий фильтр позволяет отобразить только интересующие вызовы.
Для всех завершенных вызовов имеется возможность:
- экспорта pcap-файла, для детального анализа с использованием привычных инструментов;
- визуализация последовательности сигнального обмена, в том числе в виде лестничной диаграммы.
Для отобранных по фильтру или выбранных вручную вызовов доступен экспорт CDR в формате единого CSV-файла.
Имеется возможность настроить оповещения по порогам MOS, джиттера, потерь пакетов, и по кодам SIP-ответов.
Архитектура
VoIP Monitor состоит из двух основных компонентов:
- Сенсор — точка сбора трафика.
- UI — компонент отвечающий за взаимодействие с пользователем. Предоставляет web-интерфейс для системы.
Сенсоры подразделяются на два типа:
- Основной (Master)
- Вспомогательный (Slave)
Все сенсоры могут собирать и хранить трафик. С основным (Master) сенсором взаимодействует UI, предоставляя информацию пользователю через web-интрефейс.
Вспомогательные сенсоры (Slave) подключаются к основному (Master) по протоколу TCP. Передают собранную информацию о вызовах в агрегированном виде.
Slave-сенсоры могут быть установлены на одном хосте с ECSS-10 SoftSwitch, но они требуют дополнительной процессорной мощности и дополнительной оперативной памяти для временного хранения и обработки вызовов. Требуется примерно 10% дополнительных ядер CPU (не менее одного), и около 10-20% дополнительной оперативной памяти. Кроме того, при локальном хранении PCAP-файлов требуется место на доступных серверу накопителях.
Система поставляется в Docker-контейнерах, с разделением на микросервисы.
Сенсоры для сбора трафика прослушивают сетевые интерфейсы операционной системы, на которую они установлены. При установке сенсора совместно с ECSS-10 Softswitch на одном физическом или виртуальном сервере сбор трафика происходит непосредственно с интерфейсов этого сервера. При раздельной установке необходимо организовать зеркалирование трафика с интерфейсов IP АТС на интерфейс сенсора. При такой схеме VoIP Monitor может собирать и анализировать трафик телефонии не только с ECSS-10 Softswich, но и с любой другой IP АТС, работающей по протоколу SIP. Например с аппаратных IP АТС серии SMG.
Возможные варианты реализации
Возможные варианты размещения компонентов приведены в документации. Основные рекомендации в зависимости от нагрузки приведены ниже.
При нагрузках до 200 одновременных вызовов рекомендуется устанавливать Slave-сенсоры непосредственно на ноды ECSS-10 SoftSwitch, с отключением локального хранения PCAP-файлов.
При нагрузках до 2000 одновременных вызовов допускается устанавливать Slave-сенсоры непосредственно на ноды ECSS-10 SoftSwitch, с отключением локального хранения PCAP-файлов при наличии достаточных серверных ресурсов и сложности реализации зеркалирования трафика. Рекомендуется вынесение Slave-сенсоров на внешние сервера.
При нагрузках 10000 одновременных вызовов и более для работы Slave-сенсоров необходимы отдельные физические серверы с высокопроизводительной оперативной памятью. Рекомендуется использовать все доступные центральному процессору каналы памяти. На Master-сенсоре для локального хранения PCAP-файлов рекомендуются быстрые SSD-накопители.
Master-сенсор ни в каком сценарии использования не рекомендуется размещать совместно с нодами ECSS-10 Softswitch. В общем случае Master-сенсор не должен непосредственно собирать трафик, а только получать информацию от Slave-сенсоров. Сбор трафика на Master-сенсоре допускается только в случае малых нагрузок, порядка 50 одновременных вызовов.
Master-сенсор требует высокопроизводительной системы хранения для базы данных. На небольших количествах одновременных вызовов допускается использование SATA SSD для раздела с базой данных. При нагрузках от 10000 одновременных вызовов необходим массив из NVMe SSD-дисков.
Компонент UI в большинстве сценариев может быть размещен вместе с Master-сенсором. Вынесение UI на отдельный хост необходимо только при больших нагрузках. Например при постоянной работе с системой нескольких операторов.
Зеркалирование трафика рекомендуется проводить на коммутационном оборудовании. Зеркалирование посредством iptables в продуктовых реализациях производить не рекомендуется из-за дополнительной нагрузки на систему и сетевые интерфейсы сервера IP АТС.
Интерфейс пользователя
Интерфейс пользователя доступен через Web. Содержит разделы:
- Завершенные вызовы
- Текущие вызовы
- Оповещения
- Настройки
Рисунок 11. Пример страницы «Завершенные вызовы» VoIP Monitor.
SNMP (Zabbix)
SNMP (Simple Network Management Protocol) — стандартный протокол управления и мониторинга различного оборудования, используемый во множестве систем мониторинга для сбора данных с устройств. Одной из популярных систем мониторинга, использующих SNMP, является Zabbix. В этом разделе рассмотрим возможности мониторинга устройств и программного обеспечения производства Eltex по протоколу SNMP.
ECSS-10 Softswitch
В ECSS-10 Softswitch возможности применения SNMP реализованы в ограниченном объеме. Доступны только метрики текущего количества активных вызовов в целом на системе и в разрезе по доменам (виртуальным АТС). Кроме предоставления метрик, ECSS-10 Softswitch может отправлять уведомления о событиях посредством SNMP Trap и SNMP Inform. SNMP Trap могут быть приняты и обработаны средствами Zabbix. В целом мониторинг ECSS-10 Softswitch целесообразней осуществлять с помощью системы Peeper, описанной выше.
Транковые шлюзы SMG
Транковые шлюзы SMG-2 и SMG-4, IP-АТС SMG-200 и SMG-500, транковые шлюзы и IP-АТС на базе гибридных платформ SMG-3016 и SMG-3116 поддерживают предоставление обширного диапазона метрик через SNMP.
Cписок основных типов метрик
Для шлюзов:
- физическое состояние потоков E1;
- ошибки логического состояния потоков;
- счетчики (принятых, переданных, коротких и длинных пакетов, ошибок CRC);
- состояния каналов потоков E1.
Для IP АТС:
- текущее число активных вызовов и регистраций;
- статистика RADIUS-запросов;
- информация о транковых группах;
- информация об абонентах;
- для SMG-200 также доступен мониторинг FXO/FXS-портов.
Для всех устройств:
SMG поддерживает следующие ветки MIB-2:
- system (1.3.6.1.2.1.1) — общая информация о системе;
- interfaces (1.3.6.1.2.1.2) — информация о сетевых интерфейсах;
- snmp (1.3.6.1.2.1.11) — информация о работе SNMP.
Кроме того, доступны метрики через ветку enterprise:
- состояние и загруженность SIP-интерфейсов;
- имя и тип устройства;
- версия ПО;
- IP-адрес основного интерфейса;
- свободное место на накопителях;
- свободная оперативная память;
- температурные датчики;
- состояние и занятость VoIP-субмодулей;
и дополнительно для устройств в стоечном исполнении:
- загрузка CPU;
- скорости вентиляторов;
- информация о сетевых интерфейсах и сетевых протоколах.
Полный список метрик с OID и описанием представлен в приложениях «Управление и мониторинг по протоколу SNMP» документации на каждое устройство.
Получение метрик
Для получения значений метрик по протоколу SNMP устройства необходимо настроить. Настройка описана в подразделе «Настройки SNMP» раздела «Сетевые сервисы» документации. Обязательным для чтения по протоколу SNMPv2 является только "ro Community". Там же можно указать имя и расположение устройства, контактную информацию. Если предполагается управлять устройством по протоколу SNMPv2, необходимо указать "rw Community". Для мониторинга и управления по протоколу SNMPv3 необходимо указать "RW user name" и "RW user password".
После настройки получить значения можно любым стандартным способом, например с помощью утилит snmpwalk, snmpget или через системы мониторинга, например Zabbix.
Пример запроса одной и той же ветки с применением MIB-файлов и без приведен в блоке ниже:
$ snmpwalk -m +ELTEX-SMG -c public -v 2c 10.192.1.16 smgMonitoring ELTEX-SMG::smgTemperature1.0 = STRING: 35.675 degrees Celsius ELTEX-SMG::smgTemperature2.0 = STRING: 37.982 degrees Celsius ELTEX-SMG::smgFan0.0 = INTEGER: 4500 rpm ELTEX-SMG::smgFan1.0 = INTEGER: 4500 rpm ELTEX-SMG::smgFan2.0 = INTEGER: 4560 rpm ELTEX-SMG::smgFan3.0 = INTEGER: 4560 rpm $ snmpwalk -On -c public -v 2c 10.192.1.16 .1.3.6.1.4.1.35265.1.29.35 .1.3.6.1.4.1.35265.1.29.35.1.0 = STRING: "35.675" .1.3.6.1.4.1.35265.1.29.35.2.0 = STRING: "37.982" .1.3.6.1.4.1.35265.1.29.35.3.0 = INTEGER: 4500 .1.3.6.1.4.1.35265.1.29.35.4.0 = INTEGER: 4500 .1.3.6.1.4.1.35265.1.29.35.5.0 = INTEGER: 4560 .1.3.6.1.4.1.35265.1.29.35.6.0 = INTEGER: 4500
Эти же метрики могут быть сохранены в Zabbix, и отображены в ретроспективе за желаемый период. Пример приведен на Рисунке 12.
Рисунок 12. Пример отображения исторических значений метрик в интерфейсе Zabbix.
SMG и Zabbix
Для хранения и отображения метрик c SMG в Zabbix можно воспользоваться имеющимся шаблоном, при необходимости доработав его или создав собственный.
Все устройства серии SMG в той или иной мере поддерживают управление через SNMP, но такой функционал выходит за рамки данной статьи.
Абонентские шлюзы TAU
Настольные шлюзы
На шлюзах TAU-1M.IP, TAU-2M.IP, TAU-4M.IP и TAU-8N.IP для мониторинга по SNMP доступны основные параметры системы и параметры интерфейсов Ethernet (состояние, скорость, количество принятых и переданных пакетов и т.д.). Для настройки и просмотра доступны настройки SIP-профилей, FXS-портов, групп вызова, системного журнала; коды активации ДВО с телефонного аппарата.
По умолчанию SNMP на устройствах отключен. Для включения достаточно установить флаг "Enable SNMP" ("Включить SNMP") на странице "Network"/"SNMP" ("Сеть"/"SNMP")
По умолчанию параметры roCommunity и rwCommunity установлены в значения public и private соответственно. Эти значения общеизвестны. Для обеспечения безопасности устройства рекомендуется поменять их на собственные уникальные.
Стоечные шлюзы
На шлюзах TAU-16.IP, TAU-24.IP, TAU-36.IP, TAU-72.IP и модульном шлюзе TAU-32.IP для мониторинга доступны основные параметры системы и параметры интерфейсов Ethernet, общие параметры системы (свободное дисковое пространство, свободная оперативная память, использование ресурсов процессора и т.д.), параметры датчиков температуры, вентиляторов, блоков питания. По части телефонии доступен мониторинг состояния FXS-портов, состояние SIP-регистрации, состояние вызовов и состояние групп вызова.
Также имеется возможность настройки и просмотра параметров портов, абонентских профилей, параметров SIP, настроек журналирования, кодеков, и т.д.
Для критически важных параметров, таких как отклонение напряжений питания, повышения температуры, отказа системы охлаждения предусмотрена отправка SNMP Trap и SNMP Info.
Подробно настройка и параметры SNMP описаны в руководстве по эксплуатации в разделе «Подменю настройки протокола «SNMP»»
ECCM
ECCM — система, предназначенная для инвентаризации, управления и мониторинга сетевого оборудования Eltex.
Применительно к VoIP-оборудованию, ECCM логично использовать больше как инвентаризационную систему и для мониторинга доступности VoIP-оборудования. Многие параметры мониторинга телефонии в ECCM пока не поддерживаются.
Рисунок 13. Главный экран устройства SMG-3016 в ECCM
На Рисунке 13 показан главный экран для устройства SMG-3016. На экране отображается информация о модели, серийном номере, MAC и IP-адресах, версии ПО. Также на экране имеется информация об утилизации CPU и RAM.
В подразделе "Метрики" раздела "Мониторинг" имеется возможность просмотреть изменение метрик в динамике.
Рисунок 14. График загрузки CPU
В подразделах "SNMP trap" и "Syslog" можно просмотреть сообщения от устройства с возможностью фильтрации.
Рисунок 15. Экран системного журнала.
Кроме функций мониторинга, ECCM предоставляет некоторые функции управления. Например, позволяет обновить программное обеспечение устройства или предоставить доступ к SSH-консоли.
Заключение
Построение грамотного мониторинга системы IP-телефонии позволит сократить время реагирования на инциденты, а во многих случаях и предотвратить их. Не стоит пренебрегать такой возможностью. Надеемся инструменты, описанные в данной статье, помогут вам в этом.
