1с сервер логи ошибок

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

Содержание

1. Общая информация
2. Включение технологического журнала
3. Создание файла настроек
4. <dump>
5. <log>
6. <event>
7. <property>

Общая информация

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

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

Технологический журнал может продуцировать два вида информации:

• Логи — файлы с расширением *.log, в которых в текстовом виде храниться информация о произошедших событиях;
• Дампы — файлы с расширением *.mdmp, в которых хранится содержимое оперативной памяти рабочего процесса на момент его «падения». Самостоятельный анализ дампа невозможен, так как исходный код платформы закрыт. Единственный способ проанализировать дамп — отправить  его в тех. поддержку или на партнерский форум.

Включение технологического журнала

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

%LOCALAPPDATA%1C1cv8dumps (пример: C:UsersUSR1CV8AppDataLocal1C1cv8dumps)

а логи здесь:

%LOCALAPPDATA%1C1cv8logs (пример: C:UsersUSR1CV8AppDataLocal1C1cv8logs)

USR1CV8 — имя пользователя под которым работает сервер 1С. Логи хранятся 24 часа, при этом делятся на файлы — каждый час новый файл.

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

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

Выбор директории зависит от задачи: если нужно настроить тех. журнал для всех версий 1С, то файл настроек нужно разместить здесь:

C:Program Files1cv8conf

Если настроить нужно конкретную версию, то здесь (зависит от версии):

C:Program Files1cv88.3.13.1513binconf

Иногда может потребовать включить тех. журнал для конкретного пользователя, из под которого запущен сервер 1С, в этом случае файл настроек следует разместить тут:

C:UsersUSR1CV8AppDataLocal1C1cv8conf

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

Создание файла настроек

Теперь перейдем к содержимому файла настроек logcfg.xml.

Вначале приведем пример файла настроек:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<dump>

Этот элемент отвечает за формирование дампов памяти. Атрибуты:

location — каталог в который будут сохраняться дампы, значение этого атрибута должно отличаться от значений такого же атрибута у других элементов (<log> и <defaultlog>).

create — записывать (1) или не записывать (0) дампы.

type — тип дампа, любая комбинация (сумма) из перечисленных ниже флажков:

• 0 — минимальный;
• 1 — дополнительный сегмент данных;
• 2 — содержимое всей памяти процесса;
• 4 — данные хэндлов;
• 8 — оставить в дампе только информацию, необходимую для восстановления стеков вызовов;
• 16 — если стек содержит ссылки на память модулей, то добавить флажок флаг 64;
• 32 — включить в дамп память из-под выгруженных модулей;
• 64 — включить в дамп память, на которую есть ссылки;
• 128 — добавить в дамп подробную информацию о файлах модулей;
• 256 — добавить в дамп локальные данные потоков;
• 512 — включение в дамп памяти из всего доступного виртуального адресного пространства.

Компания «1С» советует использовать значение 3 (1+2), так как в большинстве случаев этого достаточно.

<log>

Этот элемент определяет каталог тех. журнала и события которые в него попадают. Таких элементов может быть несколько т.е. сервер 1С может вести сразу несколько тех. журналов с различными настройками. Тем не менее компания «1С» не рекомендует вести более 20 тех. журналов одновременно, так как это может замедлить работу системы. Может содержать внутри себя элементы <event> и <property>. Атрибуты:

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

history — время жизни логов, в часах.

<event>

Определяет условия, при выполнении которых событие попадает в журнал. Само условие задается следующими элементами:

• eq — равно;
• ne — не равно;
• gt — больше;
• ge — больше или равно;
• lt — меньше;
• le — меньше или равно;
• like — соответствие маске.

<property>

Определяет условия попадания в журнал значения свойства события.

Элемент <property name=»all»> </property> включает записи в журнал всех свойств событий.

В статье упоминаются далеко не все элементы конфигурационного файла, а те, что все-таки упоминаются, рассмотрены поверхностно. Самое полное описание всех элементов конфигурационного файла, с примерами, советами и пояснениями имеется на сайте ИТС (ссылка), а также в руководстве администратора.

Руководство администратора (желтая, не очень толстая книжечка) можно легко найти в электронном виде, да и бумажном оно встречается достаточно часто, так как входит во многие поставки продуктов компании 1С.

На этом все, надеюсь эта статья была Вам полезна.

Если Вы нашли ошибку или неточность, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Загрузка…

Коллеги, продолжаем серию статей, посвященных технологическому журналу.

Сегодня мы покажем практику анализа логов ТЖ.

Другие статьи из серии «Технологический журнал»:

«ТЖ: Настройка»

«ТЖ: События и фильтры»

«ТЖ: Описание и включение»

Анализ логов технологического журнала

Давайте посмотрим что произойдет, если мы создадим файл logcfg.xmlс указанной выше структурой и поместим его в каталог «C:Program Files1Cv82conf»

Подождем 60 секунд и откроем каталог «C:1C_InfoLogs», т.к. именно его мы указывали в 3 строке файла logcfg.

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

В результате в каталоге мы видим 3 подкаталога.

Каждый процесс кластера создал каталог, в котором находятся логи только данного процесса, а т.к. у меня только 3 процесса, то и каталогов тоже 3.

Каталог создается по шаблону ИмяПроцесса_PIDПроцесса. PID нужен для того, чтобы отличать процессы с одинаковым именем.

Каждый час создается отдельный файл с логом.

Файл лога именуется по шаблону ГГММДДЧЧ.log.

Например, у меня первый лог за 6 апреля 2015 года 10 часов утра.

Если лог старше чем количество часов указанное в параметре history файла logcfg, то он автоматически удаляется платформой.

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

Событие записываются в лог только после того, как оно завершилось, т.к. необходимо фиксировать длительность события.

