4.5.Как включить технологический журнал «1С» и как его можно разбирать

Технологический журнал позволяет получать технологическую информацию о работе приложений, как сервера, так и клиентов. Например, позволяет посчитать количество ошибок блокировок.

Чтобы его включить, нужно выполнить следующие действия:

1. Завести на локальных дисках серверов приложений «1С» специальную папку для технологического журнала. Например, как показано на рис. 4.5.1, <C:\LOG>. И для дампов, например <C:\dumps>.

Рис. 4.5.1. Содержимое папки C:\LOG после создания

• Настроить журнал, чтобы сбор сообщений об ошибках (см. ниже пункт 10 про файл logcfg.xml) происходил в подкаталог этого каталога. Подкаталог будем называть по дате: <C:\LOG\2011-02-16> и т. д.
• Сам файл logcfg.xml надо положить в каталог conf папки установки сервера «1С:Предприятия» (например, как показано на рис. 4.5.2, в C:\Program Files\1cv82\8.2.15.301\bin\conf).

Рис. 4.5.2. Файл logcfg.xml помещен в нужный каталог

• Обратить внимание, что файл нужно помещать в каталог установки сервера, а не клиента, т. к. в зависимости от разрядности ОС это может быть либо один и тот же каталог, либо разные. То есть, например, если у вас 64-битный сервер, то сервер «1C» по умолчанию ставится в C:\Program Files\(...), а клиент в C:\Program Files (x86)\(...).
• После этого примерно через минуту убедиться, что в каталоге <C:\LOG> создалась папка C:\LOG\2011-02-16, и в ней еще подпапки с именами rphost_XXXX, ragent_XXXX, rphost_XXXX, а в них файлы. Пример с правильными папками показан на рисунке 4.5.3. Если же создаются только подпапки с именами 1с8_ХХХХ, это означает, что файл logcfg.xml поместили в конфигурационный каталог клиента, а не сервера.

Рис. 4.5.3. Папки, автоматически сформированные после старта записи технологического журнала

• Если папки, показанные на рисунке выше, создались, то все нормально, если не создались, то что-то не так.
• Если что-то не так, то наиболее распространенные ошибки:

- большие/маленькие буквы в именах каталогов (регистр должен совпадать);

- в файле настройки (logcfg.xml) написали слеш на конце имени каталога (не нужен);

- требуется донастроить права пользователей на папки C:\LOG, C:\dumps, C:\Program Files\1cv82\8.2.13.205\bin\conf, если их не хватает, а такое может быть по умолчанию. По этой же причине лучше создавать каталог хранения логов не на диске (C:).

• Если надо хранить данные за каждый день отдельно, каждый день в одно и то же время (например, в начале рабочего дня) нужно менять имя каталога в файле logcfg на новое (подставлять другую дату). Данные за прошлый день архивировать в один файл с соответствующим именем, при необходимости высылать туда, где их могут обработать. После этого данные за прошлый день удалять.
• Если не надо хранить данные за каждый день отдельно, можно ничего не делать, данные хранятся определенное количество часов (в нашей настройке, указанной ниже, – 240, после чего сами удаляются).

На настройку, если с правами все в порядке, понадобится минут пять вместе со следующим пунктом.

1. Настройка logcfg.xml.

Файл logcfg.xml сам по себе является семафором. Его присутствие в нужном каталоге включает запись технологического журнала «1С», а его содержимое определяет, что, как и куда пишется. Запись журнала начинается примерно через минуту после помещения корректного файла в нужный каталог. Перезапускать сервер не требуется.

Редактировать файл можно «Блокнотом».

Содержимое файла для наших целей должно быть примерно таким:

В этом случае в технологический журнал пишутся только ошибки:

Данные хранятся 240 часов, потом удаляются:

Они пишутся в каталог C:\LOG\2011-02-16:

Дампы при падении создаются:

Такая настройка наиболее подходит для ежедневного мониторинга. Она делает возможным ручной визуальный контроль ошибок (сам технологический журнал – это текстовые файлы). Она не вызывает дополнительной нагрузки на систему, поскольку в файл пишутся только ошибки (повышение нагрузки на систему не фиксируется, оно на уровне ошибок измерения). Также такая настройка не забивает место на диске при создании дампов. При указании type="0" дамп занимает очень мало места на диске.

Дампы нужны, если вы собираетесь их посылать на разбор или умеете обрабатывать сами. Можно совсем не записывать дампы, если вам не нужно их считать:

Для целей мониторинга ошибок указанной настройки вполне достаточно. Обработкой НастройкаТехнологическогоЖурнала.epf с ИТС можно настроить более продвинутый мониторинг, однако каждое новое событие нужно включать, только если вы четко понимаете, что вы хотите с его помощью увидеть. Может произойти такое, что избыточная информация сделает недоступным визуальный ручной контроль или ее вывод потребует от системы значительных ресурсов.

Если происходит ошибка блокировок, она записывается в файл в текстовом виде, и выглядит она примерно так, как показано на рис. 4.5.4:

Рис. 4.5.4. Пример информации об ошибках блокировок в технологическом журнале

Квалифицированный программист «1С» обычно в состоянии достаточно быстро написать парсер, считающий, например, количество появлений строк «Lock request time out» в нескольких текстовых файлах.

Другие ошибки блокировок, с которыми приходится встречаться на практике, представлены в таблице 3.9.1.

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

• если их меньше 10 в день, можно на них пока не обращать внимания;
• если в какой-то день больше 10, стоит начать заниматься этой проблемой;
• если их больше 50 в день, проблемой надо заниматься в полную силу;
• если их больше 200 в день, ваши пользователи вам и так все уже рассказали.

Отправить