Сложное телекоммуникационное оборудование всегда требует хорошего администрирования и быстрого решения проблем.
Проблем может быть большое разнообразие и не всегда можно понять, с чем именно сталкивается инженер.
Сетевая ли это проблема, или проблема телефонии, проблема нашего оборудования или встречной стороны.
Возникает ли проблема всегда или периодически. А может быть человеческий фактор или что то еще.
В связи с этим, снятия и анализы логов неизбежны. Но все зависит от того, какие именно проблемы нужно отлавливать/анализировать/дебажить.
Решение любой проблемы всегда начинается с ее локализации, разбиение на части: причина → следствие.
С точки зрения прохождения вызова через SMG это входящее плечо или исходящее плечо.
Сначала нужно удостовериться, что вызов точно приходит, что приходит корректный, т.е. анализировать входящее направление.
Затем нужно смотреть прохождение вызова через SMG, его маршрутизацию, преобразование, т.е. анализировать логи PBX_PSTN.
Третьим этапом будет проверка исходящего направления. Если вызов отправляется от SMG, то какой ответ приходит от встречной стороны и т.д.
С точки зрения работы системы SMG, причиной проблем может быть определенный процесс.
По типу процесса можно понять какого вида трафик вызвал зависание или загрузку CPU, например SIP, SNMP, WEB и т.д.
После чего уже можно анализировать конфигурации и фильтровать нужный трафик до повторения проблемы.
В этой статье речь пойдет о том, какую именно информацию нужно анализировать в каких ситуациях.
Бывают ситуации:
1. Не проходит вызов или вызов проходит, но проблемы со слышимостью, или задержки и т.п.:
1) Конфигурация SMG (Сервис->Управление файлами конфигурации->Скачать);
2) TCP дамп неудачного звонка с интерфейса any, bond1 в случае smg2016 (Раздел РСАР трассировки);
3) Лог PBX_PSTN неудачного звонка все уровни 1 (Раздел PBX трассировки).
4) Номера А и В.
2. Периодически не проходит вызов или вызов проходит, но периодически проблемы со слышимостью, или задержки и т.п.:
1) Конфигурация SMG (Сервис->Управление файлами конфигурации->Скачать);
2) В этом случае необходима запись логов/дампа на постоянной основе до следующего повторения проблемы.
Дамп нужно писать зеркалированием трафика, подробнее тут
Снятие трассировок на SMG
Логи нужно отправлять на syslog сервер, все уровни 1, раздел трассировок syslog.
3) Номера А и В.
3. Падения ПО, перезагрузки:
1) Конфигурация SMG (Сервис->Управление файлами конфигурации->Скачать);
2) Выгрузку команд:
show system info
sh
dmesg
ls -l /tmp/logs
По этим данным можно понять характер проблемы и какие логи создались в системе при падении, чтобы их скачать.
Чтобы логи сохранялись после перезагрузки SMG, нужно настроить запись и хранение трассировок на внешнем накопителе.
4. Периодическая загрузка CPU:
В этом случае нужно поднять ssh/telnet сессию до SMG и настроить запись консоли в файл. Затем дать команды:
sh
top
и оставить до возникновения загрузки. По загрузкам top можно будет понять какой процесс загружает CPU в момент проблемы и какие логи могут потребоваться для дальнейшей локализации.
5. Проблемы с потоком E1:
Если возникают проблемы с сигнализацией Q.931 или SS7 и прохождением звонков, то можно начать с анализа PCM дампа (Раздел РСАР трассировки).
Если проблема носит другой характер, например поток не поднимается совсем или поднимается и падает, то нужно снимать
логи потока в tracemode. Подробнее про это написано в статье:
Снятие логов потока E1 на SMG.