К статье
Практический материал

Администрирование · 11 мин

Где найти логи 1С: все источники и пути к файлам

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

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

Журнал регистрации фиксирует действия пользователей и ошибки прикладного уровня — это первое место, куда стоит заглянуть при жалобах «не проводится документ» или «кто изменил данные». Технологический журнал нужен для диагностики производительности, взаимоблокировок и аварийных завершений — он пишется на уровне платформы и по умолчанию отключён. Логи сервера 1С и СУБД раскрывают проблемы инфраструктуры: разрывы соединений, нехватку ресурсов, ошибки на стороне базы данных.

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

Журнал регистрации: главный прикладной лог

Журнал регистрации — встроенный механизм платформы, который фиксирует действия пользователей, ошибки выполнения кода, изменения данных и системные события. Он включён по умолчанию и не требует настройки для базовой работы. Открыть его можно двумя способами: в конфигураторе через меню «Администрирование → Журнал регистрации» или в режиме «1С:Предприятие» через «Администрирование → Обслуживание → Журнал регистрации» (точный путь зависит от конфигурации).

Физически журнал хранится в каталоге информационной базы. Для файловой базы это подкаталог 1Cv8Log рядом с файлом 1Cv8.1CD. Для клиент-серверной базы журнал хранится на сервере 1С в каталоге служебных файлов базы внутри srvinfo. Напрямую открывать эти файлы сторонними средствами не стоит — работайте с журналом через штатный интерфейс платформы.

В журнале доступен отбор по периоду, пользователю, уровню важности (ошибки, предупреждения, информация), типу события и конкретным данным. Это позволяет быстро ответить на вопросы «кто удалил документ», «когда меняли проводки», «какая ошибка возникла у пользователя утром».

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

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

Файл logcfg.xml размещается в каталоге conf каталога установки платформы (например, C:\Program Files\1cv8\<версия>\bin\conf) либо в каталоге conf внутри каталога служебных данных. Для сервера на Linux путь обычно выглядит как /opt/1cv8/<архитектура>/<версия>/conf. В файле задаются события, которые нужно писать, и каталог размещения логов через элемент <log location="..."/>.

Минимальный пример для записи всех событий в течение часа:

<config xmlns="http://v8.1c.ru/v8/tech-log">

<log location="C:\1clogs" history="1">

<event><eq property="name" value=""/></event>

<property name="all"/>

</log>

</config>

Параметр history задаёт глубину хранения в часах — без ограничения файлы быстро заполнят диск. После создания файла перезапуск служб не требуется: платформа подхватывает конфигурацию автоматически, обычно в течение минуты.

Ключевые события технологического журнала

Чтобы не тонуть в данных, включайте точечно те события, которые соответствуют вашей проблеме. Ниже — самые востребованные.

СобытиеЧто фиксируетКогда включать
EXCPАварийные ситуации и исключения платформыПадения, внезапные завершения сеансов
DBMSSQL / DBPOSTGRS / DBORACLEЗапросы к СУБД с текстом и длительностьюМедленная работа, поиск тяжёлых запросов
TLOCK, TDEADLOCK, TTIMEOUTУправляемые блокировки, взаимоблокировки, таймаутыОшибки «Конфликт блокировок», зависания
CONNУстановка и разрыв соединенийОбрывы связи клиента с сервером
CALL, SCALLВызовы на клиенте и сервереАнализ сетевого обмена и «пингов»
PROCСобытия процесса платформыОбщий контроль работы rphost

Для анализа длительности событий добавьте в конфигурацию свойство <property name="duration"/> — тогда в лог попадёт время выполнения каждого события, и можно отфильтровать только долгие операции. Разбор больших файлов ТЖ удобнее делать специализированными инструментами (например, парсерами технологического журнала), а не вручную.

Логи сервера 1С и агента кластера

Если используется клиент-серверный вариант, отдельный пласт диагностических данных пишет сам кластер серверов 1С. Рабочий каталог сервера по умолчанию — C:\Program Files\1cv8\srvinfo в Windows или /home/usr1cv8/.1cv8/1C/1cv8 (либо каталог, указанный при запуске агента) в Linux. Внутри находятся подкаталоги вида reg_1541 — по одному на каждый кластер.

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

Дополнительно события агента сервера попадают в системный журнал операционной системы: «Просмотр событий → Журналы Windows → Приложение» в Windows (источник — агент сервера 1С) и syslog/journald в Linux. Именно там видны ошибки старта службы, падения рабочих процессов rphost и проблемы с портами.

Ошибка у пользователя в документеЖурнал регистрации

Отбор по пользователю и периоду, уровень «Ошибка»

Медленно работает базаТехнологический журнал

События DBMSSQL/DBPOSTGRS с duration

Конфликт блокировокТехнологический журнал

События TLOCK и TDEADLOCK