Строка лога имеет формат:

 мм:сс.тттт-д, <ИмяСобытия>, <Уровень>, <Свойства>

Где:

мм – номер минуты в текущем часе.

сс – номер секунды в текущей̆ минуте.

тттт – номер десятитысячной доли текущей̆ секунды, для 8.3 здесь отображается номер миллионной доли.

д – длительность события в десятитысячных долях секунды, для 8.3 в миллионных долях.

<ИмяСобытия> – наименование события.

<Уровень> – уровень события в стеке текущего потока.

<Свойства> — свойства события разделенные запятыми, значения свойств проставлены через знак «=».

Разберем на примере.

Есть лог со следующим содержимым:

00:16 — это минуты и секунды окончания события. 
    Дату и час события можно взять из названия файла лога. 
    Событие завершилось 6 апреля 2015 года в 11 часов 00 минут 16 секунд.

8640 – для 8.2 это десятитысячные доли секунды.
    А для 8.3 — миллионные доли секунды момента завершения события.

1 – это длительность события. 
    В 8.2 длительность указывается в десятитысячных долях секунды,
    в 8.3 в миллионных долях секунды.
    Если необходимо поставить фильтр на длительность, то можно 
    использовать имя свойства «Duration».

DBMSSQL – это имя события.
    В данном случае выполнение инструкций СУБД MS SQL Server.

3 – уровень события.
    Далее идут свойства события DBMSSQL,при этом у каждого события свой
    набор свойств.Полный список свойств для всех событий можно посмотреть
    в руководстве администратора. Здесь мы подробно рассмотрим свойства 
    только для текущего события.

Process – Описывает процесс для которого пишется данный лог. Это свойство
    есть у всех событий. В моем случае пишется лог процесса rphost.

P:processName – имя информационной базы 1С.
    Событие было сформировано в базе под названием Deadlock.

T:clientID — идентификатор соединения с клиентом по TCP.

T:applicationName – идентификатор клиентской программы.
    Т.е. кто именно вызвал событие, в моем случае это фоновое задание.

T:connectID – номер соединения с информационной базой.

SessionID – номер сеанса, назначенный текущему потоку. 
    Если текущему потоку не назначен сеанс, то свойство не добавляется.

Usr – имя пользователя информационной базой под которым выполняется 
    данный поток. Если пользователь не определен, подставляется значение 
    DefUser.

Trans – показывает открыта транзакция на момент начала события или нет.
    1 – открыта, 0 – нет.

dbpid – номер соединения сервера 1С с сервером баз данных.

SQL – текст инструкции SQL. 
    Чаще всего здесь содержится текст запроса SQL с параметрами.

Rows – количество строк, которые вернул запрос.

RowsAffected – количество строк, которые изменил запрос в базе данных.

Context – какая строка кода на языке 1С породила данное событие. 
    Наверное, самое интересное для нас событие.

Бурмистров Андрей

В следующих статьях рассмотрим «События», а также их фильтрацию в ТЖ.

А пока закрепите полученный материал на своей тестовой информационной базе

PDF-версия статьи для участников группы ВКонтакте

Мы ведем группу ВКонтакте – http://vk.com/kursypo1c.

Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.

Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)
Ссылка доступна для зарегистрированных пользователей)

Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.

Если вы хотите узнать больше об оптимизации 1С и быть экспертом в этой области – пройдите наш новый курс «Оптимизация производительности 1С:Предприятие».

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Что такое технологический журнал? Это собственный формат логов 1С собирающий всю информацию о работе установленных на данном ПК приложениях 1С:Предприятие. По умолчанию технологический журнал настроен на сохранение минимальных дампов, возникающих при аварийном завершении программы.

Однако, давайте честно, многие из читающих данную статью имеют знания и опыт чтобы работать с дампами? А те, кто все-таки умеют это делать, будут этим заниматься? Нет, так как практического смысла в этом немного. Процитирую В. Гилева:

В дампах могут разобраться только разработчики платформы! (только у них исходники )

Поэтому сразу забываем о дампах и сосредотачиваемся на гораздо более простых и понятных вещах — логах. Для чтения логов не нужно иметь специфических знаний, достаточно просто инженерного опыта и общих представлений о работе операционной системы и непосредственно 1С:Предприятия.

Платформа Windows

Для включения и настройки технологического журнала в среде Windows необходимо в папке C:Program Files (x86)1cv8conf создать специальный файл настроек logcfg.xml. В самом простейшем случае он может выглядеть так:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:Program Files (x86)1cv8logs" history="168">
    <event>
      <ne property="Name" value=""/>
    </event>
    <property name="all">
    </property>
  </log>
</config>

Разберем структуру файла подробнее:

• log location — расположение файлов лога, указанная директория должна существовать, и пользователь от имени которого запускается 1С должен иметь право записи в нее.
• history — время хранения логов в часах, в нашем примере 168 часов равно 7 суткам или неделе.
• event — таких секций может быть много, соответствуют фиксируемым событиям. В данном случае фиксируются все события.
• property — определяет попадание в журнал свойств событий. Конструкция property name=»all» включает записи в журнал всех свойств событий.

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

Внимание! 1С категорически не рекомендует включать подобный тип журнала на рабочих серверах!

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

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:Program Files (x86)1cv8logs" history="168">
    <event>
      <eq property="Name" value="PROC"/>
    </event>
    <event>
      <eq property="Name" value="SCOM"/>
    </event>
    <event>
      <eq property="Name" value="CONN"/>
    </event>
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <event>
      <eq property="Name" value="ADMIN"/>
    </event>
    <event>
      <eq property="Name" value="QERR"/>
    </event>
    <property name="all">
    </property>
  </log>
</config>

В данном примере фиксируются следующие события:

