Парсим логи DIRECTUM

Введение

В этой статье хотелось бы немного затронуть тему автоматизации анализа логов DIRECTUM.

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

Если открыть стандартный лог-файл, то можно увидеть что-то подобное:

Поиск по такому файлу проводить весьма неудобно и ненаглядно. Кроме того, сам файл лога может значительно увеличиться в объеме, до десятков и сотен мегабайт, что так же делает его более трудоемким для анализа. А если таких файлов десятки или даже сотни?

В этом случае помочь может парсинг.

Что же такое парсинг?

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

Настроить его можно следующим образом:

Необходимо скачать архив http://club.directum.ru/file/logparser.zip. Архив состоит из 3 частей: бэкапа базы, утилиты logparser и ini-файл с настройками для утилиты.

1. Итак, развертываем на SQL сервере бэкап базы, куда далее будем собирать всю информацию из лог-файлов DIRECTUM.
2. Корректируем файл настроек. Файл настроек имеет следующий вид:

В блоке [COMMON] задаем следующие настройки:

LogMask – путь, где расположены лог-файлы DIRECTUM, а также маску необходимых, для анализа файлов;

ReportDirectory – путь куда будем складываться отчеты в формате .xls;

ExcludedUsers – пользователи, чьи логи необходимо исключить из анализа;

SubjectPrefix – префикс именования файлов отчетов в .xls;

Version – версия платформы системы DIRECTUM.

В блоке [DBCONNECTPARAMS] указываем параметры подключения к БД парсинга:

Server – сервер, где развернут бэкап базы для парсинга;

DataBase – имя БД;

WindowsAuthentication – признак использования/не использования Win-аутентификации (0 – не используется);

User и Password заполняются в случае, если Win-аутентификация не используется.

            Блок [SYSTEMCODE] содержит код системы DIRECTUM в формате ИмяSQLСервера_ИмяБазы.

3. Создаем Job на SQL-сервере, который будет автоматически ежедневно анализировать логи, например, за предыдущий день. Для уменьшения влияния на работу SQL сервера Job лучше настроить на запуск в ночное время. Как вариант, можно настроить запуск через Планировщик заданий Windows.

Ключи утилиты LogParser можно посмотреть, запустив соответствующую утилиту:

*При использовании соответствующего ключа утилиты logparser.exe данные будут сохраняться в БД.

В качестве результата в папке с отчетами ежедневно будут создаваться 4 файла следующего вида:

1. Prefixcritic_11.02.2013_18.02.2013_0.xls – критичные ошибки;

Примером критичных ошибок будет например, печально известные ошибки вида «Access violation», «Application crashed» и т.д.

2. Prefixnocritic_11.02.2013_18.02.2013_0.xls – некритичные ошибки;

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

3. Prefixuncalstk_11.02.2013_18.02.2013_0.xls – ошибки с неизвестным стеком исключения (как правило нужны для анализа разработчикам);
4. Prefixunexccls_11.02.2013_18.02.2013_0.xls – ошибки с неизвестным классом исключения (как правило нужны для анализа разработчикам).

Сами файлы будут иметь следующий вид:

Таким образом на выходе получаем файл с логами DIRECTUM, который можно фильтровать и сортировать.

Что касается интерпретации самих событий, то это тема отдельной статьи.

Итак, данная утилита позволяет:

1. Анализировать, вместо нескольких десятков и сотен файлов с логами системы DIRECTUM, несколько структурированных табличных файлов;
2. Файлы могут быть сформированы за любой период и для любой системы DIRECTUM(например, если у вас в организации несколько баз);
3. Вести историю логов системы в БД, тем самым имея возможность использовать всю мощь и средства СУБД для выборки, анализа и построения необходимых отчетов по событиям системы DIRECTUM.

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