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

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

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

Ниже разобрано, где физически находятся эти файлы в Windows и Linux, как их открыть и отфильтровать, как включить технологический журнал через logcfg.xml и как не заполнить диск избыточным логированием. Материал ориентирован на администраторов и внедренцев, работающих с клиент-серверным вариантом 1С:Предприятия.

Какие логи существуют в серверной 1С и что в них искать

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

• Журнал регистрации — встроенный механизм платформы. Фиксирует входы пользователей, изменение данных, ошибки выполнения кода, фоновые задания. Хранится внутри информационной базы (в клиент-серверном варианте — в таблицах СУБД или в формате SQLite в зависимости от настроек).
• Технологический журнал (ТЖ) — текстовые дампы событий кластера: вызовы, запросы SQL, блокировки, исключения, утечки памяти. По умолчанию отключён, включается конфигурационным файлом logcfg.xml.
• Логи кластера и агента сервера — служебные файлы в каталоге srvinfo: список баз, сеансы, регистрация рабочих процессов.
• Журналы СУБД — error log MS SQL Server, журнал PostgreSQL, alert log Oracle. Нужны, когда ошибка возникает на стороне базы данных.
• Системные журналы ОС — Event Viewer в Windows, journalctl/syslog в Linux. Фиксируют падения службы агента сервера 1С.

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

Журнал регистрации: как открыть и отфильтровать события

Журнал регистрации доступен без остановки сервера и не требует дополнительной настройки. Открыть его можно двумя способами: из пользовательского режима и из конфигуратора.

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

Журнал почти всегда содержит тысячи записей, поэтому без фильтра он бесполезен. Нажмите кнопку «Отбор» и задайте условия: период (обычно достаточно интервала вокруг момента ошибки), пользователь, уровень важности «Ошибка», конкретное событие — например, «Данные. Ошибка выполнения» или «Сеанс. Ошибка СУБД».

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

1. 1
   Откройте журнал регистрации из конфигуратора или раздела «Администрирование»
2. 2
   Нажмите «Отбор» и укажите период вокруг момента сбоя с запасом 5–10 минут
3. 3
   Добавьте условие по уровню «Ошибка» и, если известно, по пользователю
4. 4
   Откройте найденную запись и выпишите время, номер сеанса и текст ошибки
5. 5
   Используйте эти данные для поиска связанных событий в технологическом журнале и логах СУБД

Где физически лежат логи сервера 1С в Windows и Linux

Файлы кластера и служебные журналы хранятся в каталоге srvinfo. Его расположение зависит от операционной системы и параметров запуска агента сервера.

В Windows по умолчанию это C:\Program Files\1cv8\srvinfo (или C:\Program Files\1cv8\<версия>\... рядом с каталогом установки). Внутри находятся папки вида reg_1541 — по одной на каждый кластер, где 1541 — порт кластера. Там лежат файлы списка баз, сеансов, а также подкаталоги технологического журнала, если он включён.

В Linux каталог задаётся параметром -d при запуске агента (ragent). Часто встречаются пути /opt/1cv8/x86_64/<версия>/srvinfo или каталог в домашней папке служебного пользователя: /home/usr1cv8/.1cv8/1C/1cv8/. Точный путь проще всего узнать из командной строки запущенного процесса.

ps aux | grep ragent   # в выводе ищите параметр -d — это каталог srvinfo

Обратите внимание: если технологический журнал не настроен, в srvinfo вы найдёте только служебные файлы кластера (1CV8Clst.lst, файлы сеансов), а подробных логов ошибок там не будет. Это нормально — ТЖ включается отдельно.

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

Технологический журнал управляется файлом logcfg.xml, который нужно положить в каталог conf рядом с исполняемыми файлами сервера: в Windows это C:\Program Files\1cv8\<версия>\bin\conf\, в Linux — /opt/1cv8/x86_64/<версия>/conf/. Тот же файл можно разместить на клиентских машинах для сбора клиентских событий.

Минимальная конфигурация для записи ошибок и аварийных завершений выглядит так:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs" history="72">
    <event><eq property="name" value="EXCP"/></event>
    <event><eq property="name" value="CLSTR"/></event>
    <property name="all"/>
  </log>
  <dump location="D:\1clogs\dumps" create="1" type="3"/>
</config>

Параметр history задаёт срок хранения логов в часах — в примере 72 часа. Событие EXCP фиксирует исключения, CLSTR — события кластера. Для диагностики блокировок добавляют события TLOCK, TDEADLOCK, TTIMEOUT, для анализа медленных запросов — DBMSSQL или DBPOSTGRS с ограничением по длительности.

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

Как читать технологический журнал и связать его с ошибкой пользователя

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

Алгоритм поиска конкретной проблемы выглядит так. Из журнала регистрации берём точное время ошибки и номер сеанса. Открываем файл ТЖ за соответствующий час в каталоге процесса rphost и ищем по временной метке или по имени пользователя (свойство Usr) либо по фрагменту текста ошибки. Рядом с найденным событием EXCP обычно находятся события DBMSSQL с текстом запроса к СУБД и, при блокировках, события TLOCK с указанием ресурса и конкурирующего соединения.

Полезные точки входа при поиске по файлам: EXCP — любые исключения, Deadlock — взаимоблокировки, DBMSSQL с большой длительностью (первое число после времени — длительность в микросекундах) — медленные запросы. В Linux удобно использовать grep, в Windows — PowerShell или любой редактор с поиском по большим файлам.

grep -n "EXCP" /var/log/1c/rphost_*/24051312.log | head -50   # ошибки за час 12:00–13:00

Логи СУБД и операционной системы: когда их смотреть

Если в журнале регистрации и ТЖ видны ошибки вида «Ошибка СУБД», «соединение с сервером разорвано» или рабочий процесс rphost аварийно завершается, следующий шаг — журналы базы данных и ОС.

В MS SQL Server откройте SQL Server Management Studio: Management → SQL Server Logs. Там видны ошибки соединений, нехватки памяти, повреждения страниц данных. В PostgreSQL логи обычно находятся в каталоге log внутри каталога данных кластера (путь задаётся параметром log_directory в postgresql.conf); ищите строки с уровнями ERROR и FATAL в момент сбоя.

В Windows события падения службы агента сервера 1С фиксируются в Event Viewer: «Журналы Windows → Система» и «Приложение». Ищите события с источником Application Error или службой «Агент сервера 1С:Предприятия». В Linux используйте journalctl -u srv1cv8* или просмотр /var/log/messages.

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

Первая и самая частая проблема — технологический журнал «не пишется». Причины почти всегда одни и те же: logcfg.xml положен не в тот каталог conf (проверьте версию платформы, под которой реально запущен сервер), XML содержит синтаксическую ошибку, или у служебной учётной записи (USR1CV8 по умолчанию) нет прав на запись в каталог логов.

Вторая ошибка — включение слишком широкого сбора «на всякий случай» и забвение. Логи с событиями DBMSSQL без ограничений растут очень быстро, диск заполняется, и кластер останавливается с ошибкой, которую администратор потом ищет в тех же логах. Всегда задавайте параметр history и по возможности фильтруйте события.

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

Как проверить, что диагностика настроена правильно

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

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

Частые вопросы о логах сервера 1С