• PROC — события, относящиеся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например, старт, завершение, аварийное завершение и т.п.
• SCOM — события создания или удаления серверного контекста, обычно связанного с информационной базой.
• CONN — установка или разрыв клиентского соединения с сервером.
• EXCP — исключительные ситуации приложений системы 1С:Предприятие, которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса.
• ADMIN — управляющие воздействия администратора кластера серверов системы 1С:Предприятие.
• QERR — события, связанные с обнаружением ошибок компиляции запроса или ограничения на уровне записей и полей базы данных.

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

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

<event>
   <eq property="Name" value="HASP"/>
 </event>

Это позволит фиксировать события обращения к ключам защиты в том виде, в котором они фиксируются системой защиты HASP, в то время как 1С подменяет их своими сообщениями, типа «ключ защиты не обнаружен», обладающими крайне низкой информативностью.

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

Для каждого процесса создается отдельная папка с его именем и ID, каждая из которых содержит внутри текстовые файлы с именем формата ггммддчч, т.е. год-месяц-день-час, каждый час создается новый файл лога. Так, например, лог за 12 января 2016 года с 15 до 16 часов будет иметь имя 16011215.log, затем 16011216.log и т.д.

Для примера приведем участок лога:

25:25.282004-0,EXCP,0,process=ragent,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='srcServerAgentImpl.cpp(697):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=W81-TEST descr=11001(0x00002AF9): Этот хост неизвестен. line=1102 file=srcDataExchangeCommon.cpp'
25:35.876000-0,EXCP,1,process=ragent,ClientID=0,Exception=NetDataExchangeException,Descr='server_addr=W81-TEST descr=11001(0x00002AF9): Этот хост неизвестен. line=1102 file=srcDataExchangeCommon.cpp'

Сразу видно, что система не может разрешить имя сервера W81-TEST, возможно из-за проблем в DNS. Как видим, логи вполне читабельны и понятны, что позволяет осмысленно подходить к разбору ошибок, особенно в тех случаях, когда явного сообщения об ошибке не выводится, скажем не стартует процесс сервера.

Платформа Linux

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

Прежде всего расположение файла настроек. Он должен находиться в /home/usr1cv8/.1cv8/1C/1cv8/conf, по умолчанию данная директория не существует и ее нужно будет создать. Также, если вы предпочитаете графические инструменты настройки, учтите, что директория .1cv8 скрытая (на это указывает точка в начале имени) и просто так в файловом менеджере вы ее не увидите.

Мы предпочитаем работу в консоли, как более привычную и удобную для данной платформы. Поэтому создадим данную директорию:

mkdir /home/usr1cv8/.1cv8/1C/1cv8/conf

а в ней файл настроек:

touch /home/usr1cv8/.1cv8/1C/1cv8/conf/logcfg.xml

После чего можно приступать к его редактированию, содержимое должно быть полностью идентичным Windows-версии, за исключением пути хранения логов. В файловой системе Linux они традиционно располагаются в /var/log и мы не рекомендуем отступать от традиций, потому, что если с данным сервером придется работать другому специалисту, то он будет искать логи именно там.

Изменим строку конфигурационного файла logcfg.xml следующим образом:

<log location="/var/log/1C" history="168">

Затем создадим папку для логов 1С

mkdir /var/log/1C

А чтобы 1С могла писать туда, установим пользователя и группу 1С владельцем этого каталога:

chown usr1cv8:grp1cv8 /var/log/1C

Теперь перезапускаем процесс сервера 1С

service srv1cv83 restart

и отмечаем создание в директории папок и файлов с логами.

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

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

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

Попытка использовать для записи логов эту папку не приведет к успеху, папки процессов будут создаваться, но логи появляться не будут. Можно, конечно, перенастроить место хранения логов на любую папку в домашней директории, но лучше продолжить использовать для этого /var/log/1C.

Чтобы запущенное от имени пользователя приложение могло писать в данную папку надо предоставить ему соответствующие права. Если вы единственный пользователь компьютера и серверной версии 1С у вас не установлено, то можно просто сделать текущего пользователя владельцем данной папки, если пользователей несколько, либо на этом же ПК стоит серверная часть и вы хотите включить журнал и для нее, то нужно настроить совместный доступ.

Прежде всего добавим нужных пользователей в группу 1С:

usermod -a -G grp1cv8 andrey

Затем изменим права на папку логов, чтобы писать в нее мог не только владелец, но и группа:

chmod 775 /var/log/1C

Для применения прав нужно завершить сеанс пользователя и войти заново, после этого можно запустить клиентское приложение и убедиться, что в каталоге /var/log/1C создаются нужные папки логов.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

Технологический журнал является набором текстовых файлов, хранящихся в различных каталогах. За настройку и ведения ТЖ отвечает конфигурационный файл logcfg.xml, в котором описываются:

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

По умолчанию конфигурационный файл отсутствует. Это означает, что технологический журнал включен и настроен на сохранение минимальных дампов при аварийном завершении приложения в каталог: %USERPROFILE%Local SettingsApplication Data1C1cv8dumps

Настройка конфигурационного файла logcfg.xml технологического журнала

Для того, чтобы настроить сохранение логов технологического журнала требуется создать файл logcfg.xml и сохранить его в каталог конфигурационных файлов на сервере 1С, т.е. в тот каталог, в котором у вас установлена система 1С Предприятие, например: C:Program Files1cv8conf

Следует сказать, что наличие конфигурационного файла не является обязательным. Если он отсутствует, то ТЖ считается включенным и имеет следующие настройки по умолчанию:

• Технологический журнал (элемент <log>) ‑ выключен.
• Технологический журнал по умолчанию (элемент <defaultlog>):
  • Формирование ‑ включено.
  • Время жизни ‑ 24 часа.
  • Уровень формирования событий <system> для всех компонентов системы определен как Error.
  • Сохраняется в каталоги:ОС Windows: %USERPROFILE%Local Settings1C1cv8logs (%LOCALAPPDATA%1C1cv8logs для ОС Windows Vista и выше).
