Logcfg xml куда положить

Logcfg xml куда положить

файл: C:\Program Files (x86)\1cv82\8.2.14.528\bin\conf\logcfg.xml

в каталоге пусто — что не так?

каталог существует? Прав хватает?
пусто в каталоге c:\v82\logs
существует, праа даны все пользователям домена
а от какой учетной записи запущен сервер предприятия? вы же это на сервере делаете?
нет не на сервере — на клиенте
locanion заменил на location — не помогает
сервер запущен под моей же учеткой
ни каких мыслей?
дайте хть 100% рабочий файл настройки . и куда его положить?
для клиент-серверной версии

Кaк может человек ожидaть, что его мольбaм о снисхождении ответит тот, кто превыше, когдa сaм он откaзывaет в милосердии тем, кто ниже его? Петр Трубецкой

Logcfg xml куда положить

Делал обновление. Нединамическое. выгнал всех пользователей. Но есть предположение , что кто-то вошел во время обновления. Система рухнула. Зашел на сервак под админскими правами. Служба rphost не запускается, ошибка 1053 служба не ответила на запрос своевременно. Что делать?

зы сервак перезагружал. не помогло
переустанови
В защищенном режиме попробуй войди.
Есть предположение, что фоновые задания не отключил.
Платформу переустанавливал? Другие базы запускаются?
Фрамеворки переустанавливал?
logcfg.xml положить в папку conf и читать получившиеся логи.

для базы запрети регламентные задания, после сделай рестатр сервера 1с, после запусти конфигуратор с ключем командной строки /ClearCache

(11)+ кстати откат транзакции может быть длительным, у меня в практике был откат в 45 минут.

после описаного может просто подождать стоит, для понимания — смотри чего делает скуль

(12) я как-то два часа бамбук курил в ожидании ролбэка
(11)
(12)
сделать это при остановленном rphost-е не удастся
(14) вполне удастя
(15) без конкретики это не разговор
(15) с тобой всё в порядке ?
(17) rphost — это рабочий процесс, консоль кластера без рабочих процессов нормально работет

(18) и чо ты ей без рабочего процесса с базой сделаешь? У автора не просто один процесс из кластера не стартует, а вообще весь кластер воронкой к верху лежит

(18)+ и конфигуратор то-же без рхостов работает

(19) как вариант очистки серверного кеша и установки блокировки — удалить файлы настройки сервера, перезапустить службу и создать заного подключение к базе (ID будет другой, кеш другой, и при пеодключении сразу указать запрет рег)

(21)+ но вариант с пересозданием чреват потерей журнала и как следствием платформа может не знать на чем ее прервали, по этому — это крайняк.

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

(22) журнал можно предварительно засолить и сложить потом, куда надо

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

и vde69 — будь на линии пожалуйста завтра если не сложно..

у меня только два вопроса:
1. есть ли бэкап
2. тестировалось ли обновление перед накатыванием на рабочую базу
3. как так получается что пользователи могут зайти в базу когда они не должны?

(26) так это ж три вопроса =)

(26) я наверно ерунду скажу, но должна ж быть какая-то «защита от дурака». А именно. До момента обновления БД вход пользователей влиять не должен. После начала обновления БД — база должна блокироваться монопольно. Это еще в 7ке реализовано.

Посмотри у тебя файлы с настройками кластера не блокированы каким-нибудь пользователем? Можно какой-нибудь программой типа Process Exploer их разблокировать. При аварийной остановке часто именно это проихсодит.

(28) если ты хочешь нормальную программу, то что ты делаешь в 1с? 🙂

(0) Попробуй сделать тестироание средствами SQL . а так быкапы надо делать . кстати SQL не глупый, мне помогло в похожей ситуации

Не могу молчать — Пипнул на кнопку Закладка

