XIMA Chronicall экстренный траблшутинг телефонной системы мониторинга и построения отчетов

Приветствую Вас, читатели и писатели Хабрахабр!

Я в данный момент учусь, параллельно подрабатывая системным администратором, в интересном стартапе – MyMoneyPark. Естественно, что на первых порах данная работа включает в себя все, что только можно, в том числе «эникейство», но это опыт, который студенту вряд ли повредит.

Одной из областей, которой я «правлю», является телефония. Для нас стабильность работы телефонной системы очень критична, особенно в виду того, что проект был запущен немногим более трех месяцев назад. Кроме того, чтобы иметь представление о количестве звонков и необходимых «мощностях» для их обработки, чтобы не потерять ни единого звонившего клиента или же иметь возможность составлять расписания для каждого работника, нам очень пригодилась система мониторинга и построения отчетов от XIMA. А о своем траблшутинге, который мне пришлось провести, работая с данной системой я и расскажу под катом.

О системе

«Chronicall» – разработка XIMA, позволяющая хранить историю звонков, строить отчеты, просматривать подробную информацию о каждом совершенном звонке. Содержит ряд дополнений, которые нас, как потребителя, в данный момент не интересуют. Как и любой софт «Chronicall» имеет ряд ошибок и недоработок, незаметных на первый взгляд, но, тем не менее, иногда губительно сказывающихся на построении таких важных для нас отчетов.

Казалось, простейшая ситуация, глава линии обслуживания клиентов (ЛОК), получает «базовый» доступ к утилите, работающей посредством Java в виде апплета. Первое, что он сделает – ознакомится с продуктом, причем, весьма успешно – после первого же перезапуска, система откажется запуститься.

С чего все началось

Утром после необходимых обновлений, которым понадобилась перезагрузка, я получил письмо от главы ЛОК о том, что система «Chronicall» отказывается запускаться, а именно ее часть со списком доступных отчетов, жалуясь на отсутствие соединения с сервером. Сообщение незамысловатое, выглядело просто — «It appears that you have lost your connection to the Chronicall Server. Please make sure you are connected to the network».

Первые шаги

Не найдя ответов в Google и не получив от XIMA-FAQ ответов на поставленные вопросы, я начал собственный глубокий траблшутинг. Весьма легко было предположить, что все запросы Java-апплета обслуживаются HTTP сервером. Кстати, в Chronicall HTTP-сервером является tomcat. Поэтому прямой запрос к URL со списком доступных отчетов показал банальную ошибку сервера – 503. Возможно, кто-то поступил бы иначе, сразу начав изучать логи сервера, но видя ошибку соединения, невольно задумываешься о проблемах в сети. Поэтому именно мысль о проверке доступности сервера клиенту пришла в мою голову первой.

Продолжая поиск, вторым этапом я обратился к логам HTTP-сервера, где и нашлась ошибка. Для меня является немного странным то обстоятельство, что по первому взгляду на ошибку, которую выдает Java-апплет, трудно предположить что же реально ее вызывает.

Сама ошибка меня не смутила, имея опыт в отладке Java приложений, я мог бы попытаться отыскать вручную, что же стало мешать запуску чудо-утилиты. Но, к сожалению, не прислушиваясь к разуму, я начал с перезапусков сервиса, переустановок JVM, очистки КЭШ и поиска «подводных камней» в виде несовместимости с различными версиями Java-машины, в общем все, что предлагал XIMA-FAQ, сайт производителя и тематические форумы. Так ничего и не помогло. Последним делом я естественно отправил отчет об ошибке разработчикам с подробным описанием проблемы. Поверил слогану баг-репорта о скорости их работы, думал, ответят действительно быстро, но прогадал, ответ пришел через несколько недель, о чем расскажу позже.

Разумная мысль

Мое «легкое» исследование показало, что нерабочим остается только редактор отчетов, который содержит дерево выбора состоящее из доступных отчетов, расформированных по типам в папках. При всем при этом, данные в базу писались, отчеты по расписанию работали замечательно. Работало все, за исключением редактора (тех самых отчетов). К счастью, на данном этапе исследования я и вспомнил о том, что же «натворил» изменил наш глава линии обслуживания клиентов:

Тогда-то и удалось приблизиться к решению сей проблемы. На рисунке выше изображено дерево отчетов, с новой папкой «New Folder», в самом низу. Эту папку создал глава ЛОК, исследуя платформу. Причем, как видно, создать ее можно, а вот удалить — функционал, который мы имеем, не позволяет. Так же сей функционал не позволяет использовать эту папку по ее прямому назначению — чтобы группировать отчеты.

Теперь становится понятно, что функция «ensureUniqueFolderIDs» из логов, по всей видимости, и отвечает частично за загрузку списка с рисунка выше. Осталось найти откуда загружаются данные для дерева выбора и попытаться устранить ошибку.

Устранение

Используемая схема базы данных не имеет ни намека на список возможных отчетов. Поэтому, пройдясь по папкам файловой системы, набрел на одну с названием «reports». В ней имеется множество файлов без расширений, несколько шаблонов (как видно из названия) и еще ряд файлов JASPER, видимо для опенсорсного JasperReports. Но файл с названием «model» меня привлек больше всего. В нем, среди бинарного «мусора», я и нашел имена своих папок и имена, включенных в папки отчетов.

Удаление данного файла помогло подтвердить мое предположение — именно из него программа загружает дерево. Проблему это поправило — новый файл был автоматически создан после перезапуска, но, к сожалению, он оказался пуст, как и дерево отчетов. Все дело в том, что файл «model» содержит, по всей видимости, сериализованные данные дерева, что не давало мне возможности «легким движением руки» выскрести из него ненавистную «New Folder». Перебирать побайтово пришлось бы долго, рабочий день близился к концу, а оставлять все на следующий, было бы не разумно. Единственное, что могло бы ускорить процесс, был файл установщика. Правда, меня несколько пугала полная переустановка. Поэтому, разобрав его на файлы, первым делом я заменил файл «model». Эта процедура не только вернула все на свои места, но и добавила новых, бесполезных в нашем случае, отчетов.

Выводы

С одной стороны понятно стремление разработчиков как можно больше ограничить клиента, не купившего «продвинутую» лицензию. А с другой, простейшая мелочь, которую без правки файлов и длительных поисков хоть каких-то зацепок, устранить не удается, но которая приводит к полной недееспособности системы, и более того вводит в заблуждение «неправдоподобным» сообщением об ошибке. Мелочь, которая может остановить работу на несколько часов, если разбираться самому и вас постигнет удача или на несколько недель, если воспользоваться баг-репортом.

Огромную долю юмора сей истории добавляют разработчики, соизволившие ответить на баг-репорт, как уже отмечалось, через несколько недель. Восхищаясь проделанной работой, они предложили нашей фирме занять место их бета-тестера за простенькие плюшки. Но за нехваткой времени использовать данную возможность у нас не вышло и они нам более не писали.

Почему же появление данной папки так обескуражило программу для меня остается загадкой до сих пор, внятного ответа мне разработчики дать не удосужились, но проблему, надеюсь, решили. Посему я очень надеюсь, что никому больше не придется сталкиваться с подобным явлением.

P.S.

Если же я изначально пошел по неверному пути, приму любую критику. Если существуют более простые способы решения этой проблемы, мне бы очень хотелось об этом узнать.
Не судите сильно строго за первую статью у вас.

Автор: Dexterite

Источник