•  Дампы аварийного завершения (актуально только для ОС Windows):
  • Сохраняются минимальные дампы аварийного завершения работы системы (type=»1″).
  • Дампы сохраняются в каталог %USERPROFILE%Local SettingsApplication Data1C1cv8dumps (%LOCALAPPDATA%1C1cv8dumps для ОС Windows Vista и выше).

Структура конфигурационного файла

Корневым элементом конфигурационного файла является элемент <config>, который определяет настройки технологического журнала. Он может содержать несколько элементов <log>, один элемент <dump>, один элемент <leaks>, один элемент <plansql>, один элемент <defaultlog>, один или несколько элементов <system>

Описание элементов:

• Элемент <log> определяет каталог технологического журнала и его состав
• Элемент <dump> определяет каталог для записи дампов аварийного завершения
• Элемент <leaks> устанавливает отслеживание утечек памяти, которые могут быть вызваны ошибками в коде конфигурации. Отслеживание утечек памяти несколько снижает производительность.
• Элемент <mem> предназначен для учета используемой памяти
• Элемент <plansql> предназначен для управления сбором планов запроса, формируемых при работе различных СУБД. Собственно планы запросов содержатся в свойстве <planSQLText> событий, связанных с СУБД.
• Элемент <dbmslocks> предназначен для управления сбором информации о блокировках СУБД 
• Элемент <ftextupd> предназначен для управления сбором информации о процессах обновления индекса полнотекстового поиска
• Элемент <query> управляет помещением в технологический журнал информации о полях, содержащих NULL при исполнении запроса к внешнему источнику данных, но для которых такое значение не допускается
• Элемент <inputbystring> предназначен для управления сбором информации об использовании механизма ввода по строке.
• Элемент <scriptcircrefs> управляет работой механизма отслеживания информации о циклических ссылках во время выполнения встроенного языка
• Элемент <defaultlog> определяет каталог и время жизни технологического журнала по умолчанию 
• Элемент <system> определяет настройки формирования системных событий 

Остановимся на ключевых элементах конфигурационного файла.

Элемент <log>

Элемент <log> определяет каталог технологического журнала и условия отбора, по которым в технологический журнал помещаются ранее сформированные события.

Важно! Крайне не рекомендуется использовать более 20 элементов <log> — это может привести к значительному замедление работы системы 1С Предприятие.

Атрибуты элемента <log>:

• Атрибут location — Имя каталога, в котором будет размещаться технологический журнал.
• Атрибут history — Количество часов, через которое информация будет удаляться из технологического журнала.

Элемент <event>

Набор элементов <event> определяет условие, при выполнении которых события будут записываться в журнал. В ТЖ помещаются только события, которые удовлетворяют условию.

Доступны следующие имена событий:

Имя события	Описание
ADMIN	Управляющие воздействия администратора кластера серверов системы 1С:Предприятие
ATTN	Записи подсистемы мониторинга состояния кластера 1С
CALL	Входящий удаленный вызов (удаленный вызов на стороне приемника вызова)
CLSTR	Выполнение операций, изменяющих работу кластера серверов
CONFLOADFROMFILES	Выполнение операций загрузки конфигурации из файлов
CONN	Установка или разрыв клиентского соединения с сервером
DB2	Исполнение операторов SQL СУБД Db2
DBCOPIES	Работа с копиями базы данных
DBMSSQL	Исполнение операторов SQL СУБД Microsoft SQL Server
DBMSSQLCONN	Событие формируется при первом соединении сервера «1С:Предприятие» с СУБД Microsoft SQL Server в тот момент, когда происходит выбор провайдера для работы с базой данных
DBORACLE	Исполнение операторов SQL СУБД Oracle Database
DBPOSTGRS	Исполнение операторов SQL СУБД PostgreSQL
DBV8DBENG	Исполнение операторов SQL файловой СУБД
DHIST	Выполнение обновления истории данных
EDS	Работа с внешними источниками данных
EXCP	Исключительные ситуации приложений системы «1С:Предприятие», которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса
EXCPCNTX	События, которые начались, но не закончились в момент возникновения нештатной ситуации
FTEXTCheck	Возникает при проверке файлов индекса полнотекстового поиска
FTEXTUpd	Возникает во время обновления файлов индекса полнотекстового поиска
HASP	Событие описывает одно обращение к аппаратному ключу защиты
InputByString	Возникает при обработке платформой ввода по строке
LEAKS	События, связанные с утечкой памяти, которые могут быть вызваны ошибками в коде конфигурации
LIC	События, связанные с получением и освобождением лицензий (как программных, так и ключей HASP), получением лицензий на базовые версии, регулярным мониторингом соответствия реального оборудования и списка оборудования, зафиксированного в лицензии
MAILPARSEERR	Событие, формируемое в том случае, если во время разбора почтового сообщения возникла ошибка
MEM	События, связанные с увеличением объема памяти, занятой серверными процессами (ragent, rmngr, rphost).
PROC	События, относящиеся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например: старт, завершение, аварийное завершение и т. п.
QERR	События, связанные с обнаружением ошибок компиляции запроса или ограничения на уровне записей и полей базы данных
SCALL	Исходящий удаленный вызов (исходящий вызов на стороне источника вызова)
SCOM	События создания или удаления серверного контекста, обычно связанного с информационной базой
SDBL	События, связанные с исполнением запросов к модели базы данных системы 1С:Предприятие
SDGC	Событие возникает при срабатывании механизма очистки сеансовых данных
SESN	Действия, относящиеся к сеансу работы. Например: начало сеанса, окончание сеанса и т. д.
SRVC	События, связанные с запуском, остановкой и оповещениями сервисов кластера серверов
SYSTEM	Системные события механизмов платформы, предназначенные для анализа специалистами фирмы «1С». Настройка событий данного типа должна производиться на основе явных указаний со стороны службы технической поддержки и только на время воспроизведения какой-либо расследуемой проблемы. В противном случае, подобная настройка может привести к существенному увеличению объемов файлов журнала и замедлению работы приложения
TDEADLOCK	Обнаружена взаимоблокировка в управляемом режиме
TLOCK	Управление транзакционными блокировками в управляемом режиме
TTIMEOUT	Превышение максимального времени ожидания транзакционной блокировки
VRSCACHE	Работа кеша серверных вызовов
VRSREQUEST	Запрос к серверу за некоторым ресурсом
VRSRESPONSE	Ответ сервера
WINCERT	Ошибки, связанные с проверкой сертификата средствами ОС Windows. Такие события могут помочь специалистам в расследовании причин некорректной проверки сертификатов

