1с настройка технологического журнала
Обновлено: 16.07.2024
Если программа ведет себя неправильно, то первым делом следует смотреть логи. 1С:Предприятие не исключение, однако, в отличие от большинства иных программ, использующих для этого системные инструменты, 1С реализовали собственный механизм, названный технологическим журналом. Он позволяет достаточно гибко настраивать собираемую информацию и способен удовлетворить различные категории пользователей: от администраторов до разработчиков.
Что такое технологический журнал? Это собственный формат логов 1С собирающий всю информацию о работе установленных на данном ПК приложениях 1С:Предприятие. По умолчанию технологический журнал настроен на сохранение минимальных дампов, возникающих при аварийном завершении программы.
Однако, давайте честно, многие из читающих данную статью имеют знания и опыт чтобы работать с дампами? А те, кто все-таки умеют это делать, будут этим заниматься? Нет, так как практического смысла в этом немного. Процитирую В. Гилева:
В дампах могут разобраться только разработчики платформы! (только у них исходники :) )
Поэтому сразу забываем о дампах и сосредотачиваемся на гораздо более простых и понятных вещах - логах. Для чтения логов не нужно иметь специфических знаний, достаточно просто инженерного опыта и общих представлений о работе операционной системы и непосредственно 1С:Предприятия.
Платформа Windows
Для включения и настройки технологического журнала в среде Windows необходимо в папке C:\Program Files (x86)\1cv8\conf создать специальный файл настроек logcfg.xml. В самом простейшем случае он может выглядеть так:
Разберем структуру файла подробнее:
- log location - расположение файлов лога, указанная директория должна существовать, и пользователь от имени которого запускается 1С должен иметь право записи в нее.
- history - время хранения логов в часах, в нашем примере 168 часов равно 7 суткам или неделе.
- event - таких секций может быть много, соответствуют фиксируемым событиям. В данном случае фиксируются все события.
- property - определяет попадание в журнал свойств событий. Конструкция property name="all" включает записи в журнал всех свойств событий.
Данная настройка может подойти для клиентского приложения, однако попытка использовать ее на сервере приведет к резкому раздуванию логов и падению производительности системы.
Внимание! 1С категорически не рекомендует включать подобный тип журнала на рабочих серверах!
Поэтому настроим журнал на получение только нужной нам информации. Существуют разные варианты настройки технологического журнала, в зависимости от того, какие именно события нас интересуют. В первую очередь это нештатное поведение платформы, которое может быть связано с ошибками конфигурации или неправильной настройкой платформы. Фирма 1С рекомендует такую настройку журнала:
В данном примере фиксируются следующие события:
- PROC - события, относящиеся к процессу целиком и влияющие на дальнейшую работоспособность процесса. Например, старт, завершение, аварийное завершение и т.п.
- SCOM - события создания или удаления серверного контекста, обычно связанного с информационной базой.
- CONN - установка или разрыв клиентского соединения с сервером.
- EXCP - исключительные ситуации приложений системы 1С:Предприятие, которые штатно не обрабатываются и могут послужить причиной аварийного завершения серверного процесса или подсоединенного к нему клиентского процесса.
- ADMIN - управляющие воздействия администратора кластера серверов системы 1С:Предприятие.
- QERR - события, связанные с обнаружением ошибок компиляции запроса или ограничения на уровне записей и полей базы данных.
Этого набора вполне хватает, для разбора ошибок в повседневной деятельности администратора. С полным перечнем настроек технологического журнала с пояснениями и примерами можно ознакомиться в разделе 3.17 Руководства администратора (та самая толстая желтая книжка, которую никто не читает).
Для диагностики отдельных ситуаций можно применять и специфические настройки журнала. Если вы используете аппаратные ключи, то в случае возникновения проблем с ними примените следующую настройку журнала:
Итак, файл создан. Чтобы события начали фиксироваться в журнале необходимо запустить клиентское приложение или перезапустить службу сервера. После чего директория с логами примет примерно следующий вид:
Для каждого процесса создается отдельная папка с его именем и ID, каждая из которых содержит внутри текстовые файлы с именем формата ггммддчч, т.е. год-месяц-день-час, каждый час создается новый файл лога. Так, например, лог за 12 января 2016 года с 15 до 16 часов будет иметь имя 16011215.log, затем 16011216.log и т.д.
Для примера приведем участок лога:
Платформа Linux
Несмотря на то, что никаких отличий в настройке технологического журнала для разных платформ нет, в Linux имеются некоторые особенности, связанные с архитектурой системы и не всегда очевидные начинающим.
Прежде всего расположение файла настроек. Он должен находиться в /home/usr1cv8/.1cv8/1C/1cv8/conf, по умолчанию данная директория не существует и ее нужно будет создать. Также, если вы предпочитаете графические инструменты настройки, учтите, что директория .1cv8 скрытая (на это указывает точка в начале имени) и просто так в файловом менеджере вы ее не увидите.
Мы предпочитаем работу в консоли, как более привычную и удобную для данной платформы. Поэтому создадим данную директорию:
а в ней файл настроек:
После чего можно приступать к его редактированию, содержимое должно быть полностью идентичным Windows-версии, за исключением пути хранения логов. В файловой системе Linux они традиционно располагаются в /var/log и мы не рекомендуем отступать от традиций, потому, что если с данным сервером придется работать другому специалисту, то он будет искать логи именно там.
Изменим строку конфигурационного файла logcfg.xml следующим образом:
Затем создадим папку для логов 1С
А чтобы 1С могла писать туда, установим пользователя и группу 1С владельцем этого каталога:
Теперь перезапускаем процесс сервера 1С
и отмечаем создание в директории папок и файлов с логами.
Данная настройка будет вести технологический журнал сервера 1С, если вам нужно фиксировать события клиентского приложения, то следует выполнить ряд дополнительных действий.
Так как клиентская платформа работает от имени запустившего его пользователя, то файлы настройки платформы хранятся в домашнем каталоге этого пользователя. Если таких пользователей несколько, то у каждого из них будет свой вариант настроек. Структура каталогов при этом полностью повторяет серверную, что не удивительно, в случае с сервером настройки хранятся в каталоге служебного пользователя от имени которого работает сервер 1С.
Если посмотреть этот каталог, то увидим, что там кроме папки conf, присутствует также папка logs, в которой создаются папки для запущенных процессов, однако самих логов там нет.
Попытка использовать для записи логов эту папку не приведет к успеху, папки процессов будут создаваться, но логи появляться не будут. Можно, конечно, перенастроить место хранения логов на любую папку в домашней директории, но лучше продолжить использовать для этого /var/log/1C.
Чтобы запущенное от имени пользователя приложение могло писать в данную папку надо предоставить ему соответствующие права. Если вы единственный пользователь компьютера и серверной версии 1С у вас не установлено, то можно просто сделать текущего пользователя владельцем данной папки, если пользователей несколько, либо на этом же ПК стоит серверная часть и вы хотите включить журнал и для нее, то нужно настроить совместный доступ.
Прежде всего добавим нужных пользователей в группу 1С:
Затем изменим права на папку логов, чтобы писать в нее мог не только владелец, но и группа:
Для применения прав нужно завершить сеанс пользователя и войти заново, после этого можно запустить клиентское приложение и убедиться, что в каталоге /var/log/1C создаются нужные папки логов.
Коллеги, продолжаем серию статей, посвященных технологическому журналу.
Другие статьи из серии «Технологический журнал»:
Настройка технологического журнала
- Более подробно изучим файл настроек logcfg.xml
- Проведем тонкую настройку Технологического журнала
Как уже было сказано, для тонкой настройки ТЖ используется файл logcfg.xml, давайте подробно разберем структуру этого файла.
Например, мы разместили в каталоге «C:\Program Files\1Cv82\conf» файл logcfg.xml со следующим содержанием:
Давайте подробно рассмотрим каждую строку.
Определяет начало настроек ТЖ и указывает на пространство имен xml, эта строка всегда идет первой и остается неизменной по содержанию.
Определяет, что в случае аварийного завершения одного из процессов сервера 1С, необходимо создать дамп в каталоге «C:\1C_Info\Dumps».
Если атрибут create=»0″ или create=»false», то дамп не будет создан.
Атрибут «type» определяет, насколько полный дамп нужно создавать.
Значение «2», означает что в дамп будет записано содержимое всей памяти процесса. Рекомендую использовать именно его, т.к. для большинства случае этого достаточно. Можно поставить значение «0», тогда будет собран минимальный дамп, но для расследования содержащейся в нем информации может не хватить.
Для данного параметра возможен довольно большой перечень значений, подробнее о них можно почитать в руководстве администратора, но на практике другие значения почти никогда не используются.
Параметр «location» определяет, в какой каталог будет записан дамп.
Если элемента нет, то будут созданы минимальные дампы и сохранены в каталог для дампов по умолчанию (см. раздел «Включение ТЖ»)
Открывает раздел с настройками логов. Здесь настраивается каталог для хранения логов и время хранения в часах. В данном случае логи будут храниться только за последний час. Файлы логов старше указанного времени платформа удалит самостоятельно.
При выборе каталога надо учитывать, что там не должно быть ничего кроме файлов логов.
Открывает раздел для фильтрации и настройки тех событий, которые мы будем собирать в логах ТЖ.
Разделов также может быть несколько, по одному разделу на одно событие.
Определяет, какое именно событие мы будем фиксировать и в каком случае.
ne – это условие на не равенство (not equal), дословно строка читается так: если свойство события «Имя» не равно значению «», тогда записываем это событие в ТЖ.
А т.к. у любого события есть имя, то данное условие заведомо всегда будет выполняться, и мы будем фиксировать абсолютно все события технологического журнала.
Обычно такая настройка не используется, т.к. сбор полного технологического журнала будет замедлять работу системы, логи быстро займут все свободное место на диске, да и разобраться в гигабайтах текстовой информации потом будет непросто. Поэтому обычно используют фильтрацию по событиям, об этом мы поговорим чуть позже.
Закрывает раздел event. После этого можно начинать новый раздел если нужно фиксировать несколько событий.
Здесь мы определяем, какие свойства событий необходимо фиксировать. Обычно это значение остается по умолчанию в «all», т.е. записываем все свойства событий, которые определены в разделе <event>.
Закрывает раздел log. После этого можно начинать новый раздел <log>.
Определяет конец настроек ТЖ.
На первый взгляд такая структура может показаться сложной, но поверьте, это только на первый взгляд. На самом деле благодаря такому формату можно делать очень гибкие настройки, что очень облегчает работу по расследованию всяких непонятных ситуаций.
Бурмистров Андрей
В следующих статьях рассмотрим нюансы настройки логов ТЖ и практику их использования.
А пока закрепите полученный материал на своей тестовой информационной базе :)
PDF-версия статьи для участников группы ВКонтакте
Статья в PDF-формате
Вы можете скачать эту статью в формате PDF по следующей ссылке:
Если вы хотите узнать больше об оптимизации 1С и быть экспертом в этой области – пройдите наш новый курс «Оптимизация производительности 1С:Предприятие».
Коллеги, начинаем серию статей, посвященных технологическому журналу.
Другие статьи из серии «Технологический журнал»:
«ТЖ: Настройка»
«ТЖ: Анализ логов»
«ТЖ: События и фильтры»
Описание и включение технологического журнала
Что Вы узнаете из этой статьи?
- Описание и предназначение инструмента Технологический журнал
- Как включить Технологический журнал в 1С:Предприятие 8
- Принцип формирования и сохранения логов и дампов
Описание ТЖ
Технологический журнал (далее ТЖ) – это средство для логирования работы платформы на низком уровне.
ТЖ предназначен для расследования ошибок, анализа и диагностики различных проблем в работе платформы 1С:Предприятие.
С помощью ТЖ можно выяснить, какие запросы работают медленно и откуда они вызываются, при выполнении какого кода «падают» рабочие процессы сервера, куда «утекает» память и многое, многое другое.
Все инструменты анализа производительности платформы используют ТЖ для получения информации. При желании и доскональном изучении вопроса с помощью ТЖ вы можете написать свой инструмент анализа производительности.
ТЖ можно собирать как для процессов сервера 1С, так и для клиентских приложений. Соответственно, и набор событий, которые можно фиксировать в ТЖ, будет отличаться.
Клиентские логи и дампы крайне редко вызывают интерес, поэтому в статье мы будем рассматривать ТЖ исключительно с точки зрения сервера. Тем не менее все, что здесь написано, также подходит и для клиентских логов.
С помощью ТЖ можно собирать логи и настраивать формирование дампов в случае аварийного завершения работы процесса.
Логи – это файлы с расширением .log, где информация хранится в текстовом виде.
Включение ТЖ
По умолчанию технологический журнал включен и работает, но собирает очень ограниченный объем данных.
Под минимальным объемом данных подразумеваются 2 вещи:
1) Формирование дампов минимального размера в случае аварийного завершения работы процессов кластера 1С (ragent, rmngr или rphost).
По умолчанию дамп создается в каталоге:
Если вы используете Windows Vista и выше, то будет использоваться каталог:
Для 8.3 вместо каталога 1Cv82 используется 1Cv8.
2) Для 8.3 в минимальный ТЖ входит формирование логов с одним событием SYSTEM с уровнем Error.
Логи сохраняются в каталоге:
Для Windows Vista и старше используется каталог:
Данные логи по умолчанию будут хранится 24 часа, после чего платформа будет удалять файлы логов, которые превышают этот порог.
Чаще всего информации из ТЖ по умолчанию недостаточно, и необходимо его настраивать вручную.
Чтобы произвести тонкую настройку ТЖ, необходимо создать файл logcfg.xml с определенной структурой в определенном месте.
Данный файл необходимо разместить в каталоге:
В этом случае настройки ТЖ будут действовать для всех версий 1С, которые установлены на данном компьютере, и для всех пользователей. Этот вариант используется чаще всего, и именно его рекомендуем применять.
При настройках ЦУПа, облачных сервисов контроля производительности и прочих инструментов, где надо указывать путь к logcfg, также лучше использовать именно этот каталог, иначе при обновлении платформы или изменении имени пользователя, под которым запущена служба сервера 1С, описанные инструменты перестанут работать и придется менять настройку.
Тем не менее есть и другие варианты, хотя и используются они гораздо реже. Опишу лишь то, что с наибольшей вероятностью вам может понадобится.
Чтобы настроить ТЖ только для одной версии платформы, размещаем logcfg.xml в каталоге:
Где 8.2.19.106 – это номер нужной вам версии.
Крайне редко, но все же, может возникнуть необходимость настроить ТЖ отдельно для каждого пользователя, под которым запущена служба сервера 1С.
Тогда размещаем logcfg в каталоге:
Для ОС Windows Vista и старше:
Это может потребоваться, если у вас, например, 1 служба сервера 1С используется как рабочая, а вторая для отладки. При необходимости можно запустить службы под разными пользователями и собирать ТЖ только для одной из них, чтобы не загружать второй сервер и не собирать в логах лишние данные, либо сделать для каждой из служб свои настройки ТЖ.
Настройки из logcfg считываются не моментально, а каждые 60 секунд, причем каждый из процессов кластера считывает файл настроек независимо от других процессов. Например, сначала могут появиться логи процесса rmngr и только через 45 секунды логи rphost.
Для выключения ТЖ достаточно удалить или переименовать файл logcfg.xml.
Бурмистров Андрей
В следующих статьях рассмотрим нюансы настройки ТЖ и практику использования.
А пока закрепите полученный материал на своей тестовой информационной базе :)
PDF-версия статьи для участников группы ВКонтакте
Статья в PDF-формате
Вы можете скачать эту статью в формате PDF по следующей ссылке:
Если вы хотите узнать больше об оптимизации 1С и быть экспертом в этой области – пройдите наш новый курс «Оптимизация производительности 1С:Предприятие».
Комментарии / обсуждение (18):
2. Периодически появляется ошибка блокировки HRESULT=80040E31
На самом деле для расследования этой проблемы исследовать логи ТЖ вам не нужно. Это проблема ожидания на блокировках причем на уровне СУБД, а для ее исследования вам нужен инструмента анализа ожиданий на блокировках. Вы можете для этих целей использовать платный ЦУП (Центр управления производительностью) или бесплатный сервис анализа блокировок от Гилева. С помощью одного из этих инструментов вы сможете определить причину ожиданий и если есть нужные знания решить проблему.
В самом ТЖ вы лишь увидите текст ошибки по таймауту из-за блокировки, хотя этот текст проще вам будет посмотреть в журнале регистрации (если он конечно включен).
Благодарю за Ваш ответ!
Пожалуйста!
Интересного обучения!
Подскажите, можно ли отловить в ТЖ изменения настроек Журнала регистрации, например, отключение записи событий?
Специального такого события нет, но можно посмотреть что настройки ЖР были изменены, хотя и нельзя определить что именно там было изменено.
В случае измерения настроек в ТЖ будет вот такая строка:
Вы можете сделать фильтр на свойства t:applicationName=Designer и MName=changeLogMngrInfo
Наберусь наглости задать еще один вопрос по журналу регистрации.
Если в кластере два центральных сервера, то как идет запись в ЖР?
Если ничего не настраивать, то журналы регистрации для одной и той же ИБ на серверах разные? Или дублируются? Как сделать так, чтобы все писалось только в одну папку в служебном каталоге кластера одного из серверов? Если помощью требований назначения функциональности запретить одному серверу работать с журналом регистрации, то события будут писаться в папку другого сервера или вообще не будут для сеансов на данном сервере?
>Если в кластере два центральных сервера, то как идет запись в ЖР?
Если ничего не настраивать, то журналы регистрации для одной и той же ИБ на серверах разные?
Журнал пишется только на одном из серверов если ничего дополнительно не настравивать.
>Или дублируются?
Нет, журнал не дублируется.
>Как сделать так, чтобы все писалось только в одну папку в служебном каталоге кластера одного из серверов?
Для этого необходимо с помощью требований назначения функциональности перенести сервис ЖР на какой-то один сервер.
>Если помощью требований назначения функциональности запретить одному серверу работать с журналом регистрации, то события будут писаться в папку другого сервера или вообще не будут для сеансов на данном сервере?
Будут писаться в папку другого сервера.
Рекомендуется закрепить ЖР за каким-то одним из серверов, что бы не получилась нижеописанная ситуация.
Допустим с помощью требований назначения функциональности указано что одна база работает на отдельном сервере, другие на другом. В этом случае ЖР действий по этой базе будет вестись на отдельном сервере, ЖР по другим базам будет на другом сервере, и это нужно учитывать при резервном копировании. Так же возможна ситуация когда работы с отдельной базой или рег. заданием вынесли на отдельный сервер, а потом вернули обработно. Тогда всей действия в этой базе или в этом рег. задании которые были за период пока они выполнялись на отдельном сервере, будут только в ЖР на этом отдельном сервере. С другими серверами кластера эта информация не синхронизируется. Поэтому что бы не рисковать, рекомендуется сделаять явное указание где хранить ЖР, в таком случае ЖР всегда будет храниться в одном месте при любых условиях.
Коллеги, завершаем серию статей посвященных технологическому журналу.
Сегодня рассмотрим полезные примеры настройки тех. журнала.
Предыдущие статьи из серии «Технологический журнал»:
Примеры настройки и ошибки в технологическом журнале
- Посмотрим, как именно на практике можно применить технологический журнал
- Рассмотрим наиболее популярные ошибки
- Укажем как избежать подобных ошибок
При настройке ТЖ довольно легко допустить ошибку, при этом платформа никак об этом не сообщает, она просто перестает писать логи без объяснения причин.
Самый простой способ избежать примитивных ошибок, это открыть logcfg.xml в браузере перед тем как копировать в каталог config.
Рассмотрим наиболее популярные ошибки при настройке ТЖ:
1. Русские символы. Классика жанра — если в logcfg вы поставили русские символы в любом месте, кроме значений параметров, то ТЖ работать не будет.
2. Непечатаемые символы. Проблема может возникнуть если вы скопировали текст logcfg, а не набирали вручную.
3. Нарушена структура файла xml, например, где-то не закрыли тэг или поставили лишний пробел.
4. Неправильно указаны каталоги. В каталоге с логами не должно находится ничего кроме логов, иначе логи записаны не будут.
Например, неправильно указывать такую настройку:
Также неправильно будет указать 1 каталог для дампов и логов.
При возникновении дампа логи перестанут записываться, т.к. в каталоге с логами будет создан посторонний элемент.
5. Используется кодировка отличная от UTF-8. При использовании других кодировок возможны проблемы.
Технологический журнал крайне полезный инструмент для расследования проблем производительности и стабильности.
Надеюсь, что после прочтения статьи у вас не осталось вопросов по его использованию.
Бурмистров Андрей
PDF-версия статьи для участников группы ВКонтакте
Статья в PDF-формате
Вот и закончилась серия статей для ознакомления с инструментом 1С:Предприятие 8 — Технологическим журналом.
Надеемся вам было всё понятно, а если возникли вопросы пишите в комментариях :)
Если вы хотите узнать больше об оптимизации 1С и быть экспертом в этой области – пройдите наш новый курс «Оптимизация производительности 1С:Предприятие».
Читайте также: