2. Средства мониторинга и диагностики проблем и аварий оставляют желать много-много лучшего. Основное средство диагностики до сих пор отладочные логи, понятные только самим разработчикам системы, нигде, разумеется, не документированные. Плюс "снимите дамп трафика", куда ж без этого. Для проекта open source это было бы нормально, для весьма недешевого коммерческого решения - нет.
Простой пример - для мониторинга загрузки потоков E1 в ITG есть программный SNMP-модуль. snmpwalk-ом обойти MIB невозможно (либо Error: OID not increasing, либо вечный цикл с возвратом одного и того же OID в зависимости от флагов snmpwalk). Плюс он отдаёт информацию только о потоках с сигнализацией ОКС7, но не о потоках PRI. Пришлось рисовать shell-крипт, который запускается из cron раз в 5 минут, вызывает CLI, кормит его командами, парсит его вывод, выкусывает нужные цифры, сохраняет их в файлы и выходит. После запуска скрипта в работу ITG стал иногда аварийно перезагружаться целиком, пришлось отключить задачу в cron и остаться без графиков загрузки потока на офисную АТС.
Другой пример: при возникновении линейных проблем с подключением к PSTN оказалось, что средства диагностики аварий на потоке со стороны ITG тоже оставляют желать лучшего. Как и средства устранения сбоев - вплоть до того, что пришлось перезагружать ITG полностью, тогда поток снова заработал. К счастью, проблема больше не возникает.
Проблемы с диагностикой касаются всех компонентов комплекса.