Условия задаются элементами:

• eq‑ равно;
• ne‑ не равно;
• gt‑ больше;
• ge‑ больше или равно;
• lt‑ меньше;
• le‑ меньше или равно;
• like‑ соответствие маске.

Примеры настройки технологического журнала

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

1. Создать каталог на сервере для хранения логов технологического журнала
2. Создать файл logcfg.xml или скачать готовый. Примеры содержания данного файла вы найдете ниже. Указав в данном файле каталог, созданный на шаге 1
3. Сохранить этот файл на сервере в конфигурационный каталог, куда установлена система 1С. Например:  C:Program Files1cv8conf

Полный технологический журнал

<config xmlns="http://v8.1c.ru/v8/tech-log">
    <log location="C:v8logs" history="168">
        <event>
            <ne property="name" value=""/>
        </event>
        <property name="all">
        </property>
    </log>
</config> 

После сохранения журнала не забудьте указать свой каталог в атрибуте location. Т.е., следует заранее создать каталог и заменить в строке <log location=»C:v8logs» на него.

Настройки, приведенные выше позволят сохранить все события со всеми свойствами, при этом журнал будет сохраняться 168 часов (одна неделя). Важно понимать, что объем выводимой информации будет очень большим, поэтому не рекомендуется использовать данные настройки в рабочих системах на постоянной основе, однако это может быть весьма полезно на этапе внедрения или при расследовании ошибок. Для рабочих систем следует остановиться на приведенных ниже вариантах.

Ошибки системы и действия администратора

<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:v8logs" history="168">
    <event>
        <eq property="name" value="admin"/>
    </event>
    <event>
        <eq property="name" value="conn"/>
    </event>
    <event>
        <eq property="name" value="excp"/>
    </event>
    <event>
        <eq property="name" value="proc"/>
    </event>
    <event>
        <eq property="name" value="qerr"/>
    </event>
    <event>
        <eq property="name" value="scom"/>
    </event>
    <property name="all"/>
 </log>
</config>

Данный конфигурационный файл создает технологический журнал относительно небольшого объема, в котором содержится информация о запуске и завершении приложений, установке и разрыве соединений с кластером серверов «1С:Предприятия», действиях администратора кластера и об ошибочных ситуациях в работе 1С:Предприятия. Такой журнал в большинстве случаев достаточен для расследования ошибочных ситуаций как в конфигурации, так и в технологической платформе 1С.

Для удобства вы можете скачать данный файл по ссылке.

Ограничение по времени выполнения

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
 <dump create="false"/>
 <log location="C:v8logs" history="168">
    <event>
        <eq property="name" value="admin"/>
        <gt property="duration" value="100000"/>
    </event>
    <event>
        <eq property="name" value="conn"/>
        <gt property="duration" value="100000"/>
    </event>
    <event>
        <eq property="name" value="excp"/>
        <gt property="duration" value="100000"/>
    </event>
    <event>
        <eq property="name" value="proc"/>
        <gt property="duration" value="100000"/>
    </event>
    <event>
        <eq property="name" value="qerr"/>
        <gt property="duration" value="100000"/>
    </event>
    <event>
        <eq property="name" value="scom"/>
        <gt property="duration" value="100000"/>
    </event>
    <property name="all"/>
 </log>
</config>

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

Зачем он нужен

Технологический Журнал (далее ТЖ) позволяет протоколировать все события 1С:Предприятия (или часть, используя фильтр), например:
— исполняемый код 1С:Предприятие 8;
— код Transact-SQL для СУБД;
— интерактивные действия пользователей,

— сообщения об ошибках,

— утечки памяти.
В случаи аварийного завершения журнал позволяет сделать дамп памяти и копию экрана для передачи разработчикам.

Основное

Журнал настраивается с помощью файла logcfg.xml в папку программы C:Program Files1cv81binconf
1) Для успешного создания логов, нужно создать каталоги для логов (например C:Program Files1cv81binlogs) и дапмов (например C:Program Files1cv81bindumps)

2) К этим каталогам ТЖ должны быть обязательно настроены права:

— полные права на каталог технологического журнала;

— права на чтение владельца каталога технологического журнала.

Проверяйте наличие прав с помощью Procmon.

Примечание. Если все равно не пишется ТЖ, то дать права всем на эту папку (временно, чтобы убедиться что дела в правах).

3) В каталоге технологического журнала не должно быть посторонних файлов. Каталог, в котором имеются посторонние файлы не позволит создавать журнал (логи).

4) Место хранения dumps и logs не хранить вместе, потому что через указанный интервал (по умолчанию 1 час) содержимое польностью перетирается и вы потеряете дампы

Настройка

ТЖ лучше настраивать (с помощью фильтров — тэгов logcfg.xml) только на исследуемые события, остальное не собирать, иначе словите «отсутствие места на диске» и тормоза в быстродействии сервера.