(26) Бэкапа да, не было((

Версия про фоновое задание — очень может быть. Хотя оно должно было пройти в 18, а я обновлялся в 18.04.

Но все слава Богу нормально. Переставил 1с-ку полностью, в консоли кластера переподключил базы. Зашел в программу со воего компа как обычным способом, так и через ярлык (скрипт).

Вроде в понедельник юзеры должны заработать.

Только вот журнал регистрации накрылся(( С этим ничего нельзя сделать?

ищи тут по идентификатору «поломанной» базы
(33) C:/Documents and Settings/All Users/Application Data/1C/1Cv8//1Cv8.log.

Записки IT специалиста

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

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

Что такое технологический журнал? Это собственный формат логов 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 Руководства администратора (та самая толстая желтая книжка, которую никто не читает).

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

Это позволит фиксировать события обращения к ключам защиты в том виде, в котором они фиксируются системой защиты 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='src\ServerAgentImpl.cpp(697):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=W81-TEST descr=11001(0x00002AF9): Этот хост неизвестен. line=1102 file=src\DataExchangeCommon.cpp'
25:35.876000-0,EXCP,1,process=ragent,ClientID=0,Exception=NetDataExchangeException,Descr='server_addr=W81-TEST descr=11001(0x00002AF9): Этот хост неизвестен. line=1102 file=src\DataExchangeCommon.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 следующим образом:

Затем создадим папку для логов 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С (ragent, rmngr или rphost) Дамп фиксируется в каталоге %LOCALAPPDATA%\1C\1Cv82\dumps — для 1С 8.2 %LOCALAPPDATA%\1C\1Cv8\dumps — для 1С 8.3 Если используется платформа 8.3 и возникает событие SYSTEM с уровнем Error Логи таких событий хранятся 24 часа, затем платформе удалит файлы логов %LOCALAPPDATA%\1C\1Cv8\logs — для 1С 8.3

Инструкция по настройке технологического журнала

• Завести специальную папку для технологического журнала (например C:\LOG), и для дампов (например C:\dumps)
• Настроить файл logcfg.xml для сбора сообщений об ошибках (ниже примеры настройки)
• Поместить файл logcfg.xml в необходимый каталог (ниже пример)
• Проверить права на запись в каталоги логов и дампов
• Убедиться через минуту что создаются файлы логов (если не создаются, значит настройки не корректны)
• Возможная ошибка — разный регистр букв в именах каталогов (должен совпадать)
• Возможная ошибка — в файле настройки в конце имени каталога слеш «\» не нужен

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

Отметим, что наиболее часто используемым каталогом расположения конфигурационного файла, является C:\Program Files\1Cv82\conf — для платформы 8.2 C:\Program Files\1Cv8\conf — для платформы 8.3 В этом случае настройки будут действовать во всех версиях платформы установленных на сервере. Также стоит сказать, что именно этот вариант является рекомендуемым.
Каждые 60 секунд, настройки считываются рабочими процессами кластера. Чтение настроек каждым процессом, происходит независимо от других процессов.

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

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

Пример настройки «на каждый день»

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

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

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

Далеко не все специалисты о нем знают, а умеют грамотно использовать лишь немногие. Попытаемся исправить ситуацию:)

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

Что Вы узнаете из этой статьи?

• Описание и предназначение инструмента Технологический журнал
• Как включить Технологический журнал в 1С:Предприятие 8
• Принцип формирования и сохранения логов и дампов

Описание ТЖ

ТЖ предназначен для расследования ошибок, анализа и диагностики различных проблем в работе платформы 1С:Предприятие .

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

Все инструменты анализа производительности платформы используют ТЖ для получения информации. При желании и доскональном изучении вопроса с помощью ТЖ вы можете написать свой инструмент анализа производительности.

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

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

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

Логи – это файлы с расширением .log , где информация хранится в текстовом виде.

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

Включение ТЖ

По умолчанию технологический журнал включен и работает, но собирает очень ограниченный объем данных.

Под минимальным объемом данных подразумеваются 2 вещи:

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

По умолчанию дамп создается в каталоге:

%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\dumps

Если вы используете Windows Vista и выше, то будет использоваться каталог:

Для 8.3 вместо каталога 1Cv82 используется 1Cv8 .

2) Для 8.3 в минимальный ТЖ входит формирование логов с одним событием SYSTEM с уровнем Error .

Логи сохраняются в каталоге:

%USERPROFILE%\Local Settings\Application Data\1C\1Cv8\logs

Для Windows Vista и старше используется каталог:

Данные логи по умолчанию будут хранится 24 часа, после чего платформа будет удалять файлы логов, которые превышают этот порог.

Чаще всего информации из ТЖ по умолчанию недостаточно, и необходимо его настраивать вручную.

Чтобы произвести тонкую настройку ТЖ, необходимо создать файл logcfg.xml с определенной структурой в определенном месте.

Данный файл необходимо разместить в каталоге:

C:\Program Files\1Cv82\conf (для 8.3 каталог 1Cv8)

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

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

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

Чтобы настроить ТЖ только для одной версии платформы, размещаем logcfg.xml в каталоге:

Где 8.2.19.106 – это номер нужной вам версии.

Крайне редко, но все же, может возникнуть необходимость настроить ТЖ отдельно для каждого пользователя, под которым запущена служба сервера 1С .

Тогда размещаем logcfg в каталоге:

%USERPROFILE%\Local Settings\Application Data\1C\1Cv82\Conf

Для ОС Windows Vista и старше:

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

Настройки из logcfg считываются не моментально, а каждые 60 секунд, причем каждый из процессов кластера считывает файл настроек независимо от других процессов. Например, сначала могут появиться логи процесса rmngr и только через 45 секунды логи rphost.

Для выключения ТЖ достаточно удалить или переименовать файл logcfg.xml .

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

В следующих статьях рассмотрим нюансы настройки ТЖ и практику использования.

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

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

Инструкция по настройке технологического журнала

1. Завести на локальных дисках серверов приложений 1С специальную папку для технологического журнала. Например, C:\LOG . И для дампов, например, C:\dumps.
2. Настроить журнал на сбор сообщений об ошибках (см. файл ) в подкаталог этого каталога. Подкаталог будем называть по дате: C:\LOG\2014-04-22 и т.д.
3. Сам файл logcfg.xml надо положить в каталог conf папки установки сервера (!) 1С: Предприятия (например, C:\Program Files\1cv82\8.2.17.153\bin\conf).
4. После этого примерно через минуту убедиться, что в каталоге создалась папка C:\LOG\2014-01-01, и в ней еще подпапки с именами rphost_XXXX, ragent_XXXX, rphost_XXXX, а в них файлики.
5. Если создались, то все нормально, если не создались, то что-то не так.
6. Если что-то не так: наиболее распространенные ошибки: большие/маленькие буквы в именах каталогов (регистр должен совпадать), в файле настройки написали слеш на конце имени каталога (не нужен), а еще иногда требуется донастроить права пользователей на папки C:\LOG, C:\dumps, C:\Program Files\1cv82\8.2.17.153\bin\conf, если они чересчур «закручены».

Файл logcfg.xml изнутри должен выглядеть примерно так:

Атрибуты для настройки журнала

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С»

(или часть, используя фильтр), например:
— исполняемый код 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.

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

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

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

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

В последнее время у всех сотовых операторов становится популярным.