Как настроить технологический журнал в кластере из нескольких серверов 1С:Предприятие 8.3?

При администрировании крупных информационных систем на платформе 1С:Предприятие 8.3 часто используется отказоустойчивый или производительный кластер, состоящий из двух и более физических серверов. В процессе диагностики стабильности и производительности системы ключевым инструментом становится Технологический журнал (ТЖ).

Однако при работе в распределенной среде администраторы часто сталкиваются с проблемой: конфигурационный файл настроен на центральном сервере, но логи со второго рабочего сервера не собираются или вообще отсутствуют. Выясним причину этой проблемы, разберем по шагам логику работы платформы и рассмотрим лучшие практики настройки ТЖ в многосерверном кластере.

Как процессы платформы ищут и считывают файл настроек logcfg.xml

Начнем с базового принципа работы платформы. Все процессы 1С:Предприятия, такие как агент сервера ragent, менеджер кластера rmngr и рабочие процессы rphost, функционируют на каждом сервере как независимые службы операционной системы. Когда запускается любой из этих процессов, он пытается определить параметры логирования, считывая конфигурационный файл настроек технологического журнала logcfg.xml.

Критически важно понимать: процессы 1С ищут конфигурационный файл настроек исключительно локально на том сервере, на котором они запущены. Никакого «автоматического наследования» настроек с центрального сервера на рабочие серверы кластера средствами самой платформы не происходит.

Проанализируем порядок и места поиска файла настроек процессами на каждом отдельном сервере:

1. Общий каталог конфигурации для всех версий платформы:
   • В операционной системе Windows: C:\Program Files\1cv8\conf\logcfg.xml
   • В операционной системе Linux: /opt/1cv8/conf/logcfg.xml
2. Каталог конфигурации конкретной версии платформы:
   • В операционной системе Windows: C:\Program Files\1cv8\<Номер_Версии_Платформы>\bin\conf\logcfg.xml
   • В операционной системе Linux: /opt/1cv8/<Номер_Версии_Платформы>/bin/conf/logcfg.xml
3. Пользовательский каталог (если служба запущена от имени конкретной учетной записи ОС):
   • В операционной системе Windows: C:\Users\<Имя_Пользователя>\AppData\Local\1C\1cv8\conf\logcfg.xml
   • В операционной системе Linux: ~/.1cv8/conf/logcfg.xml

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

Организация хранения логов: локально или в сетевую папку?

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

Подход №1: Запись логов на локальные диски серверов (Рекомендуемый)

При таком подходе на каждом сервере кластера создается локальный каталог для хранения логов, и в локальных файлах logcfg.xml прописывается путь к нему.

Пример настройки logcfg.xml для записи на локальный диск:

<config xmlns="http://v8.1c.ru/v8/tech-journal">
    <log location="C:\1C_Logs\TJ" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

Преимущества:

• Максимальная производительность: Локальные дисковые операции происходят со скоростью локальной шины данных, не создавая нагрузки на локальную сеть.
• Надежность: Запись логов не прервется при временных проблемах со связью между серверами.

Недостатки:

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

Подход №2: Запись логов в общую сетевую папку (UNC-путь)

Кажется заманчивым указать один общий сетевой каталог для всех серверов кластера, чтобы логи собирались «в одну кучу» автоматически. Например:

<config xmlns="http://v8.1c.ru/v8/tech-journal">
    <log location="\\central-server\1C_logs" history="12">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

Однако этот подход таит в себе множество скрытых проблем, которые могут привести к падению производительности или полной потере логов:

1. Права доступа операционной системы: Службы 1С на рабочих серверах часто запускаются под локальными системными учетными записями (например, LocalSystem) или локальными пользователями (например, USR1CV8). Локальный пользователь одного сервера не имеет никаких прав на сетевой каталог другого сервера. Чтобы запись по сетевому пути заработала, службы 1С на всех серверах должны быть запущены от имени доменной учетной записи, которой предоставлены полные права (чтение, запись, изменение) на общую сетевую папку.
2. Конфликты блокировок процессов (PID): Внутри целевой папки платформа создает подкаталоги по именам процессов и их PID (например, rphost_1234). Если два физических сервера в кластере одновременно запустят процессы с одинаковыми PID (что при интенсивной работе случается регулярно) и попытаются писать в одну общую сетевую папку, возникнет конфликт совместного доступа к файлам. Это приведет к повреждению логов или полной блокировке записи со стороны одного из серверов.
3. Падение производительности дисковой и сетевой подсистем: Технологический журнал при высоком уровне детализации генерирует колоссальные объемы информации. Постоянная синхронная отправка мегабайтов данных по сети напрямую рабочими процессами rphost существенно замедляет их работу, увеличивая время отклика для конечных пользователей.

Как на самом деле работает 1С:ЦУП в многосерверном кластере

При использовании специализированных инструментов, таких как ЦУП (Центр управления производительностью) из состава Корпоративного инструментального пакета (КИП), процесс сбора логов автоматизируется, но подчиняется тем же самым правилам.

Когда вы подключаете информационную базу к ЦУП, система анализирует структуру кластера и определяет список всех входящих в него рабочих серверов. Чтобы включить технологический журнал:

• ЦУП пытается удаленно записать конфигурационные файлы logcfg.xml на каждый из рабочих серверов кластера.
• Для этого системе требуются административные права доступа к сетевым ресурсам этих серверов (например, к скрытым общим папкам вида \\server2\C$). Если сетевой доступ закрыт брандмауэром или учетная запись ЦУП не имеет административных прав на удаленном сервере, автонастройка не сработает.
• На каждом сервере также должны быть установлены специальные вспомогательные компоненты — Агенты КИП, которые локально собирают логи и передают их в центральную базу ЦУП.

В современных конфигурациях мониторинга часто применяется схема на основе лог-шипперов (например, Fluent Bit или Logstash). На каждом сервере кластера настраивается локальная высокопроизводительная запись технологического журнала на быстрый диск, а легковесный агент в фоновом режиме считывает файлы и отправляет их в единое хранилище (например, Elasticsearch или OpenSearch). Это исключает сетевые задержки при работе процессов 1С и гарантирует полноту собираемых данных.

Пошаговый алгоритм настройки ТЖ на втором сервере кластера

Рассмотрим по шагам, как правильно настроить сбор логов, если вы администрируете двухсерверный кластер вручную:

Шаг 1. Создание локальной директории для логов.
На каждом из двух серверов создайте быструю директорию на локальном диске (желательно SSD/NVMe), например: C:\TJ_Logs\. Убедитесь, что у пользователя, под которым работает служба 1C:Enterprise 8.3 Server Agent (например, USR1CV8), есть полные права доступа к этой папке.

Шаг 2. Подготовка конфигурационного файла.
Создайте текстовый файл logcfg.xml со следующим содержимым:

<config xmlns="http://v8.1c.ru/v8/tech-journal">
    <log location="C:\TJ_Logs" history="24">
        <event>
            <eq property="name" value="EXCP"/>
        </event>
        <property name="all"/>
    </log>
</config>

Шаг 3. Размещение файла настроек на обоих серверах.
Скопируйте подготовленный файл logcfg.xml в локальный каталог конфигурации conf на первом и на втором серверах кластера (например, в C:\Program Files\1cv8\conf\).

Шаг 4. Проверка работы.
Подождите около 60 секунд. Перейдите в созданные на шаге 1 папки C:\TJ_Logs\ на первом и на втором серверах. Вы должны увидеть появление подкаталогов с именами процессов (например, rphost_..., rmngr_...), в которых начнут создаваться файлы логов с расширением .log. Это означает, что конфигурация применена успешно и сбор данных идет параллельно на обоих узлах вашего кластера.