1) Легче выполнять настройку фильтров с помощью обработки с ИТС НастройкаТехнологическогоЖурнала.epf, но при этом помнить, что новые фичи последних релизов в обратке могут отстутствавать (каждая новая версия добавляет новые возможности, в обработки они не отражены). В этом случаи корректировать файл logcfg.xml руками.

2) Чтобы логи перестали собираться достаточно переименовать файл, перезапускать сервер не надо, настройки пересчитываются каждую минуту «на лету»

3) настроить logcfg.xml для фильтрации событий по определённой ИБ нужно использовать  «p:processName=»

4) http://users.v8.1c.ru/Adm1936.aspx — примеры настроек

Подробности

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

1) Сложности чтения ТЖ:

— Требует хорошего понимания архитектуры работы системы

— Тексты запросов регистрируются на внутреннем языке 1С:Предприятия и на языке DBMS

2) Файлы технологического журнала хранятся в подкаталогах. Имя каждого подкаталога технологического журнала одного процесса будет иметь вид: <ИмяПроцесса>_<ИдентификаторПроцесса>, например: rphost_4076. Имя файла журнала задается шаблоном ГГММДДЧЧ.log. Например, в журнале 07051819.log имя файла образовано от 2007 мая 18, 19 часов)

3) Журнал для анализа можно выгрузить в эксель, используя разделителем запятую например

4)1С:ЦУП использует для своих аналитических показалей логи технологического журнала. При использовании ЦУП другие данные собираться не должны, удалите logcfg.xml вручную, ЦУП сам создаст файл с нужными настройками.

5) Возможные ошибки и доп. информация:

— ищем логи в каталоге на сервере хотя для 64 разрядного сервера другой каталог программы

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

<config xmlns=»http://v8.1c.ru/v8/tech-log«>
<log location=»C:Program Files1cv81logs» history=»24″>
<event>
<eq property=»Name» value=»EXCP»/>
</event>
<event>
<eq property=»Name» value=»SDBL»/>
<eq property=»Func» value=»BeginTransaction»/>
</event>
<event>
<eq property=»Name» value=»DBMSSQL»/>
<ge property=»Duration» value=»30000″/>
</event>
<property name=»All»/>
</log>
</config>

— более подробно с особенностями использования технологического журнала можно ознакомиться по материалам семинара партнеров 2 — 4 марта 2007 года, доклад «Средства диагностики работы системы «1С:Предприятия 8.1″».

События в ТЖ

Удобные для анализа ошибок

События EXCP — исключительные ситуации приложений системы «1С:Предприятие», которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса.
События EXCPCNTX — события, которые начались, но не закончились в момент возникновения нештатной ситуации.

Для анализа скорости веба

Событие VRSREQUEST — запрос к серверу за некоторым ресурсом.

Событие VRSRESPONSE — ответ сервера.

Для анализа активности

Событие SCALL — исходящий удаленный вызов (исходящий вызов на стороне источника вызова).

Событие CALL — входящий удаленный вызов (удаленный вызов на стороне приемника вызова).

Анализ утечек и расхода памяти

События LEAKS — события, связанные с утечкой памяти, которые могут быть вызваны ошибками в коде конфигурации.
События MEM — события, связанные с увеличением объема памяти, занятой серверными процессами (ragent, rmngr, rphost). 

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

если вы не нашли ответ на ваш вопрос, давайте расширим материал

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

Включение технологического журнала

Суть этого механизма в том, чтобы 1С записывала выбранные действия в файл формата XML, расположенный в определенном месте. Для операционных систем семейства Windows этот путь:

• «C:Program Files1cv8conf»

Если же вы используете Linux, то:

• «/home/usr1cv8/.1cv8/1C/1cv8/conf»

Для примера рассмотрим простейшую структуру этого файла под именем «logcfg.xml» и опишем ее основные разделы:

1. Log – в реквизит location указывают месторасположение логов. Это должен быть существующий каталог, а у пользователей должны быть права на запись в него. Речь идет о пользователях, от имени которых может запускаться 1С, и, соответственно, могут записываться логи при определенных событиях. Реквизит history отражает время хранения логов в часах;
2. Event – здесь отражаются фиксируемые события с помощью свойств property и name;
3. Property – указанное значение в свойстве name отражает настройку, отвечающую за набор событий, попадающих в технологический журнал.

Существует множество различных настроек, указываемых в свойстве name. Не разобравшись в этом перечне, невозможно правильно настроить файл logcfg.sml. При этом неправильно настроенный технологический журнал очень опасен: резко увеличивающийся объем логов и падение в несколько раз производительности сервера станут неприятным исходом.

Перечислим основные параметры, достаточные для понимания большинства проблем:

• ALL – все события;
• ADMIN – действия администратора;
• CONN – установка и разрыв клиентской сессии с сервером;
• EXCP – исключительные ситуации, причины аварийного разрыва сессий;
• EXCPCNTX – исполняющиеся события в момент возникновения аварийной ситуации;
• LEAKS – регистрация утечки памяти из-за ошибок в конфигурации;
• MEM – утечки памяти на серверных процессах;
• PROC – этапы процессов – начало, окончание;
• QERR – ошибки компиляции запросов и ограничения по правам;
• SCOM – создание и удаление объектов на сервере.

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

Для этого нужно либо запустить клиентское приложение 1С, либо перезагрузить сервер. В результате для каждой сессии создается отдельная папка с идентификатором, в которую пишутся действия пользователя в текстовые файлы. Все логи разбиты по 1 часу и названы в соответствии со временем начала. Логи за 3 сентября 2018 года с 12-00 до 13-00 запишутся в файл с именем «18090312».

Настройка систем семейства Linux для включения ТЖ

