Логи сервера 1С: где находятся и как их анализировать

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

Платформа 1С:Предприятие 8.3 создаёт несколько типов логов в зависимости от настроек технологического журнала, журнала регистрации и системных событий Windows или Linux. Каждый тип логов решает свои задачи: технологический журнал фиксирует детальные события на уровне кластера серверов, журнал регистрации хранит бизнес-события информационных баз, а системные логи ОС отражают работу процессов rphost.exe, ragent.exe и rmngr.exe.

Где находятся логи сервера 1С 8.3

Расположение логов зависит от типа журнала и операционной системы сервера. В таблице ниже указаны стандартные пути для Windows Server и Linux.

Тип лога	Windows Server	Linux	Что фиксирует
Технологический журнал	C:\Program Files\1cv8\srvinfo\reg_1541\	/var/log/1C/	События кластера, блокировки, запросы к СУБД, ошибки rphost
Журнал регистрации	В каталоге информационной базы: 1Cv8Log\	Аналогично Windows	Действия пользователей, изменения документов, ошибки конфигурации
Логи Windows Event Log	Просмотр событий → Журналы приложений	—	Сбои процессов 1С, критические ошибки ОС
Логи syslog (Linux)	—	/var/log/syslog или /var/log/messages	Ошибки запуска служб, проблемы с памятью

Путь к технологическому журналу настраивается в консоли кластера серверов 1С (Администрирование → Настройка технологического журнала). По умолчанию папка называется reg_XXXX, где XXXX — номер порта агента кластера. Внутри папки создаются подкаталоги по датам (например, 20260211) и файлы с расширением .log.

Журнал регистрации хранится в каталоге информационной базы, который указан в настройках информационной базы в консоли кластера. Для файловых баз это путь вида \\server\bases\accounting\1Cv8Log\, для клиент-серверных баз — каталог на сервере 1С, где размещены рабочие файлы информационной базы.

Содержание технологического журнала

Технологический журнал — наиболее информативный источник данных для диагностики проблем сервера 1С. Он фиксирует события на уровне рабочих процессов (rphost), менеджера кластера (rmngr) и агента сервера (ragent). В логе записываются события с разными уровнями важности и категориями.

Основные категории событий

• DBMSSQL, DBOracle, DBPostgreSQL — запросы к СУБД, время выполнения SQL-команд, блокировки таблиц
• Deadlock — взаимные блокировки потоков, которые приводят к зависанию сеансов
• TLOCK — управляемые блокировки 1С (транзакционные и общие)
• MEM — события распределения памяти, утечки памяти в рабочих процессах
• EXCP — исключительные ситуации (exception), критические ошибки выполнения кода
• CONN — подключения и отключения пользователей
• CALL — вызовы серверных методов конфигурации
• SDBL — трансляция запросов языка запросов 1С в SQL

Каждое событие в технологическом журнале записывается в следующем формате:

53:24.347012-0,DBMSSQL,5,process=rphost,p:processName=rphost_12345,t:clientID=12345,t:applicationName=1CV8,t:computerName=CLIENT01,t:connectID=54321,SessionID=12345,Usr=Иванов И.И.,AppID=1CV8,SQL=SELECT T1.Ref FROM Document.Invoice AS T1 WHERE T1.Posted = 1,planSQLText=...,Rows=1234,RowsAffected=0,Duration=1234,durationPrepare=0,durationExecute=1234

Разберём структуру записи:

• 53:24.347012-0 — время события (минуты:секунды.микросекунды, смещение от начала текущего часа)
• DBMSSQL — категория события (запрос к Microsoft SQL Server)
• 5 — уровень детализации (от 1 до 10, чем выше — тем подробнее)
• process=rphost — процесс, который зафиксировал событие
• p:processName=rphost_12345 — имя процесса с идентификатором PID
• t:clientID, t:applicationName, t:computerName — данные о клиентском подключении
• SessionID — идентификатор сеанса пользователя
• Usr — имя пользователя 1С
• SQL — текст SQL-запроса
• Duration — общая длительность выполнения запроса в миллисекундах
• Rows — количество возвращённых строк

Эта информация позволяет точно определить, какой пользователь выполнил медленный запрос, сколько времени заняла его обработка и какие таблицы были задействованы. Для диагностики производительности серверов применяют фильтрацию событий по полю Duration — запросы длительностью более 5000 мс (5 секунд) требуют анализа и оптимизации.

