Коллеги, продолжаем серию статей, посвященных технологическому журналу.
Сегодня мы покажем практику анализа логов ТЖ.
Другие статьи из серии «Технологический журнал»:
Что Вы узнаете из этой статьи?
Давайте посмотрим что произойдет, если мы создадим файл logcfg.xml с указанной выше структурой и поместим его в каталог «C:\Program Files\1Cv82\conf»
Подождем 60 секунд и откроем каталог «C:\1C_Info\Logs» , т.к. именно его мы указывали в 3 строке файла logcfg.
Если каталога 1C_Info на диске нет, то сервер 1С попробует его создать, но есть риск того что у пользователя под которым запущена служба 1С не будет прав. Поэтому рекомендуется создавать каталоги для логов вручную и проверять наличие прав у сервера 1С на запись в данный каталог.
В результате в каталоге мы видим 3 подкаталога.
Каждый процесс кластера создал каталог, в котором находятся логи только данного процесса, а т.к. у меня только 3 процесса, то и каталогов тоже 3.
Каталог создается по шаблону ИмяПроцесса_PIDПроцесса. PID нужен для того, чтобы отличать процессы с одинаковым именем.
Файл лога именуется по шаблону ГГММДДЧЧ.log.
Если лог старше чем количество часов указанное в параметре history файла logcfg , то он автоматически удаляется платформой.
Давайте подробно разберем формат лога технологического журнала.
Событие записываются в лог только после того, как оно завершилось, т.к. необходимо фиксировать длительность события.
Строка лога имеет формат:
Мм:сс.тттт-д, <ИмяСобытия>, <Уровень>, <Свойства>
мм – номер минуты в текущем часе.
сс – номер секунды в текущей̆ минуте.
тттт – номер десятитысячной доли текущей̆ секунды, для 8.3 здесь отображается номер миллионной доли.
д – длительность события в десятитысячных долях секунды, для 8.3 в миллионных долях.
<ИмяСобытия> – наименование события.
<Уровень> – уровень события в стеке текущего потока.
<Свойства> - свойства события разделенные запятыми, значения свойств проставлены через знак «=» .
Разберем на примере.
Есть лог со следующим содержимым:
Бурмистров Андрей
В следующих статьях рассмотрим «События», а также их фильтрацию в ТЖ .
А пока закрепите полученный материал на своей тестовой информационной базе:)
Коллеги, начинаем серию статей, посвященных технологическому журналу.
В этой серии мы с вами рассмотрим практику использования полезного инструмента для расследования проблем производительности и стабильности 1С:Предприятие – технологического журнала.
Далеко не все специалисты о нем знают, а умеют грамотно использовать лишь немногие. Попытаемся исправить ситуацию:)
Что Вы узнаете из этой статьи?
ТЖ предназначен для расследования ошибок, анализа и диагностики различных проблем в работе платформы 1С:Предприятие .
С помощью ТЖ можно выяснить, какие запросы работают медленно и откуда они вызываются, при выполнении какого кода «падают» рабочие процессы сервера, куда «утекает» память и многое, многое другое.
Все инструменты анализа производительности платформы используют ТЖ для получения информации. При желании и доскональном изучении вопроса с помощью ТЖ вы можете написать свой инструмент анализа производительности.
ТЖ можно собирать как для процессов сервера 1С, так и для клиентских приложений. Соответственно, и набор событий, которые можно фиксировать в ТЖ, будет отличаться.
Клиентские логи и дампы крайне редко вызывают интерес, поэтому в статье мы будем рассматривать ТЖ исключительно с точки зрения сервера. Тем не менее все, что здесь написано, также подходит и для клиентских логов.
С помощью ТЖ можно собирать логи и настраивать формирование дампов в случае аварийного завершения работы процесса.
Логи – это файлы с расширением .log , где информация хранится в текстовом виде.
Дампы
– это файл с расширением .mdmp
, который содержит в себе содержимое оперативной памяти процесса на момент «падения».
Дамп бывает крайне необходим для расследования проблем стабильности платформы. Мы не можем самостоятельно анализировать дампы, т.к. у нас нет исходного кода платформы, но мы можем отправить их в техническую поддержку или на партнерский форум и получить решение нашей проблемы.
По умолчанию технологический журнал включен и работает, но собирает очень ограниченный объем данных.
Под минимальным объемом данных подразумеваются 2 вещи:
1) Формирование дампов минимального размера в случае аварийного завершения работы процессов кластера 1С (ragent, rmngr или rphost ).
По умолчанию дамп создается в каталоге:
%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\dumps
Если вы используете Windows Vista и выше, то будет использоваться каталог:
%LOCALAPPDATA%\1C\1Cv82\dumps
Для 8.3 вместо каталога 1Cv82 используется 1Cv8 .
2) Для 8.3 в минимальный ТЖ входит формирование логов с одним событием SYSTEM с уровнем Error .
Логи сохраняются в каталоге:
%USERPROFILE%\Local Settings\Application Data\1C\1Cv8\logs
Для Windows Vista и старше используется каталог:
%LOCALAPPDATA%\1C\1Cv8\logs
Данные логи по умолчанию будут хранится 24 часа, после чего платформа будет удалять файлы логов, которые превышают этот порог.
Чаще всего информации из ТЖ по умолчанию недостаточно, и необходимо его настраивать вручную.
Чтобы произвести тонкую настройку ТЖ, необходимо создать файл logcfg.xml с определенной структурой в определенном месте.
Данный файл необходимо разместить в каталоге:
C:\Program Files\1Cv82\conf (для 8.3 каталог 1Cv8)
В этом случае настройки ТЖ будут действовать для всех версий 1С , которые установлены на данном компьютере, и для всех пользователей. Этот вариант используется чаще всего, и именно его рекомендуем применять.
При настройках ЦУПа , облачных сервисов контроля производительности и прочих инструментов, где надо указывать путь к logcfg , также лучше использовать именно этот каталог, иначе при обновлении платформы или изменении имени пользователя, под которым запущена служба сервера 1С , описанные инструменты перестанут работать и придется менять настройку.
Тем не менее есть и другие варианты, хотя и используются они гораздо реже. Опишу лишь то, что с наибольшей вероятностью вам может понадобится.
Чтобы настроить ТЖ только для одной версии платформы, размещаем logcfg.xml в каталоге:
C:\Program Files\1Cv82\8.2.19.106\bin\conf
Где 8.2.19.106 – это номер нужной вам версии.
Крайне редко, но все же, может возникнуть необходимость настроить ТЖ отдельно для каждого пользователя, под которым запущена служба сервера 1С .
Тогда размещаем logcfg в каталоге:
%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\Conf
Для ОС Windows Vista и старше:
%LOCALAPPDATA%\1C\1Cv82\Conf
Это может потребоваться, если у вас, например, 1 служба сервера 1С используется как рабочая, а вторая для отладки. При необходимости можно запустить службы под разными пользователями и собирать ТЖ только для одной из них, чтобы не загружать второй сервер и не собирать в логах лишние данные, либо сделать для каждой из служб свои настройки ТЖ .
Настройки из logcfg считываются не моментально, а каждые 60 секунд, причем каждый из процессов кластера считывает файл настроек независимо от других процессов. Например, сначала могут появиться логи процесса rmngr и только через 45 секунды логи rphost.
Для выключения ТЖ достаточно удалить или переименовать файл logcfg.xml .
Бурмистров Андрей
В следующих статьях рассмотрим нюансы настройки ТЖ и практику использования.
А пока закрепите полученный материал на своей тестовой информационной базе:)
(или часть, используя фильтр), например:
— исполняемый код 1С:Предприятие 8;
— код Transact-SQL для СУБД;
— интерактивные действия пользователей,
— сообщения об ошибках,
Примечание. Если все равно не пишется ТЖ, то дать права всем на эту папку (временно, чтобы убедиться что дела в правах).
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) Журнал для анализа можно выгрузить в эксель, используя разделителем запятую например
Если Вы хотите воспользоваться журналом для анализа сообщений об ошибках, воспользуйтесь бесплатным сервисом .
если вы не нашли ответ на ваш вопрос, давайте расширим материал
Примеры настройки технологического журнала
Технологический журнал выключен
Если файл logcfg.xml отсутствует в каталоге C:\Program Files\1cv81\bin, то технологический журнал не создается. Если файл logcfg.xml необходим для правильной настойки дампов, то он не должен содержать ни одного элемента log. Следующий пример определяет необходимость построения полного дампа приложения при его аварийном завершении. Дампы помещаются в каталог: C:\Program Files\1cv81\bin\dumps.
< config xmlns="http://v8.1c.ru/v8/tech-log">
< dump location="C:\Program Files\1cv81\bin\dumps" create="l" type="3"/>
< /config>
Полный технологический журнал
Приведенный ниже конфигурационный файл определяет вывод в технологический журнал всех событий вместе со всеми свойствами. Журнал будет сохраняться в течение недели (168 часов). Объем выводимой информации при этом будет очень большим, однако, она может быть полезна при анализе сложных нештатных ситуаций. Данную конфигурацию рекомендуется использовать на этапе тестирования и при расследовании ошибок.
Код
< config xmlns="http://v8.1c.ru/v8/tech-log">
< log location="C:\Program Files\1cv81\bin\logs" history="168"> < event>
< ne property="Name" value="" /> < /event>
< property name="al1"> < /property>
< /log>
< /config>
Обращения к СУБД
Следующий конфигурационный файл определяет, что технологический журнал будет содержать только обращения 1С:Предприятия к СУБД, а так же информацию об ошибочных ситуациях. Объем выводимой информации меньше, чем при полном технологическом журнале, но тоже может быть очень большим.
< config xmlns="http://v8.1c.ru/v8/tech-log">
< log location="C:\Program Files\1cv81\bin\logs" history="168"> < event>
< eq propertу ="Name" va1ue="DBV8DBEng" /> < /event>
< event>
< eq propertу ="Name" va1ue="DBMSSQL"/> < /event>
< event>
< eq property="Name" value="DBPOSTGRS"/> < /event> < event>
< eq property="Name" value="DB2"/> < /event> < event>
< eq proper t у ="Name" va1ue="EXCP"/> < /event>
< property name="al1"> < /property>
< /log>
< /config>
Действия администратора и ошибки
Этот конфигурационный файл создает технологический журнал небольшого объема, в котором содержится информация о запуске и завершении приложений, установке и разрыве соединений с кластером серверов 1С:Предприятия, действиях администратора кластера и об ошибочных ситуациях в работе 1С:Пред приятия. Такой журнал в большинстве случаев достаточен, для расследования ошибочных ситуаций как в конфигурации, так и в технологической платформе 1С:Предприятия.
< config xmlns="http://v8.1c.ru/v8/tech-log">
< log location="C:\Program Files\1cv81\bin\logs" history="168"> < event>
< event> < eq property= Name" value= PR0C"/> < /event>
< event> < eq property= Name" value= SC0M"/> < /event>
< event> < eq property= Name" value= C0NN"/> < /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>
Ошибки и долгие операции
По сравнению с предыдущим, данный конфигурационный файл добавляет все операции, длительность которых превышает 10 секунд. Это может оказаться полезным для обнаружения действий пользователей, которые выполнялись длительное время, с целью, например, их последующей оптимизации. Длительность событий выражается в сотнях микросекунд.
< config xmlns="http://v8.1c.ru/v8/tech-log">
< log location="C:\Program Files\1cv81\bin\logs" history="168"> < event>
< event> < eq property= Name" value= PR0C"/> < /event>
< event> < eq property= Name" value= SC0M"/> < /event>
< event> < eq property= Name" value= C0NN"/> < /event>
< event> < eq property= Name" value= EXCP"/> < /event>
< event> < eq property= Name" value= ADMIN"/> < /event>
< event> < eq property= Name" value= QERR"/> < /event>
< event> < gt property= Duration" value="100000"/> < /event>
< property name="al1"> < /property>
< /log>
< /config>
Технологический журнал — специальный механизм платформы 1С 8.2 и 8.3, который позволяет протоколировать все события, происходящие в системе, в том числе системные ошибки. Рассмотрим инструкцию по настройке технологического журнала в 1С: Предприятии.
Файл logcfg.xml изнутри должен выглядеть примерно так:
Получите 267 видеоуроков по 1С бесплатно:
| ALL | Все события | Абсолютно все события технологического журнала |
| ADMIN | Административное действие | Действия пользователя-администратора |
| CALL | Входящий вызов | Входящий удаленный вызов (удаленный вызов на стороне приемника вызова) |
| CONN | Соединение с сервером | Установка или разрыв TCP-соединения между процессами системы «1С 8.3» |
| CLSTR | Активность кластера | Выполнение операций, изменяющих работу кластера серверов |
| EDS | Внешний источник данных | Все события внешних источников данных |
| DB2 | IBM DB2 | Исполнение операторов SQL СУБД IBM DB2 |
| DBMSSQL | Microsoft SQL Server | Исполнение операторов SQL СУБД Microsoft SQL Server |
| DBPOSTGRS | PostgreSQL | Исполнение операторов SQL СУБД PostgreSQL |
| DBORACLE | Oracle Database | Исполнение операторов SQL СУБД Oracle Database |
| DBV8DBEng | SQL, Файловая СУБД | Исполнение операторов SQL файловой СУБД |
| EXCP | Исключение | Исключительная ситуация приложения системы «1С: Предприятие», которое штатно не обрабатывается и может послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса |
| EXCPCNTX | Контекст исключения | Событие, которые началось, но не закончилось в момент возникновения нештатной ситуации |
| HASP | Обращение к HASP | Обращение к аппаратному ключу защиты () |
| LEAKS | Утечка памяти | Событие, связанное с утечкой памяти, которая может быть вызвана ошибками в коде конфигурации 1С 8.2 |
| MEM | Утечка памяти сервера | Событие, связанные с увеличением объема памяти, занятой серверными процессами (ragent, rmngr, ). |
| PROC | Процесс | Событие, относящееся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например: старт, завершение, аварийное завершение и т. п. |
| QERR | Ошибка запроса | Событие, связанное с обнаружением ошибок компиляции запроса или ограничением на уровне записей и полей базы данных |
| SCALL | Исходящий вызов | Исходящий удаленный вызов (исходящий вызов на стороне источника вызова). |
| SCOM | Серверный контекст | Событие создания или удаления серверного контекста, обычно связанного с информационной базой. |
| SDBL | Запрос к базе данных | Исполнение запросов к модели базы данных 1С: Предприятия 8.3 |
| SESN | Сеанс | Действие, относящиеся к сеансу работы. Например: начало сеанса, окончание сеанса и т. д. |
| SRVC | Сервисы кластера | События, связанные с запуском, остановкой и оповещениями сервисов кластера серверов |
| TLOCK | Блокировка | Управление транзакционными блокировками в Управляемом режиме |
| TDEADLOCK | Обнаружена взаимоблокировка в Управляемом режиме | |
| TTIMEOUT | Таймаут | Превышено максимальное время ожидания транзакционной блокировки |
| VRSCACHE | Кеш http | Работа кеша серверных вызовов |
| VRSREQUEST | Запрос к серверу | Запрос к серверу за некоторым ресурсом |
| VRSRESPONSE | Ответ сервера | Ответ сервера |
| SYSTEM | Системные события | Системные события механизмов платформы, предназначенные для анализа сотрудниками фирмы «1С» |