Сам журнал и его включение никаких особенностей не имеет на другой платформе, но ее архитектура достаточно сложна для начинающих администраторов. Необходимое расположение файла с настройками технологического журнала уже было обозначено, но в системе нет такой директории. Подготовить систему к регистрации логов 1С поможет следующий алгоритм действий в консоли:

1. Создаем нужный каталог внутри скрытой директории «.1cv8». В файловом менеджере ее невозможно увидеть, поэтому вводим следующую команду в консоли:
   • mkdir /home/usr1cv8/.1cv8/1C/1cv8/conf
2. Создаем сам файл настроек формата xml:
   • Touch /home/usr1cv8/.1cv8/1C/1cv8/conf/logcfg.xml
3. Содержимое настроечного файла идентично версии для Windows, за исключением местоположения файлов логов. В операционных системах под Linux заведено, что все логи хранятся в папке «/var/log». Конечно, от этого правила можно отступить, но это приведет лишь в путанице, поэтому этого делать не стоит. В результате раздел log будет выглядеть так:
   • log location=”/var/log/1C” history=”168″
4. Естественно, эту папку нужно будет создать:
   • mkdir /var/log/1C
5. Также для осуществления записи в только что созданную папку, необходимо дать на это права тем сотрудникам, которые будут работать с 1С. Следующей командой мы устанавливаем пользователя и всю группу 1С в качестве владельца на новый каталог:
   • chown usr1cv8:grp1cv8 /var/log/1C
6. Чтобы появились папки и началось ведение логов на сервере 1С, необходимо перезапустить его процесс командой:
   • service srv1cv83 restart
7. Вышеперечисленные действия позволят включить технологический журнал и фиксировать нужные события на сервере 1С. Если вы хотите вести учет действий клиентских приложений, то придется сделать дополнительные настройки. Проблема в том, что настройки платформы создаются для каждого пользователя отдельно и хранятся в домашних каталогах. Чтобы настроить права пользователя на запись логов в указанной папке, нужно включить его в группу «grp1cv8»:
   • usermod –a –G grp1cv8 IvanovIC
8. Также потребуется редактировать права на запись в папку логов, чтобы группа могла писать наравне с владельцем:
   • chmod 775 /var/log/1C

Чтобы фиксация логов начала функционировать, пользователю необходимо завершить сеанс и заново войти в систему. После этих действий в папке /var/log/1C начнут создаваться папки и файлы с данными.

Анализ данных технологического журнала

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

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

Чтобы понимать, что можно увидеть в логах, разберем всю информацию, которая там находиться. 1С пишет данные формата определенного шаблона «MM:SS.TTTT-L,Name,Level,Properties», где:

• MM – порядковый номер минуты окончания события в часе, указанном в названии;
• SS – порядковый номер секунды в вышеуказанной минуте;
• TTTT – номер миллионной доли. В более ранних версиях стоял порядковый номер десятитысячной доли секунды;
• L – длительность события в миллионных долях в версии 1С 8.3. Для ранних версий – в десятитысячных долях;
• Name – имя события в системе;
• Level – уровень окончившегося события в очереди потока;
• Properties – в этом параметре перечислены свойства операции. Записываются по шаблону «ИмяСвойства=ЗначениеСвойства» и разделяются запятыми.

Проанализируем пример строки из логов технологического журнала файла «18090312.log»:

• 12:13:569 – минуты, секунды и миллионные доли секунды. Совместно с названием файла получаем информацию, что данное событие окончилось 3 сентября 2018 года в 12:12:13,000569;
• 1 – длительность события – 0,000001 секунды;
• DMBSQL,3 – наименование и уровень окончившегося события;
• Process=rphost – указывает на конкретный процесс, чей лог записан;
• p:processName=TestBase – указывает, что логи пишутся для базы под названием «TestBase»;
• t:clientID=1572,t:applicationName=BackgroundJob – в этих свойствах указаны идентификаторы соединения с клиентов и клиентской программы, соответственно;
• t:connectID =1236 – номер соединения с ИБ;
• SessionID=234 – идентификатор сеанса текущего потока;
• Usr=DefUser,Trans=0,dbpid=11 – имя пользователя, показатель открытой или закрытой транзакции и идентификатор связи сервера приложений 1С с сервером БД;
• Sql – текст запроса на языке SQL;
• Context – ключевое значение, показывающее нам, какая строка кода в 1С породила событие.

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

Технологический Журнал (далее ТЖ) позволяет протоколировать все события 1С:Предприятия (или часть, используя фильтр).
ТЖ настраивается с помощью файла logcfg.xml в папку программы C:Program Files1cv81binconf, пример структуры файла (включить запись событий DBMSSQL):

Код

< config xmlns=»http://v8.1c.ru/v8/tech-log»>
< log history=»168″ location=»C:Program Files1Cv81binlogs»>
< event>
< eq property=»name» value=»dbmssql»/>
< /event>
< property name=»all»/>
< /log>
< dump create=»1″ location=location=»C:Program Files1Cv81bindumps» type=»2″ />
< /config>

1. Для успешного создания логов, нужно создать каталоги для логов (например C:Program Files1cv81binlogs) и дапмов (например C:Program Files1cv81bindumps),
где в случае аварийного завершения ТЖ создаст дамп памяти и копию экрана для передачи разработчикам.
Важно иметь в виду, что в каталог ТЖ при некоторых его настройках могут выводится данные очень большого объема. Поэтому, либо на диске С: должно быть достаточно места, либо каталог ТЖ необходимо изменить.
Для работы ТЖ необходимо, чтобы пользователи, от имени которых запускаются приложения 1С:Предприятия (как клиентские, так и серверные), имели полные права на каталог ТЖ (C:Program FiIes1cv81binlogs), и право на чтение выше лежащего каталога (C:Program Fileslcv81).
Примечание. Если все равно не пишется ТЖ, то дать права всем на эту папку (временно, чтобы убедиться что дела в правах).