Настройка технологического журнала

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

Для временной диагностики можно включить все категории событий с высоким уровнем детализации, но в продуктивном режиме рекомендуется логировать только критичные категории (DBMSSQL, Deadlock, EXCP, MEM) с уровнем 3-4. Это позволяет снизить объём записываемых данных и избежать заполнения дискового пространства.

При работе с высоконагруженными серверами 1С на платформе Dell PowerEdge важно размещать технологический журнал на быстрых накопителях SSD NVMe — это снижает задержки записи и не влияет на производительность рабочих процессов rphost.

Содержание журнала регистрации

Журнал регистрации 1С (1Cv8Log) хранит события уровня приложения: действия пользователей, изменения справочников и документов, попытки входа, ошибки выполнения кода конфигурации. Этот журнал ведётся автоматически для каждой информационной базы и доступен через клиент 1С (меню Администрирование → Журнал регистрации).

Журнал регистрации размещается в каталоге информационной базы в папке 1Cv8Log и состоит из файлов:

• 1Cv8.lgd — основной файл журнала с записями событий
• 1Cv8.lgp — индексный файл для ускорения поиска записей
• 1Cv8.lgf — файл описания структуры событий

Формат файлов журнала регистрации — бинарный, для чтения требуется клиент 1С или специализированные утилиты (например, 1C Log Parser). Каждая запись журнала содержит следующие поля:

• Дата и время — момент события с точностью до секунды
• Пользователь — имя пользователя 1С
• Компьютер — имя клиентского компьютера
• Приложение — тип подключения (Толстый клиент, Тонкий клиент, Web-клиент, Фоновое задание)
• Событие — тип события (например, «Ошибка», «Предупреждение», «Информация»)
• Комментарий — описание события или текст ошибки
• Метаданные — объект конфигурации, с которым связано событие (документ, справочник, обработка)

Для анализа журнала регистрации применяют встроенный просмотр в клиенте 1С с фильтрацией по пользователям, событиям и периодам времени. Это позволяет быстро найти ошибки подключения, проблемы с правами доступа или критичные события в работе информационной базы.

Инструменты анализа логов 1С

Для эффективной работы с логами сервера 1С системные администраторы используют специализированные утилиты, которые автоматизируют поиск проблем и визуализируют данные.

1. Консоль кластера серверов 1С

Встроенный инструмент платформы 1С для мониторинга кластера и просмотра технологического журнала. Позволяет фильтровать события по категориям, процессам и уровням детализации. Поддерживает экспорт данных в текстовые файлы для дальнейшего анализа в Excel или Power BI.

2. Log File Viewer (LFView)

Бесплатная утилита для просмотра и анализа технологического журнала 1С. Основные возможности:

• Открытие нескольких файлов логов одновременно
• Фильтрация событий по категориям, процессам, пользователям
• Поиск по тексту SQL-запросов и комментариям
• Построение графиков длительности запросов и нагрузки на СУБД
• Экспорт отфильтрованных данных в CSV

LFView ускоряет диагностику: вместо ручного поиска медленных запросов в текстовых файлах можно отфильтровать события DBMSSQL с Duration > 5000 и сразу увидеть список проблемных SQL-команд.

3. Zabbix + скрипты мониторинга

Для непрерывного контроля работы сервера 1С применяют системы мониторинга (Zabbix, Prometheus). Скрипты анализируют технологический журнал в реальном времени, ищут события EXCP и Deadlock и отправляют уведомления администраторам. Это позволяет реагировать на сбои до того, как пользователи сообщат о проблеме.

4. PowerShell и grep

Для быстрого поиска в логах используют стандартные утилиты командной строки. Примеры команд:

# Найти все события EXCP за текущий день (Windows PowerShell)
Select-String -Path "C:\TechLog\20260211\*.log" -Pattern "EXCP" | Select-Object Line

# Найти медленные запросы (Duration > 10000 мс)
Select-String -Path "C:\TechLog\20260211\*.log" -Pattern "Duration=([1-9][0-9]{4,})" | Select-Object Line

# Найти все события Deadlock за текущий день (Linux)
grep -r "Deadlock" /var/log/1C/20260211/