Сервер не стартуетСистемный журнал ОС

Журнал «Приложение» или journalctl -u srv1cv8

Логи СУБД и операционной системы

Часть проблем клиент-серверной 1С видна только на стороне СУБД. Для MS SQL Server полезны журнал ошибок (SQL Server Error Log, открывается из Management Studio в разделе «Управление → Журналы SQL Server») и системные представления динамического управления (DMV). В PostgreSQL логи пишутся в каталог, заданный параметром log_directory (обычно log внутри каталога данных), а детализация настраивается через log_min_duration_statement для поиска медленных запросов.

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

При разборе инцидента всегда сверяйте время во всех источниках: журнал регистрации, ТЖ, лог СУБД и журнал ОС. Если часы на серверах расходятся, сопоставить события почти невозможно — настройте синхронизацию времени по NTP заранее.
ПЗ
Практическое замечание

Порядок поиска при типовой проблеме

Чтобы не проверять всё подряд, двигайтесь от прикладного уровня к инфраструктурному. Сначала журнал регистрации — он даст текст ошибки, пользователя и время. Затем, если ошибка неочевидна, включите точечный сбор в технологическом журнале на период воспроизведения проблемы. И только если платформа и СУБД «чисты», спускайтесь к журналам ОС и оборудования.

Порядок действий при ошибке пользователя
  1. 1
    Откройте журнал регистрации и отфильтруйте по пользователю и времени ошибки
  2. 2
    Скопируйте полный текст ошибки и контекст (данные, операция)
  3. 3
    Если причина неясна — создайте logcfg.xml с событиями EXCP и DBMSSQL
  4. 4
    Попросите пользователя повторить действие и соберите логи за этот интервал
  5. 5
    Проанализируйте события вокруг момента ошибки, отключите сбор
  6. 6
    При подозрении на инфраструктуру проверьте журналы ОС и СУБД

Типичные ошибки при работе с логами

Типичные ошибки
01
Включение полного ТЖ на продуктиве без ограничения history — диск заполняется, сервер встаёт
02
Размещение каталога логов на системном диске — при переполнении страдает вся ОС, выносите логи на отдельный том
03
Поиск ошибки только в журнале регистрации — инфраструктурные сбои там не видны, нужен ТЖ или журнал ОС
04
Ручное редактирование файлов srvinfo — приводит к повреждению реестра кластера, работайте через консоль кластера
05
Игнорирование ротации логов СУБД — журналы PostgreSQL или SQL Server тоже растут и требуют контроля

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

Проверка результата и ограничения

Контрольные точки

Как проверить, что логи пишутся

Технологический журнал
Норма

В каталоге из logcfg.xml появились подкаталоги с файлами .log

Тревожный признак

Каталог пуст — проверьте путь, права записи и синтаксис XML

Журнал регистрации
Норма

Новые действия пользователей появляются в отборе

Тревожный признак

Записей нет — проверьте, не сокращён ли журнал и тот ли это период

Системный журнал
Норма

Есть записи от источника агента сервера 1С

Тревожный признак

Записей нет — служба могла не стартовать, проверьте её состояние

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

Частые вопросы

Где лежит журнал регистрации файловой базы 1С?

В подкаталоге 1Cv8Log внутри каталога информационной базы, рядом с файлом 1Cv8.1CD. Открывать его следует не напрямую, а через конфигуратор или режим «1С:Предприятие» — там доступны отборы и поиск.

Нужно ли перезапускать сервер после создания logcfg.xml?

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

Почему технологический журнал быстро заполняет диск?

При включении всех событий на нагруженной системе объём данных достигает гигабайт в час. Ограничивайте набор событий только нужными (EXCP, DBMSSQL, TDEADLOCK), задавайте параметр history и выделяйте под логи отдельный диск с контролем свободного места.

Где смотреть причину падения рабочего процесса rphost?

Начните с системного журнала ОС: «Просмотр событий → Приложение» в Windows или journalctl в Linux. Затем включите в технологическом журнале события EXCP и PROC — они покажут аварийную ситуацию, предшествовавшую падению, и дампы процесса, если они настроены.

Можно ли узнать, кто удалил документ, если журнал регистрации сократили?

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

Пишутся ли логи при работе через веб-сервер?

Да. Журнал регистрации и технологический журнал работают независимо от способа подключения. Дополнительно полезны логи самого веб-сервера (IIS или Apache) — там видны ошибки публикации, таймауты и отказы в доступе, которых нет в журналах 1С.

Итог

Что важно запомнить

Прикладные ошибки и действия пользователей ищите в журнале регистрации, проблемы производительности и блокировок — в технологическом журнале через logcfg.xml, сбои сервера — в системном журнале ОС и каталоге srvinfo. Включайте сбор точечно, ограничивайте объём и перед любыми операциями с журналами делайте резервные копии.