Как посмотреть логи 1С на сервере

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

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

Где физически находятся логи сервера 1С

Рабочий каталог кластера серверов 1С по умолчанию расположен в C:\Program Files\1cv8\<версия>\srvinfo на Windows или /opt/1cv8/x86_64/<версия> и каталоге, заданном при запуске агента, на Linux. Именно здесь сервер хранит служебные файлы кластера, список информационных баз и настройки.

Если при установке агент сервера запускался с параметром -d, рабочий каталог может находиться в другом месте. Точный путь виден в свойствах службы «Агент сервера 1С:Предприятия» в оснастке services.msc — в строке запуска исполняемого файла ragent.exe указан параметр -d "путь".

Внутри srvinfo расположена папка reg_1541 (номер зависит от порта кластера), где лежат файлы реестра кластера. Сами по себе эти файлы читать «в лоб» не нужно — для диагностики важнее технологический журнал, который по умолчанию пишется в подкаталог logs или в путь, заданный в конфигурационном файле.

Технологический журнал: включение через logcfg.xml

Технологический журнал — основной инструмент диагностики сервера 1С. Он фиксирует вызовы, запросы к СУБД, ошибки, таймауты, блокировки и аварийные завершения процессов. Включается он конфигурационным файлом logcfg.xml, который нужно разместить в каталоге conf рядом с исполняемыми файлами сервера (например, C:\Program Files\1cv8\<версия>\bin\conf).

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

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs" history="24">
    <event><eq property="name" value=""/></event>
    <property name="all"/>
  </log>
</config>

Здесь location — папка, куда будут писаться логи (создайте её заранее и дайте права на запись учётной записи службы сервера 1С), history — глубина хранения в часах. Запись всех событий без фильтра генерирует большой объём данных, поэтому для постоянной работы лучше сузить набор событий: например, оставить только EXCP (исключения), CLSTR (события кластера) и DBMSSQL или DBPOSTGRS (запросы к СУБД).

После создания или изменения logcfg.xml перезапуск службы не обязателен — сервер подхватывает конфигурацию автоматически в течение примерно минуты. Проверить, что журнал заработал, просто: в указанной папке должны появиться подкаталоги с именами процессов (rphost, rmngr, ragent) и файлы вида *.log с метками времени.

Как читать файлы технологического журнала

Каждая строка технологического журнала имеет формат «время-длительность,событие,процесс,свойства». Например, запись 45:12.345678-1500000,DBMSSQL,2,process=rphost,... означает запрос к MS SQL длительностью 1,5 секунды. Длительные события — первый кандидат на анализ при жалобах на медленную работу.

Для поиска ошибок фильтруйте по событиям EXCP и EXCPCNTX — это исключения и их контекст. Событие TDEADLOCK указывает на взаимоблокировку, PROC и CLSTR — на состояние процессов кластера. В каждом событии есть поля с именем пользователя, сеанса, имени базы и текста запроса или ошибки.

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

Журнал регистрации информационной базы

Журнал регистрации — это лог прикладного уровня: входы пользователей, изменения данных, ошибки выполнения кода, фоновые задания. В клиент-серверном режиме он хранится в подкаталоге информационной базы внутри srvinfo: путь выглядит как srvinfo\reg_1541\<GUID базы>\1Cv8Log. GUID базы можно узнать в консоли кластера, посмотрев свойства информационной базы.

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

Файловый вариант чтения — открыть каталог 1Cv8Log напрямую: журнал хранится в формате SQLite (файл 1Cv8.lgd) в новых версиях платформы или в текстовом формате lgp в старых. Прямое чтение файлов пригодно для архивных копий, но при работающей базе корректнее пользоваться конфигуратором или выгрузкой журнала.

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

Если сервер 1С завершается аварийно, первым делом смотрите журнал Windows: «Просмотр событий» → «Журналы Windows» → «Система» и «Приложение». Ошибки службы агента сервера 1С, нехватка памяти и сбои драйверов фиксируются именно там. На Linux используйте journalctl -u srv1cv8 или аналогичную команду для службы агента.

Со стороны СУБД источники различаются. MS SQL Server пишет журнал ошибок ERRORLOG в каталоге экземпляра и события в Windows Event Log; полезны также представления динамического управления для анализа текущих блокировок. PostgreSQL ведёт лог в каталоге, заданном параметром log_directory, и уровень детализации регулируется параметрами log_min_duration_statement и log_lock_waits.

Сопоставление по времени — ключевой приём: если в техножурнале 1С виден разрыв соединения с СУБД, а в логе PostgreSQL в ту же секунду зафиксирован restart или out of memory, причина находится на стороне СУБД, а не платформы.

Типичные ошибки и ограничения

Самая частая ошибка — разместить logcfg.xml не в тот каталог. Файл должен лежать в bin\conf той версии платформы, под которой реально работает служба сервера. Если на сервере установлено несколько версий платформы, легко положить конфигурацию не туда и ждать логов, которых не будет.

Вторая ошибка — отсутствие прав у учётной записи службы (по умолчанию это может быть USR1CV8) на запись в папку логов. Сервер при этом не выдаёт видимой ошибки администратору — просто молча не пишет файлы. Проверяйте права явно.

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

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