Тема: Прошу помощи с шаблоном разбора логов
Долго мучались, не понимая почему в отчетах некорректные цифры, пока не сели пристально изучать шаблоны разбора логов по умолчанию.
В итоге пришли вот к какой ситуации.
1. Комендант поставили с нуля (предварительно удалили раннюю установку, почистили папки, включая mySQLбазу)
2. в свежеустановленном Коменданте настроили связь с миниАТС (Panasonic TDA-600)
3. поправили шаблон разбора логов, в соответствии с тем, что выдает наша АТС.
В результате отчет не показывает исходящие звонки, и не показывает корректно входящие.
для упрощения анализа отправил письмо с архивом:
- текстовый лог полученный из АТС (2.log)
- сохраненный шаблон разбора логов из конфигуратора (шаблон.ats)
- свежий архив базы (komendant(1)_20120517_193022.sqlz)
- скриншот того, что выдает отчет по всем звонкам без каких либо фильтров
буду благодарен за помощь\
И еще момент такой. у меня в логе время звонка отображается с разделителем апострофом, (например 00:00’14 ), а в редактировании шаблона логов нет такого формата для времени вызова, там только двоеточия-разделители. Может это как-то влияет тоже?
Отправили Вам на почту приблизительный шаблон разбора логов от АТС.
Сравните его со своим и сделайте соответствующие выводы о допущенных ошибках.
время звонка отображается с разделителем апострофом
Не влияет - время разбирается правильно.
Отправили Вам на почту приблизительный шаблон разбора логов от АТС.
Сравните его со своим и сделайте соответствующие выводы о допущенных ошибках.
Внимательно перелопатили ваш и наш шаблоны - в упор не видим различий, кроме на первый взгляд незначительных, например
В правиле для исходящих звонков отличаются ровно две вещи:
- стартовая позиция поиска “внутреннего номера” (у нас 19 у вас 20)(но у вас число знаков 3 а у нас 4, и у нас этот номер все равно влезал)
- число знаков набранного номера (у нас 25 у вас 30) по идее тоже не влияет особо
Плюс порядок проверки правил разный, у вас сначала входящие, потом внутренние, потом исходящие, у нас - исходящие - первым правилом.
Аналогично для других правил: где то дополнительное условие задано (без него по идее тоже должно же отбирать, Вообще правило БЕЗ доп условий наоборот более общее, более непривиредливое, м?), где то мизерные различия в длине параметра и т.д.
Если взять за основу правило для исходящих звонков - что из описанных различий в вашем и нашем шаблонах сказалось таким образом, что по нашему шаблону исходящие звонки не разбирались, не были видны в отчете?
Может есть еще какие-то различия которые я не вижу, или не понимаю куда смотреть?
“Дьявол кроется в деталях” ©
“Дьявол кроется в деталях” ©
Был бы очень признателен, если бы ткнули носом в конкретную ошибку.
А еще лучше объяснили-бы принцип. (Например: “Шаблон не работает, т.к. у вас смешения при поиске поля ААА неправильное и при разборе строки это поле начинается с пробела. Парсер считает это ошибкой и не учитывает в разборе. А вообще критично важные поля ААА, БББ, ССС - остальное может быть с ошибками - парсер пропустит.”)
Если это не входит в рамки поддержки бесплатной версии - что ж, okay. :(
Цитирую мануал:
Настройки правила разбора лога.
Внимание! Важен порядок следования правил разбора лога. Строка лога от АТС обрабатывается правилами последовательно. Если строка лога удовлетворяет условиям правила, то обработка строки лога прекращается (даже если есть нижележащие правила) и строка лога считается обработанной.
Для правила можно установить условие, по которому правило будет определять обрабатывать строку лога или не обрабатывать. Дополнительно к основному условию можно использовать дополнительное условие.
* Основное условие.
* Дополнительное условие.
Примечание.
Параметр черного цвета - не участвует в правиле разбора строки лога.
Параметр синего цвета - участвует в правиле разбора строки лога.
У каждого параметра указывается два значения:
* установка позиции в строке
* длина параметра в символах
Цитирую мануал:
Наверное разобрался.
Очередность правил важна. Наше правило для исходящих было слишком всеобъемлющим (без условий)и будучи первым по списку подхватывало в себя вообще все звонки.
Попутно вылез еще один странноватый момент. некоторые входящие звонки АТС не помечает в конце кодом D0 или TR. т.е. просто строка с номерами и т.д. без кода в конце.
Соответственно в текущем шаблоне эти звонки попадали в “исходящие”.
Я добавил два дополнительных правила (без доп. условий по кодам в конце, но с определением входящего типа по <I> - и вроде бы все заработало.
Спасибо за помощь.
Звонки без пометки CD(код состояния) - прямые звонки.
А CD может принимать следующие значения:
CL: вызов с начислением оплаты на вызываемого абонента;
TR: переадресация;
FW: постоянная переадресация вызовов во внешнюю линию;
D0: вызов с использованием DISA или услуг соединительных линий;
RM: удаленное техническое обслуживание (через модем);
NA: ответ на вызов не получен;
RC: полученный вызов;
AN: отвеченный вызов;
VR: полученный вызов с АОН для ожидающих вызовов с сигнализацией типа FSK (Отображение идентификатора вызывающего абонента);
VA: отвеченный вызов с АОН для ожидающих вызовов с сигнализацией типа FSK (Отображение идентификатора вызывающего абонента);
Звонки без пометки CD(код состояния) - прямые звонки.
Немного странно.
Вот пример строк из лога. Первая строка - тот самый звонок без пометки CD, вторая строка - с пометкой.
22/05/12 12:43 558 05 <D>5340<I>4956200819 0’00 00:00’26
22/05/12 12:43 118 03 <D>5340<I>4955155442 0’00 00:01’48 TR
Оба звонка пришли по одному и тому же входящему потоку (разные линии, но это ведь не должно влиять)
Но у одного есть код состояния, а у другого - нету.
По нашей конфигурации мини-АТС ВСЕ звонки приходящие по этому потоку попадают на DISA, т.е. автоматически должны иметь либо пометку D0 либо TR(если звонящий знает внутренний номер и сам его набрал).
Или я ошибаюсь?
Нужно смотреть сколько каналов у Дисы и как распределяются звонки при ее занятости.
Нужно смотреть сколько каналов у Дисы и как распределяются звонки при ее занятости.
Я это проверял.
У DISA 8 каналов (2 платы MSG4), при занятости всех каналов DISA звонок переводится на AA-0, т.е. в нашем случае на группу секретарей ресепшна (вн. номер 601).
В строке лога, которую я приводил есть внутренний номер 558 - он НЕ принадлежит группе секретарей ресепшна.
На всякий случай: я понимаю, что вопрос не к вам. И не требую ответа. 😊
Просто думал может при вашем опыте разбирательств с логами миниАТС вы навскидку что-то посоветуете.
Если нет - то нет .
Спасибо еще раз за помощь с шаблоном разбора.
Посмотрите в МС 10,3 - может этот номер входящий по DDI/DID запрограммирован на 558 валиться.
Посмотрите в МС 10,3 - может этот номер входящий по DDI/DID запрограммирован на 558 валиться.
точно нет.
Мало того лог, который я приводил, это ведь только кусочек - для примера.
В реальном логе такие записи (без кодов состояния) есть не только для номера 558, но и для некоторой выборки других номеров.
Связать эти номера каким-то единым общим признаком (общая группа, общий COS и т.д.) у меня пока не получилось.
Я не скажу что это проблема (в конце концов дополнительными правилами разбора все прекрасно парсится), но интересна суть: почему в этих строках код состояний не пишется.
