При администрировании крупных информационных баз на платформе 1С:Предприятие нередко возникают ситуации, когда система начинает вести себя нестабильно: появляются необъяснимые ошибки, зависают сеансы или резко падает производительность. В такие моменты лучшим инструментом для локализации проблемы становится Технологический журнал (ТЖ). Однако перед системным администратором встает закономерный вопрос: можно ли активировать ТЖ на короткий промежуток времени (например, на один час) непосредственно в процессе работы пользователей, не прерывая их сеансы и не выполняя перезапуск сервера 1С?
В рамках данной статьи мы подробно разберем, как устроен механизм включения ТЖ, выясним, почему для его активации не требуется рестарт служб, научимся правильно настраивать конфигурационный файл logcfg.xml, минимизировать нагрузку на дисковую подсистему и автоматизировать процесс отключения журнала через заданное время.
Начнем с главного вопроса, который волнует каждого администратора высоконагруженных систем: нужно ли выгонять пользователей или планировать технологическое окно для перезапуска службы сервера приложений 1С? Ответ однозначный: нет, не нужно.
Давайте проанализируем, как именно рабочие процессы сервера приложений 1С взаимодействуют с конфигурационными файлами. Все запущенные рабочие процессы (такие как rphost, ragent, rmngr) в фоновом режиме осуществляют непрерывный мониторинг каталога конфигурации. Интервал опроса этого каталога на предмет появления или изменения файла logcfg.xml составляет ровно 60 секунд.
Это означает следующее:
logcfg.xml в целевом каталоге, сервер 1С автоматически считывает новые настройки в течение одной минуты и начинает логирование «на лету».logcfg.xml из папки конфигурации. В течение той же минуты запись данных в технологический журнал полностью прекратится.Такой механизм позволяет нам безопасно исследовать поведение системы в режиме реального времени, собирая детальную трассировку именно в те моменты, когда наблюдается пиковая нагрузка или воспроизводится плавающая ошибка.
В зависимости от версии платформы 1С:Предприятие расположение конфигурационных файлов может различаться. Рассмотрим особенности размещения для современных и устаревших релизов платформы.
Если мы работаем на устаревших версиях платформы (например, ветка 1С v8.2), файл logcfg.xml необходимо размещать в подкаталоге conf конкретного релиза платформы. Путь к нему выглядит следующим образом:
C:\Program Files\1cv82\8.2.XX.XXX\bin\conf\ (где 8.2.XX.XXX — номер установленного релиза).
В современных версиях платформы 1С:Предприятие 8.3 разработчики существенно упростили эту процедуру. Теперь файл настроек ТЖ можно разместить в общем каталоге конфигурации, который является единым для всех установленных версий платформы на данном сервере:
C:\Program Files\1cv8\conf\/opt/1cv8/conf/Размещение файла в общей папке conf избавляет нас от необходимости копировать файл при каждом обновлении релиза платформы 1С. Все установленные и вновь запускаемые процессы сервера будут автоматически использовать единый конфигурационный файл.
При включении ТЖ на «живой» рабочей базе крайне важно не перегрузить дисковую подсистему сервера. Если мы настроим сбор всех возможных событий (так называемый «полный ТЖ»), сервер может моментально зависнуть из-за колоссального объема дисковых операций записи. Нам необходимо собирать только строго определенные события.
Рассмотрим структуру типового конфигурационного файла logcfg.xml, ориентированного на сбор критических ошибок (исключений) и аварийных дампов:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" location="C:\dumps" type="3"/>
<log history="2" location="C:\log\tech_log">
<property name="all"/>
<event>
<eq property="name" value="excp"/>
</event>
</log>
</config>
Давайте подробно разберем по шагам ключевые теги и параметры, используемые в данном файле:
<dump> управляет созданием дампов при аварийном завершении рабочих процессов сервера 1С. Параметр create="true" активирует запись дампов, location указывает папку для их сохранения, а type="3" определяет уровень детализации дампа (в данном случае — полный дамп памяти процесса, что крайне полезно для разработчиков при анализе причин падения рабочих процессов).history="2" в теге <log> указывает платформе время хранения файлов ТЖ в часах. По истечении этого времени старые файлы логов будут автоматически удаляться платформой. Это критически важный параметр, который страхует дисковую систему сервера от переполнения, если администратор забудет выключить логирование вручную. В нашем случае мы установили значение 2 часа, что отлично подходит для часового мониторинга.<event> и вложенный в него фильтр <eq property="name" value="excp"/> указывают, что в журнал необходимо записывать исключительно события типа EXCP (exceptions — исключительные ситуации, ошибки). Такой подход позволяет фиксировать все нештатные ситуации в системе, практически не оказывая влияния на общую производительность сервера.Иногда сбора одних лишь ошибок EXCP бывает недостаточно для локализации проблемы. Например, если нам необходимо выявить запросы к базе данных, которые выполняются слишком медленно и вызывают зависание системы. В этом случае нам потребуется собирать события работы с СУБД (например, DBMSSQL или DBPOSTGR в зависимости от используемой СУБД).
Чтобы не перегрузить сервер, мы должны обязательно использовать фильтрацию по длительности события. Рассмотрим пример конфигурационного файла для сбора запросов к СУБД Microsoft SQL Server, длительность выполнения которых превышает 10 секунд (10 000 000 микросекунд):
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log history="2" location="C:\log\long_queries">
<property name="all"/>
<event>
<eq property="name" value="DBMSSQL"/>
<gt property="duration" value="10000000"/>
</event>
</log>
</config>
Проанализируем этот пример. С помощью оператора <gt property="duration" value="10000000"/> (greater than — больше чем) мы отсекаем миллионы быстрых запросов, которые выполняются мгновенно, и фиксируем только те «тяжелые» операции, которые реально нагружают систему и заставляют пользователей ждать. Такой точечный сбор логов позволяет проводить глубокую диагностику производительности прямо на работающей рабочей системе.
Поскольку в самой платформе 1С:Предприятие отсутствует встроенный таймер отключения логирования, для реализации сценария «включить ровно на 1 час» нам потребуется использовать внешние инструменты операционной системы. Ниже представлены два наиболее популярных сценария автоматизации.
Мы можем написать простой скрипт на языке PowerShell, который будет запускаться планировщиком задач (Task Scheduler). Скрипт выполнит копирование предварительно настроенного файла конфигурации в папку 1С, выдержит паузу в 1 час, после чего удалит файл, остановив запись логов.
Для реализации этого метода выполним следующие шаги:
C:\TJ_Temp) и сохраним туда наш целевой файл logcfg.xml.start_tj.ps1 со следующим содержимым:
# Путь к заранее подготовленному файлу конфигурации ТЖ
$SourceFile = "C:\TJ_Temp\logcfg.xml"
# Рабочий каталог конфигурации сервера 1С
$DestFolder = "C:\Program Files\1cv8\conf"
$DestFile = Join-Path $DestFolder "logcfg.xml"
# Шаг 1: Копируем файл для активации ТЖ
Copy-Item -Path $SourceFile -Destination $DestFolder -Force
Write-Host "Технологический журнал успешно активирован. Ожидаем 1 час..."
# Шаг 2: Ждем 3600 секунд (1 час)
Start-Sleep -Seconds 3600
# Шаг 3: Удаляем файл для деактивации ТЖ
if (Test-Path $DestFile) {
Remove-Item -Path $DestFile -Force
Write-Host "Время вышло. Технологический журнал успешно отключен."
}
Этот скрипт можно запускать как вручную через консоль PowerShell от имени администратора, так и по расписанию через планировщик задач Windows, настроив запуск в определенные часы пиковой нагрузки.
Если мы не хотим использовать внешние скрипты, мы можем подстраховаться с помощью параметра ротации, встроенного в саму платформу 1С. Как мы уже упоминали, атрибут history задает время хранения логов в часах.
Если мы установим значение history="1", платформа будет автоматически перезаписывать и удалять файлы логов, храня информацию только за последний астрономический час. Таким образом, даже если мы физически забудем удалить файл logcfg.xml из папки conf, объем логов на диске никогда не превысит лимит, накопленный за 60 минут работы. Однако, для полного прекращения дисковой активности файл все же потребуется удалить или переименовать.
При настройке технологического журнала администраторы часто совершают классические ошибки, из-за которых сбор данных либо не начинается вовсе, либо приводит к серьезному падению производительности сервера. Разберем ключевые правила, которые необходимо строго соблюдать.
Это, пожалуй, самая частая причина, по которой ТЖ «не взлетает». Рабочие процессы сервера 1С функционируют под управлением специальной системной учетной записи ОС (в Windows по умолчанию это локальный пользователь USR1CV8, в Linux — пользователь usr1cv8).
Чтобы платформа могла записывать файлы логов, у этой учетной записи должны быть полные права (чтение, запись, изменение) на тот каталог, который указан в параметре location конфигурационного файла (в нашем примере это C:\log\tech_log). Если у пользователя USR1CV8 не будет прав на создание папок и запись файлов в целевой директории, платформа не выдаст абсолютно никаких предупреждений или ошибок в системный журнал — логи просто не будут собираться.
Процесс записи технологического журнала характеризуется созданием огромного количества мелких текстовых файлов, в которые непрерывно добавляются новые строки. Для любого антивируса, установленного на сервере, такое поведение выглядит подозрительно. Антивирус начинает «на лету» сканировать каждый изменяемый лог-файл, блокируя его чтение и запись на доли секунды.
Это приводит к лавинообразному росту длительности дисковых операций ввода-вывода (I/O) и вызывает жесткие зависания у всех активных пользователей 1С. Перед включением ТЖ в обязательном порядке внесите каталог с логами и каталог с дампами в список исключений вашего серверного антивируса!
В конфигурационном файле параметры location для тегов <log> и <dump> указывают пути к каталогам хранения информации. Настоятельно рекомендуем указывать для них абсолютно разные папки (например, C:\log\tech_log и C:\dumps).
Если вы укажете одну и ту же папку, то при срабатывании механизма автоматической очистки устаревших логов по параметру history платформа очистит весь каталог и безвозвратно удалит файлы дампов аварийного завершения процессов, которые могли понадобиться вам для расследования причин сбоя.
Никогда не настраивайте вывод логов ТЖ на тот же физический диск, где расположены рабочие базы данных (файловые или базы СУБД) или файлы виртуальной памяти (pagefile.sys / swap). Интенсивная последовательная запись логов создаст конкурентную нагрузку на дисковые головки (в случае HDD) или исчерпает ресурс производительности контроллера (в случае SSD).
Идеальное решение — выделение отдельного быстрого накопителя (или раздела на высокопроизводительном SSD-массиве) исключительно под нужды логирования ТЖ.
Для программистов и системных администраторов, которые хотят выйти за рамки простого отслеживания ошибок EXCP, полезно знать и другие ключевые события технологического журнала. Рассмотрим наиболее важные из них:
SDBL — фиксирует все запросы к внутреннему объектному языку запросов 1С (запросы на уровне СУБД 1С). Анализ этих событий помогает понять, как объектный запрос платформы транслируется во внутренние структуры данных СУБД.CONN — события установки и разрыва соединений между различными рабочими процессами и клиентскими приложениями. Незаменимо при поиске причин сетевых сбоев и отвалах пользователей.PROC — регистрирует запуск, остановку и аварийное завершение самих рабочих процессов сервера (rphost и др.).ADMIN — фиксирует административные действия, выполняемые через консоль кластера или программно (например, завершение сеансов, изменение параметров кластера).Если вы создали файл logcfg.xml, подождали более одной минуты, но в целевом каталоге не появилось ни одного файла логов, рекомендуем провести проверку по следующему чек-листу:
logcfg.xml сохранен в кодировке UTF-8. Использование других кодировок (например, UTF-16 или ANSI) приведет к тому, что платформа не сможет корректно прочесть XML-структуру и проигнорирует файл.<conifg> вместо <config>) делает файл нечитаемым для платформы. Откройте файл в любом веб-браузере для быстрой проверки структуры XML.conf именно той версии платформы, служба которой сейчас запущена и обрабатывает пользовательские сеансы.1C:Enterprise 8.3 Server Agent. В колонке "Вход от имени" проверьте точное имя пользователя. Именно этому пользователю необходимо предоставить полные права на папку с логами.Подводя итоги, мы можем с уверенностью сказать, что кратковременное включение технологического журнала 1С на 1 час — это стандартная, безопасная и крайне эффективная процедура администрирования. Благодаря динамическому опросу конфигурационных файлов платформой 1С:Предприятие, мы можем гибко управлять сбором диагностических данных прямо в процессе работы пользователей.
Главное — соблюдать базовую гигиену настройки: ограничивать состав собираемых событий, использовать фильтры по длительности для тяжелых запросов, следить за правами доступа службы 1С к дисковым каталогам и обязательно исключать папки логов из области сканирования антивирусного ПО. Соблюдение этих простых рекомендаций позволит вам оперативно находить причины любых сбоев без ущерба для комфортной работы пользователей.