# Подсчитать количество событий EXCP
grep -r "EXCP" /var/log/1C/20260211/ | wc -l

Эти команды выполняются за секунды даже на больших логах (сотни мегабайт) и помогают быстро оценить масштаб проблемы.

Типичные ошибки в логах 1С и их решение

В таблице ниже приведены наиболее частые события в логах сервера 1С, их причины и способы устранения.

Событие	Описание	Причина	Решение
EXCP: Memory limit exceeded	Процесс rphost превысил лимит памяти	Недостаточно RAM на сервере или неоптимальные запросы	Увеличить объём RAM, оптимизировать запросы, ограничить объём выборки данных
Deadlock detected	Взаимная блокировка потоков	Одновременное изменение одних и тех же данных несколькими пользователями	Пересмотреть логику бизнес-процессов, использовать управляемые блокировки
DBMSSQL: Timeout expired	СУБД не успела выполнить запрос за отведённое время	Медленные запросы, отсутствие индексов, высокая нагрузка на SQL Server	Создать индексы, оптимизировать запросы, увеличить мощность сервера БД
CONN: Connection lost	Разрыв соединения клиента с сервером	Проблемы сети, перезапуск rphost, превышение таймаута простоя	Проверить стабильность сети, увеличить таймаут соединения в параметрах кластера
TLOCK: Lock wait timeout	Тайм-аут ожидания управляемой блокировки	Длительное удержание блокировки одним из пользователей	Оптимизировать код конфигурации, сократить время удержания блокировок

Пример анализа ошибки Memory limit exceeded

Событие EXCP с сообщением «Memory limit exceeded» возникает, когда рабочий процесс rphost.exe исчерпал доступную память. В логе это выглядит так:

15:42.123456-0,EXCP,1,process=rphost,p:processName=rphost_4567,Memory=2048,MemLimit=2048,Descr='Memory limit exceeded for process rphost_4567'

Поле Memory показывает текущее потребление памяти в мегабайтах, MemLimit — установленный лимит. Если значения равны, процесс достиг предела и был принудительно завершён.

Решение проблемы:

1. Увеличить лимит памяти для рабочих процессов в консоли кластера (Администрирование → Кластер серверов → Рабочие процессы → Использование памяти).
2. Добавить физическую память на сервер — для продуктивных серверов 1С с 50+ пользователями рекомендуется минимум 32 ГБ RAM.
3. Найти запросы, которые загружают большие объёмы данных (события DBMSSQL с Rows > 100000), и оптимизировать их.

Для серверов 1С с высокой нагрузкой подходят конфигурации Dell PowerEdge с поддержкой до 1 ТБ RAM и процессорами Intel Xeon Scalable — это гарантирует запас производительности для обработки больших массивов данных.

Настройка ротации логов

Технологический журнал 1С может расти до нескольких гигабайт в день на высоконагруженных серверах. Без ротации логов диск заполняется за несколько недель, что приводит к сбоям записи и потере данных. Для автоматического удаления старых логов применяют скрипты или встроенные механизмы ОС.

Ротация логов в Windows

Создайте задание в планировщике Windows, которое ежедневно удаляет файлы логов старше 30 дней:

# Скрипт PowerShell для удаления старых логов
$LogPath = "C:\TechLog\"
$DaysToKeep = 30
Get-ChildItem -Path $LogPath -Recurse -File | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysToKeep) } | Remove-Item -Force

Сохраните скрипт в файл clean_logs.ps1 и настройте запуск через Task Scheduler (Планировщик заданий) на время минимальной нагрузки (например, 03:00).

Ротация логов в Linux

В Linux используйте утилиту logrotate. Создайте файл конфигурации /etc/logrotate.d/1c:

/var/log/1C/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
}

Эта конфигурация сохраняет логи за последние 30 дней, сжимает старые файлы и не создаёт ошибок, если логов нет. Ротация выполняется автоматически через cron.

Мониторинг дисковой подсистемы

Технологический журнал создаёт высокую нагрузку на дисковую подсистему сервера — запись логов конкурирует с операциями СУБД и файлами информационных баз. Для снижения задержек рекомендуется размещать логи на отдельных дисках SSD с высокой скоростью записи (IOPS > 50000).