В каталоге технологического журнала не должно быть посторонних файлов. Каталог, в котором имеются посторонние файлы не позволит создавать журнал (логи).
Место хранения dumps и logs не хранить вместе, потому что через указанный интервал (по умолчанию 1 час) содержимое польностью перетирается и вы потеряете дампы

2. ТЖ лучше настраивать (с помощью фильтров — тэгов logcfg.xml) только на исследуемые события, остальное не собирать, иначе словите «отсутствие места на диске» и тормоза в быстродействии сервера.
Легче выполнять настройку фильтров с помощью обработки с ИТС НастройкаТехнологическогоЖурнала.epf, но при этом помнить, что новые фичи последних релизов в обратке могут отстутствавать (каждая новая версия добавляет новые возможности, в обработки они не отражены). В этом случаи корректировать файл logcfg.xml руками.

Структура конфигурационного файла

Корневым элементом конфигурационного файла является элемент < config>, который определяет настройки ТЖ. он может содержать несколько элементов < log> и один < dump>

< log> определяет каталог ТЖ:
history = количество часов, через которое инфа будет удалятся из ТЖ.
location = Каталог в котором сохраняются логи

Код

< log history=»168″ location=»C:Program Files1Cv81binlogs»>
…
< /log>

Элемент < dump> определяет каталог в который будут записываться дампы аварийного завершения

Код

< dump create=»1″ location=location=»C:Program Files1Cv81bindumps» type=»2″ />

< event> — этим элементом определяется условие, при выполнении которого событие будет записано в ТЖ. Условия записываются элементами:
eq = равно
ne = не равно
gt = больше
ge = больше или равно
lt = меньше
le = меньше или равно
like = соответсвие маске

property — атрибут задает название события
value — атрибут задает значение события, ниже пример в котором в ТЖ будут регистрироваться события относящиеся к группе с именем «dbmssql»

Код

< event>
< eq property=»name» value=»dbmssql»/>
< /event>

Доступны следующие имена групп, с выходом новых версий платформы возможны добавления новых групп:
PROC — события, относящиеся к процессу целиком и влияющие на дальнейшую работоспособность процесса(старт, завершение, аварийное завершение и т.д.);
SCOM — события создания или удаления серверного контекста, обычно связанного с информационной базой;
ЕХСР — исключительные ситуации приложений системы Предприятие 8.1, которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса;
EXCPCNTX — события, которые начались, но не закончились в момент возникновения нештатной ситуации;
SDBL — события, связанные с исполнением запросов к модели базы данных системы 1С:Предприятие 8.1;
QERR — события, связанные с обнаружением ошибок компиляции запроса или ограничения на уровне записей и полей базы данных.
PERR — события, связанные с обнаружением ошибок работы с настройками пользователя;
CONN — установка или разрыв клиентского соединения с сервером;
ADMIN — управляющие воздействия администратора кластера серверов;
DBV8DBErg — исполнение операторов SQL файловой СУБД;
DBMSSQL — исполнение операторов SQL СУБД Microsoft SQL Server;
DBPOSTGRS — исполнение операторов SQL СУБД PostgreSQL;
DB2 — исполнение операторов SQL СУБД DB2,
CALL — удаленный вызов.
TLOCK — управление транзакционными блокировками в управляемом режиме.

Следует заметить, что на клиентском компьютере могут возникать только те события, которые отсносятся к группам PROC, ЕХСР, SDBL Также на клиентском компьютере могут возникать события из группы DBVBDBEng, если используется файловый вариант работы системы 1С:Предприятие 8.1.
Также следует заметить, что события из групп PROC, SCOW, ЕХСP, CONN и ADMIN возникают относительно и содержат малое количестово информации, в то время как регистрация событий из групп SDBL, DBVPCBE v и DBMSSQL может привозить к значительному росту ТЖ.

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

4. Настроить logcfg.xml для фильтрации событий по определённой ИБ нужно использовать «p:processName=»
5. Дополнительные примеры настроек взятые с форумов
6. Дополнительные примеры настроек на сайте 1С

7. Понятно, что собрать логи мало, их еще нужно обработать для решения конкретной задачи.
Файлы ТЖ могут быть просмотрены с помощью любого текстового редактора, но через блокнот ТЖ сложно читаем, так как:
— Требует хорошего понимания архитектуры работы системы
— Тексты запросов регистрируются на внутреннем языке 1С:Предприятия и на языке DBMS
Файлы технологического журнала хранятся в подкаталогах. Имя каждого подкаталога технологического журнала одного процесса будет иметь вид: < ИмяПроцесса>_< ИдентификаторПроцесса>, например: rphost_4076. Имя файла журнала задается шаблоном ГГММДДЧЧ.log. Например, в журнале 07051819.log имя файла образовано от 2007 мая 18, 19 часов)
Журнал для анализа можно выгрузить в эксель, используя разделителем запятую например
1С:ЦУП использует для своих аналитических показалей логи технологического журнала. При использовании ЦУП другие данные собираться не должны, удалите logcfg.xml вручную, ЦУП сам создаст файл с нужными настройками.

Других парсеров логов от 1С нет, есть ObrabotkaTehnologiceskogoGurnala.epf

8. Возможные ошибки и доп. информация:
— ищем логи в каталоге на сервере хотя для 64 разрядного сервера другой каталог программы
— отследить не завершившийся запрос; событие технологического журнала DBMSSQL выводится только в момент окончания выполнения запроса. Если запрос долго не может выполниться, то его выполнение можно прервать, после чего будут выведены в технологический журнал связанные с ним события.

В статье использованы материалы с http://www.gilev.ru/1c/81/techlog/index.htm

Содержание

1. Общая информация
2. Включение технологического журнала
3. Создание файла настроек
4. <dump>
5. <log>
6. <event>
7. <property>

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18