Администрирование · 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Откройте журнал регистрации и отфильтруйте по пользователю и времени ошибки
- 2Скопируйте полный текст ошибки и контекст (данные, операция)
- 3Если причина неясна — создайте logcfg.xml с событиями EXCP и DBMSSQL
- 4Попросите пользователя повторить действие и соберите логи за этот интервал
- 5Проанализируйте события вокруг момента ошибки, отключите сбор
- 6При подозрении на инфраструктуру проверьте журналы ОС и СУБД
Типичные ошибки при работе с логами
Отдельная частая ситуация — администратор ищет логи файловой базы на своём компьютере, хотя база лежит на сетевом ресурсе. Журнал регистрации файловой базы всегда находится рядом с файлом базы, а технологический журнал пишется на той машине, где работает процесс платформы, — для файлового режима это компьютер пользователя.
Проверка результата и ограничения
Как проверить, что логи пишутся
В каталоге из 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. Включайте сбор точечно, ограничивайте объём и перед любыми операциями с журналами делайте резервные копии.