Статьи

Ведение журнала на основе сеансов

Апрель 17, 2018

Для устранения неполадок программного обеспечения, регистрация какого-либо рода имеет важное значение. Но для большинства систем просто невозможно регистрировать все, что происходит. Многие системы и каркасы журналирования позволяют вам ограничивать объем данных, задавая уровень журналирования (например, ошибка, предупреждение, информация, отладка) и указав, где в коде должна выполняться регистрация. Альтернативным способом ограничения данных является использование ведения журнала на основе сеанса. Затем вы получаете все данные, относящиеся к определенному сеансу, но ничего для любого другого сеанса.

ПРИМЕР

Например, в  Symsoft  мы производим системы для операторов мобильной связи для обработки вызовов и текстовых сообщений (SMS). Типичный сеанс в нашем случае — это телефонный звонок или отправка SMS. При ведении журнала на основе сеанса одна запись журнала содержит все, что происходит во время сеанса. Он содержит исходное сообщение, которое запускает обработку в системе, все операторы журнала, относящиеся к внутренней логике, и все внешние сигналы (и ответы), которые являются частью обработки. Вот  пример журнала  отправки SMS. Это выписка:

-- 6, smrouter: MsRouter: Analyse SMS control for service
      key 1565 (Collected Info (orig))
-- 7, smrouter: MsRouter: Invoking SMS control function
      SM Quota Control
-- 7, smquotacontrol: Process message
-- 8, smquotacontrol: Unconfigured service key 1565
-- 8, smrouter: MsRouter: SMS Control Continue
-- 8, smrouter: MsRouter: Analyse destination 46704123456
     [Numbering plan, MSISDN] [Type of number, INTERNATIONAL],
     RI=0

Цифры слева — это миллисекунды с начала сеанса. В приведенном выше фрагменте мы видим, что был задействован программный модуль smquotacontrol, и что служебный ключ 1565 не был настроен. Мы также можем видеть, что номер телефона получателя 46704123456. В  полном журнале  этой отправки SMS мы можем, например, увидеть полное содержимое всех сообщений SS7, отправленных и полученных во время доставки, текст SMS, что доставка была успешно, и что весь процесс занял 128 миллисекунд.

В начале сеанса выполняется проверка того, следует ли вести журнал (например, на основе номера телефона абонента, идентификатора пользователя или аналогичного). Операторы регистрации выглядят как обычные операторы регистрации:


1

2

3
if
(context.isTraceActive()) {
context.printTrace(
"MSISDN is missing or empty."
);
}

Нет уровня ведения журнала — ведение журнала всегда выполняется на самом детальном уровне. В конце сеанса выводится полный журнал сеанса.

ПРЕИМУЩЕСТВА

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

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

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

РАЗНООБРАЗНЫЙ

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

В нашей системе на работе у нас есть полезный вариант ведения журнала сессий, который называется Trace On Error . При активации, если генерируется исключение (например, NullPointerException), выводится полная трассировка сеанса до этой точки, в дополнение к трассировке стека. Он работает, запуская ведение журнала сеанса для каждого сеанса, но выводя результат только в случае возникновения исключения. Если нет, вся собранная информация о сеансе (в основном набор строк) отбрасывается. Это оказывает некоторое давление на кучу и сборщик мусора, но не слишком много. Мы использовали этот механизм в реальной системе несколько раз, чтобы получить больше информации о трудно решаемых ошибках.

Я должен также упомянуть, что помимо ведения журнала на основе сеансов у нас также есть традиционное ведение журнала на основе операторов. Этот тип регистрации используется для таких событий, как изменения конфигурации, периодические выходы и т. Д.

Используется ли в вашей системе протоколирование на основе сеанса или отдельные операторы журналирования (с использованием каркаса журналирования или на заказ) или что-то еще? Дай мне знать в комментариях.

35
Share: