Логи сервера 1С 8.3: где смотреть и как их использовать

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

Основные рабочие инструменты диагностики — технологический журнал (ТЖ) и журнал регистрации (ЖР). Первый пишет низкоуровневые события платформы: вызовы, запросы к СУБД, ошибки, дампы. Второй фиксирует действия пользователей и системные события на уровне прикладного решения. Дополнительно к ним работают логи операционной системы и сервера баз данных, без которых картина часто остаётся неполной.

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

Какие логи есть у сервера 1С и за что каждый отвечает

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

Журнал регистрации работает на уровне прикладного решения: вход и выход пользователей, изменение объектов, запуск фоновых заданий, ошибки выполнения кода. Его удобно смотреть прямо из конфигуратора или через функцию «Выгрузка журнала регистрации». При этом ЖР не покажет, почему упал рабочий процесс, — это зона ответственности ТЖ и системных логов.

Третий уровень — логи окружения: служба «Агент сервера 1С:Предприятия» пишет события в системный журнал Windows, а СУБД (MS SQL Server, PostgreSQL, Oracle) ведёт собственные журналы ошибок и медленных запросов. Полная диагностика почти всегда требует сопоставления всех трёх уровней по времени события.

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

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

По умолчанию файлы ТЖ складываются в каталог, заданный параметром location в logcfg.xml. Если каталог не указан, используется стандартный путь C:\ProgramData\1C\1cv8\logs\ (внутри — подкаталоги по именам процессов: rphost, ragent, rmngr). Убедитесь, что у учётной записи службы агента сервера (по умолчанию USR1CV8) есть права на запись в этот каталог — иначе журнал молча не создастся.

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

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

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

Журнал регистрации: где лежит и как посмотреть

Журнал регистрации хранится вместе с информационной базой. Для клиент-серверного варианта это файл 1Cv8.lgd (в новых версиях формата — каталог 1Cv8Log с файлами по периодам) внутри служебного каталога базы в кластере серверов. Сам каталог кластера находится в srvinfo каталога установки сервера, а точный путь к регистрационным данным базы можно увидеть в консоли кластера в свойствах информационной базы.

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

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

Логи службы агента сервера и события Windows

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

Каталог srvinfo (по умолчанию C:\Program Files\1cv8\srvinfo или путь, заданный параметром -d при установке службы) содержит реестр кластера: список баз, настройки менеджеров и рабочих процессов. Повреждение файлов в этом каталоге — частая причина того, что кластер не стартует или базы «пропадают» из консоли. Перед любыми ручными правками в srvinfo остановите службу агента и сделайте копию каталога.

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

1. 1
   Откройте «Просмотр событий» Windows и найдите записи об аварийном завершении rphost в момент инцидента
2. 2
   Проверьте каталог дампов (указан в logcfg.xml) — наличие свежего дампа подтверждает падение процесса
3. 3
   Включите в logcfg.xml события EXCP и PROC, если они ещё не пишутся, и дождитесь повторения или проанализируйте уже записанное
4. 4
   Сопоставьте время падения с записями журнала регистрации — найдите, какой пользователь и какое действие предшествовали сбою
5. 5
   Проверьте журнал ошибок СУБД на тот же момент времени — взаимоблокировки и разрывы соединений видны именно там

Логи СУБД: MS SQL Server и PostgreSQL

Значительная часть «проблем 1С» на самом деле — проблемы сервера баз данных. В MS SQL Server журнал ошибок открывается через SQL Server Management Studio: «Management» → «SQL Server Logs». Здесь фиксируются взаимоблокировки (deadlock), таймауты, ошибки целостности, события автоматического перезапуска. Дополнительно полезен расширенный сбор медленных запросов через Extended Events или Profiler на время диагностики.

В PostgreSQL расположение логов задаётся параметрами log_directory и log_filename в postgresql.conf; типичный путь — подкаталог log внутри каталога данных кластера. Для диагностики 1С полезно временно включить log_min_duration_statement, чтобы видеть длительные запросы, и log_lock_waits для фиксации ожиданий блокировок.

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

Что искать в логах при типовых проблемах

При жалобах на «всё тормозит» в технологическом журнале включите события DBMSSQL (или DBPOSTGRS / DBORACLE) и CALL с фильтром по длительности. События с большим значением duration покажут конкретные запросы и вызовы, которые занимают время. Параллельно проверьте ожидания на СУБД — часто длительный запрос в ТЖ на самом деле ждёт блокировку.

При ошибке «Соединение с сервером разорвано» смотрите в ТЖ события EXCP (исключения) и CONN (соединения), а в Просмотре событий — не падал ли rphost. Если рабочий процесс падает регулярно, анализ дампа и обращение к списку известных ошибок платформы для вашей версии — правильный следующий шаг; иногда помогает обновление платформы на свежий релиз.

При подозрении на действия пользователей (кто удалил документ, кто изменил проводки) достаточно журнала регистрации: отбор по типу события «Данные. Удаление» или «Данные. Изменение» и по объекту метаданных даст точный ответ с указанием пользователя и времени. Учитывайте, что ЖР фиксирует факт изменения, но не старые значения реквизитов — для такого уровня аудита нужны отдельные механизмы.

Организация хранения и ротации логов

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

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

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