Мониторьте показатели дисковой подсистемы через Performance Monitor (Windows) или iostat (Linux). Критичные метрики:

• Avg. Disk Queue Length — средняя очередь запросов к диску (норма < 2)
• Disk Write Bytes/sec — скорость записи (для технологического журнала — до 50 МБ/с)
• % Disk Time — процент времени активности диска (норма < 80%)

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

Интеграция логов 1С с системами мониторинга

Для крупных инфраструктур с десятками серверов 1С ручной анализ логов нецелесообразен. Вместо этого применяют централизованные системы сбора и анализа логов (ELK Stack, Graylog, Splunk). Логи отправляются на центральный сервер, индексируются и становятся доступны для поиска через веб-интерфейс.

Пример конфигурации Filebeat для отправки технологического журнала 1С в Elasticsearch:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:\TechLog\*\*.log
  fields:
    log_type: 1c_tech_log

output.elasticsearch:
  hosts: ["http://elk-server:9200"]
  index: "1c-logs-%{+yyyy.MM.dd}"

После настройки Filebeat все события технологического журнала отправляются в Elasticsearch, где доступен полнотекстовый поиск по SQL-запросам, пользователям и процессам. Это ускоряет диагностику в десятки раз: вместо поиска по файлам на каждом сервере администратор вводит запрос в Kibana и видит все релевантные события из всех серверов кластера.

Резервное копирование логов

Логи сервера 1С — важный источник информации для расследования инцидентов и аудита действий пользователей. Для соблюдения требований информационной безопасности и восстановления данных после сбоев рекомендуется создавать резервные копии логов.

Настройте ежедневное копирование логов на отдельное хранилище или в облако:

• Для малых инфраструктур — скрипты PowerShell/Bash с копированием на сетевой диск (NAS, SMB/CIFS-ресурс)
• Для средних и крупных инфраструктур — Veeam Backup, Acronis или встроенные средства ОС (Windows Server Backup, rsync)

Срок хранения резервных копий логов зависит от политики компании и требований законодательства. Для коммерческих организаций рекомендуется хранить логи минимум 90 дней, для государственных учреждений — до 3 лет.

При настройке резервного копирования учитывайте объём данных: технологический журнал с детализацией 5 на сервере со 100 пользователями создаёт 2-5 ГБ логов в день. Для экономии места применяйте сжатие архивов (ZIP, 7z) — текстовые логи сжимаются в 10-15 раз.

Поддержка инфраструктуры резервного копирования и регулярное сервисное обслуживание серверов обеспечивают непрерывность бизнес-процессов и защиту данных от потери.

Оптимизация производительности через анализ логов

Технологический журнал 1С содержит данные, которые позволяют точно определить узкие места инфраструктуры и конфигурации. Регулярный анализ логов помогает предотвратить деградацию производительности и сократить время реакции на инциденты.

Методика анализа производительности

1. Соберите логи за период пиковой нагрузки (например, с 10:00 до 12:00 в рабочий день).
2. Отфильтруйте события DBMSSQL с Duration > 3000 мс — это медленные запросы, которые замедляют работу пользователей.
3. Сгруппируйте запросы по тексту SQL — найдите наиболее часто выполняемые медленные запросы.
4. Проанализируйте план выполнения запросов в SQL Server Management Studio (для MS SQL) или pgAdmin (для PostgreSQL) — определите отсутствующие индексы или неоптимальные соединения таблиц.
5. Внесите изменения в конфигурацию 1С или СУБД (создайте индексы, перепишите запросы, добавьте ограничения выборки).
6. Повторите измерения — убедитесь, что изменения снизили длительность запросов.

Эта методика позволяет систематически улучшать производительность серверов 1С без масштабных вложений в аппаратное обеспечение. Часто оптимизация одного запроса снижает нагрузку на сервер на 30-50%.

Метрики для постоянного мониторинга

Для проактивного управления производительностью серверов 1С рекомендуется ежедневно отслеживать следующие показатели из логов:

• Среднее время выполнения SQL-запросов (норма < 1000 мс)
• Количество событий Deadlock (норма < 10 в день)
• Количество событий EXCP (норма < 5 в день)
• Максимальное потребление памяти процессами rphost (не более 80% от лимита)
• Количество разрывов соединений CONN (норма < 20 в день)

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

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