Работа с высоконагруженными информационными базами требует постоянного мониторинга производительности. Когда пользователи жалуются на «тормоза» или зависания, администратору необходимо получить объективные данные о происходящем на сервере. Стандартные средства мониторинга не дают полной картины происходящего внутри ядра платформы.
В таких ситуациях на помощь приходит технологический журнал, который фиксирует все события в работе кластера серверов. Его включение позволяет отследить длительные транзакции, ошибки соединений и потребление ресурсов в реальном времени. Правильная настройка логов — это первый шаг к диагностике сложных проблем в архитектуре 1С:Предприятие.
Однако не стоит запускать запись всех событий подряд без разбора. Это может привести к переполнению дискового пространства и дополнительному снижению производительности системы. В этой статье мы подробно разберем, как активировать логирование, какие параметры использовать для фильтрации и как правильно анализировать полученные данные.
Назначение и принципы работы журнала
Технологический журнал представляет собой текстовый файл, в который сервер 1С записывает события согласно заданным шаблонам. Он работает на уровне процесса rphost или rmngr. Каждая запись содержит временную метку, имя процесса, имя пользователя и детальное описание события.
Основная цель использования этого инструмента — выявление узких мест в конфигурации или инфраструктуре. С его помощью можно отследить, какая именно операция занимает больше всего времени. Например, вы сможете увидеть долгие SQL-запросы или блокировки на уровне записей.
Важно понимать, что включение журнала создает дополнительную нагрузку на дисковую подсистему. Поэтому его следует активировать только на время проведения диагностики. После сбора необходимой информации логирование необходимо немедленно отключить или перенастроить на менее детальный режим.
⚠️ Внимание: Никогда не включайте полную запись всех событий (уровень детализации 0) на боевых серверах в рабочее время. Это гарантированно приведет к остановке работы базы из-за нехватки места на диске или исчерпания ресурсов ввода-вывода.
Перед включением журнала убедитесь, что на диске, куда будут писаться логи, есть как минимум 10-15 ГБ свободного места. Логи могут расти экспоненциально быстро при высокой активности пользователей.
Регистрация компонентов в реестре Windows
Для того чтобы сервер 1С начал записывать события, необходимо зарегистрировать специальные компоненты в реестре операционной системы. Этот процесс выполняется с помощью утилиты regsvr32. Без этой процедуры параметры в консоли кластера просто не будут иметь силы.
Процедура регистрации должна выполняться от имени администратора. Вам потребуется найти файлы DLL, которые поставляются вместе с сервером 1С. Обычно они находятся в каталоге установки платформы, в папке bin.
Существует два основных компонента, которые отвечают за разные аспекты логирования. Первый отвечает за общий механизм журнала, а второй — за специфические события СУБД. Регистрация обоих компонентов гарантирует полный охват диагностируемых проблем.
regsvr32"C:\Program Files\1cv8\8.3.22.1567\bin\1cv8log.dll"
regsvr32"C:\Program Files\1cv8\8.3.22.1567\bin\1cv8logcms.dll"
После успешного выполнения команд вы увидите системное сообщение о регистрации. Если появляется ошибка, проверьте разрядность ОС и версию платформы. Пути к файлам могут отличаться в зависимости от того, куда была установлена ваша версия 1С:Предприятие.
☑️ Проверка перед регистрацией
Настройка параметров через консоль кластера
После регистрации DLL необходимо настроить правила отбора событий. Это делается через консоль администрирования серверов 1С. Вам нужно подключиться к центральному серверу кластера и найти нужный рабочий процесс.
В свойствах процесса rphost или на уровне всего кластера можно задать параметры технологического журнала. Ключевыми параметрами являются log-level, log-location и log-template. Именно они определяют, что, куда и как подробно будет записываться.
Параметр log-level задает уровень детализации. Значение 0 означает запись всего, что является избыточным. Оптимальным значением для диагностики производительности обычно является 1 или 2. Параметр log-location указывает путь к файлу на диске сервера.
| Параметр | Значение по умолчанию | Рекомендуемое значение | Описание |
|---|---|---|---|
| log-level | 0 (выключен) | 1 | Уровень детализации событий |
| log-location | - | C:\1CLogs\tj.log | Полный путь к файлу лога |
| log-template | - | EXCP;SQL;LOCK | Шаблон отбираемых событий |
| log-period | 0 | 300 | Период ротации файла в секундах |
Не забудьте применить изменения. В некоторых версиях платформы требуется перезапуск службы сервера 1С или хотя бы перезапуск конкретного рабочего процесса, чтобы новые настройки вступили в силу. Проверьте статус процесса после внесения изменений.
Использование шаблонов и фильтров событий
Самая важная часть настройки — это правильный выбор шаблона. Шаблон определяет, какие именно события будут попадать в лог. Использование wildcard-символов позволяет гибко настраивать фильтрацию под конкретную задачу.
Например, если вас интересуют только ошибки выполнения кода, используйте шаблон EXCP. Если нужно найти причину медленной работы отчетов, подключите шаблон SQL с фильтром по времени выполнения. Это позволит отсечь лишнюю информацию.
Можно комбинировать несколько типов событий через точку с запятой. Например, конструкция EXCP;SQL;LOCK позволит видеть ошибки, долгие запросы и блокировки в одном потоке. Это универсальный набор для первичной диагностики.
Для анализа блокировок часто используется параметр LOCK. Он показывает, какой процесс удерживает блокировку и кто ждет её освобождения. Это критически важно при анализе взаимоблокировок (deadlock) в многопользовательском режиме.
⚠️ Внимание: Фильтр CALL записывает вызовы каждого метода. Используйте его с крайней осторожностью и только на тестовых стендах, так как объем данных будет колоссальным.
Существует возможность настройки фильтрации по времени выполнения запроса. Вы можете указать, чтобы в журнал попадали только те SQL-запросы, которые выполняются дольше определенного порога, например, 1000 мс. Это резко сокращает размер лога.
Список основных кодов событий
EXCP — Ошибки выполнения|SQL — Запросы к СУБД|LOCK — Блокировки данных|CALL — Вызовы методов|MEM — Выделение памяти|NET — Сетевое взаимодействие
Анализ логов и поиск проблем
После того как журнал поработал некоторое время, наступает этап анализа. Файл лога представляет собой поток записей, который трудно читать в обычном блокноте. Для эффективного разбора лучше использовать специализированные утилиты или текстовые редакторы с поддержкой больших файлов.
В первую очередь ищите записи с меткой EXCP. Они указывают на критические сбои. Обратите внимание на стек вызовов, который обычно прилагается к сообщению об ошибке. Это поможет локализовать проблемный модуль конфигурации.
Если проблема в производительности, сортируйте записи по длительности выполнения. В логах часто указывается время в миллисекундах. Запросы, занимающие более 5-10 секунд, требуют оптимизации индексов или переписывания алгоритма.
При анализе блокировок обращайте внимание на пары событий: захват блокировки и ожидание. Если один процесс долго держит ресурс, а другие стоят в очереди, это явный признак неоптимальной транзакции. Возможно, транзакция охватывает слишком много данных.
Для быстрого анализа используйте утилиту 1CLogReader или скрипты PowerShell, которые могут парсить лог-файлы и выводить статистику по топ-10 самых долгих операций.
Очистка и автоматизация обслуживания
Технологический журнал не имеет встроенного механизма автоудаления старых записей в некоторых конфигурациях. Администратор должен самостоятельно следить за размером файлов. Переполненный диск — частая причина падения всего кластера серверов.
Рекомендуется настроить задачу в планировщике Windows, которая будет архивировать или удалять старые логи. Скрипт может проверять возраст файлов и перемещать их в архивную папку, если они старше 24 часов. Это поддерживает порядок на сервере.
Также полезно реализовать механизм ротации логов внутри параметров самого журнала. Параметр log-period позволяет создавать новые файлы через заданные интервалы времени. Старые файлы при этом можно безопасно удалять скриптом.
Помните, что после устранения проблемы необходимо вернуть настройки журнала в исходное состояние. Отключите запись или уменьшите уровень детализации до минимума. Работа с включенным подробным логированием в штатном режиме недопустима.
⚠️ Внимание: Интерфейсы и параметры могут незначительно отличаться в разных версиях платформы 1С. Всегда сверяйтесь с документацией к вашей конкретной версии релиза перед внесением изменений в реестр.
Используйте PowerShell команду Get-ChildItem для поиска файлов логов размером более 1 ГБ. Это поможет быстро обнаружить забытые включенные журналы.
Где физически хранится файл технологического журнала?
Путь к файлу задается в параметре log-location в консоли кластера. Если параметр не задан явно, сервер может использовать временную папку пользователя, под которым запущена служба, или папку установки платформы. Всегда задавайте явный путь, например, D:\Logs\1C_TJ.log.
Можно ли включить журнал для конкретной информационной базы?
Да, это возможно. В консоли кластера нужно раскрыть ветку конкретной информационной базы, найти работающие процессы (rphost), связанные с ней, и задать параметры журнала именно для этих процессов. Это позволит изолировать логи одной базы от других.
Как понять, что журнал включен и работает?
Проверьте наличие файла по указанному пути. Если файл создается и его размер увеличивается в момент активных действий пользователей, значит, логирование работает. Также можно посмотреть события в журнале регистрации Windows, если настроен соответствующий вывод.
Влияет ли включение журнала на скорость работы 1С?
Да, влияет. Запись на диск — это ресурсоемкая операция. При высоком уровне детализации (log-level 0-1) и большой нагрузке снижение производительности может составлять от 5% до 30%. Поэтому используйте журнал только для диагностики.