Где находятся логи сервера 1С: подробное руководство

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

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

Каталог srvinfo — главное хранилище логов кластера

Каталог srvinfo (реестр кластера) создаётся при запуске агента сервера 1С. Именно здесь лежат служебные файлы кластера, журналы рабочих процессов, дампы и технологический журнал, если он включён. Путь к каталогу задаётся параметром -d при запуске агента; если параметр не указан, используется каталог по умолчанию.

В Windows при установке сервера как службы путь по умолчанию — C:\Program Files\1cv8\srvinfo (для 32-разрядной версии на 64-разрядной ОС — C:\Program Files (x86)\1cv8\srvinfo). Точный путь виден в строке запуска службы «Агент сервера 1С:Предприятия»: откройте services.msc, найдите службу, посмотрите свойства — в поле «Исполняемый файл» после параметра -d указан рабочий каталог.

В Linux агент обычно работает от пользователя usr1cv8, и каталог реестра располагается в /home/usr1cv8/.1cv8/1C/1cv8. Если при установке задан другой путь, его можно увидеть в скрипте запуска службы или в выводе команды ps aux | grep ragent — параметр -d покажет актуальное расположение.

1. 1
   Откройте services.msc и найдите службу «Агент сервера 1С:Предприятия»
2. 2
   Откройте свойства службы и скопируйте путь после параметра -d
3. 3
   Перейдите в этот каталог — внутри будут папки reg_1541, logs и другие
4. 4
   Проверьте подкаталоги reg_1541 и logs — там лежат файлы событий кластера

Что находится внутри srvinfo: структура каталогов

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

Диагностически полезные данные лежат в подкаталогах:

• logs — текстовые журналы событий кластера, если их запись включена;
• techlog (или каталог, заданный в logcfg.xml) — технологический журнал;
• dump — аварийные дампы процессов rphost при падениях;
• prof — файлы профилирования, если оно включено.

Учтите, что каталог srvinfo может активно расти: технологический журнал и дампы способны занять десятки гигабайт за несколько дней. Следите за свободным местом на диске, иначе переполнение приведёт к остановке кластера.

Технологический журнал: где лежит и как включить

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

Место записи логов задаётся в самом logcfg.xml атрибутом location элемента log. Если каталог не указать, журнал пишется в подкаталог logs рабочего каталога процесса. Пример минимальной конфигурации для записи всех событий:

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

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

# Linux: найти, куда пишет технологический журнал
grep -r "location" /opt/1cv8/x86_64/*/conf/logcfg.xml
# Проверить свежие файлы ТЖ
ls -lt /var/1clogs | head

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

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

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

В клиент-серверном варианте журнал регистрации хранится в таблицах СУБД (например, в MS SQL это таблица EventLog внутри базы). Напрямую из таблиц его читают редко — удобнее открыть журнал через конфигуратор (Администрирование → Журнал регистрации) с фильтрами по пользователю, периоду и уровню важности. Для выгрузки в текстовый формат используйте выгрузку журнала из конфигуратора или обработку на встроенном языке.

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

Если сбой связан с базой данных, логов кластера 1С недостаточно — нужны журналы СУБД. В MS SQL Server это журнал ошибок ERRORLOG в каталоге Log экземпляра (например, C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log) и события в «Просмотре событий» Windows. В PostgreSQL путь задаётся параметром log_directory в postgresql.conf, обычно это подкаталог log внутри каталога данных кластера.

Системные журналы тоже содержат полезные записи: падения службы агента 1С фиксируются в журнале «Приложение» просмотра событий Windows (источник — агент сервера 1С), в Linux — в journald (journalctl -u srv1cv8 или аналогичное имя юнита) и syslog. Если сервер 1С внезапно перезапускается, начинайте поиск причины именно там.

Как проверить результат и не навредить

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

Для анализа больших логов не открывайте файлы в блокноте — используйте специализированные инструменты или хотя бы поиск по ключевым словам (Descr, Deadlock, EXCP). После завершения диагностики отключите или сократите состав событий ТЖ: постоянная запись всех событий заметно нагружает дисковую подсистему и снижает производительность сервера.

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