Эффективное обслуживание высоконагруженных информационных систем требует постоянного контроля за занимаемым дисковым пространством. В экосистеме 1С:Предприятие серверная часть генерирует колоссальные объемы служебной информации, которые при отсутствии регламентных работ могут полностью исчерпать ресурсы хранилища. Накопление файлов логов часто приводит к критическим ситуациям, когда сервер перестает отвечать на запросы пользователей или вовсе останавливает службы из-за нехватки места.
Администраторам необходимо понимать архитектуру хранения диагностических данных, чтобы грамотно управлять ими. Процесс очистки не сводится к простому удалению файлов через проводник, так как активные процессы могут блокировать запись или, наоборот, продолжать писать в удаленные дескрипторы. Игнорирование этой процедуры превращает сервер вуправляемую систему, где поиск первопричины ошибки тонет в гигабайтах рутинных записей.
В данной статье мы детально разберем механизмы работы технологического журнала, журналов регистрации и системных логов кластера. Вы узнаете, как использовать утилиту rac для автоматизации рутинных задач и какие нюансы существуют при работе с файловыми и SQL-серверными базами данных. Правильная настройка ротации и очистки — залог стабильности вашей инфраструктуры.
Архитектура логирования в сервере 1С
Сервер 1С:Предприятие использует многоуровневую систему логирования, которая охватывает различные аспекты работы кластера. Основными источниками данных являются технологический журнал (ТЖ), журнал регистрации событий и системные логи самого процесса rphost. Каждый из этих компонентов выполняет свою функцию: ТЖ фиксирует низкоуровневые события выполнения кода, журнал регистрации хранит историю действий пользователей, а системные логи отражают состояние процессов операционной системы.
Файлы технологического журнала по умолчанию располагаются в каталоге установки сервера, обычно это путь C:\Program Files\1cv8\srvinfo или аналогичный в Linux. Структура папок здесь иерархическая: сначала идет идентификатор кластера, затем — идентификатор рабочего процесса. Внутри этих директорий файлы могут достигать десятков гигабайт, если не настроено ограничение по размеру или времени жизни.
Важно отметить, что механизм записи в ТЖ отличается высокой производительностью, но требует значительных ресурсов дисковой подсистемы при включенном подробном логировании. Администрирование этих файлов должно быть приоритетной задачей, так как их рост экспоненциален при активном использовании системы. Без надлежащего контроля один сбойный процесс может заполнить весь диск за несколько часов.
⚠️ Внимание: Прямое удаление файлов технологического журнала во время работы сервера может привести к потере части диагностических данных, но обычно не вызывает сбоев в работе самого сервиса, так как процесс 1С открывает файлы заново при необходимости. Однако для журналов регистрации, работающих через СУБД, такой подход недопустим.
Используйте отдельный физический диск или раздел для размещения каталога srvinfo. Это изолирует рост логов от системного диска и предотвратит падение операционной системы при переполнении.
Настройка и очистка Технологического Журнала (ТЖ)
Технологический журнал является наиболее объемным источником данных, который требует регулярной чистки. Управление параметрами ТЖ осуществляется через файл logcfg.xml, расположенный в каталоге конфигурации сервера. Именно здесь задаются правила отбора событий, уровни детализации и, что самое важное, параметры ротации файлов.
Для корректной настройки необходимо отредактировать секцию history-size и history-time. Параметр history-size ограничивает количество хранимых файлов, а history-time — время их жизни в минутах. Отсутствие этих параметров приводит к бесконечному накоплению данных на диске.
<log>
<property name="log-location" value="C:\1CLogs\"/>
<property name="history-size" value="10"/>
<property name="history-time" value="1440"/>
</log>
После изменения конфигурации сервер 1С необходимо перезапустить службу, чтобы новые настройки вступили в силу. Стоит помнить, что включение логирования всех событий (*) без фильтров создает экстремальную нагрузку на дисковую подсистему. Рекомендуется использовать фильтры по конкретным исключениям или длительным транзакциям для снижения объема генерируемых данных.
- 📁 log-location: Указывает абсолютный путь к директории, где будут сохраняться файлы логов.
- 🔄 history-size: Определяет максимальное количество файлов, которые сервер будет хранить перед удалением старых.
- ⏳ history-time: Задает временной интервал, по истечении которого файлы считаются устаревшими и подлежат удалению.
Особенности работы ротации
Сервер 1С проверяет условия ротации только в момент записи новой порции данных. Если система простаивает, старые файлы могут не удаляться до момента следующей активности, даже если лимит времени истек.
Использование утилиты RAC для управления логами
Консольная утилита rac (Remote Administration Console) предоставляет мощный инструментарий для администрирования кластера серверов 1С без необходимости прямого доступа к файловой системе. С её помощью можно не только просматривать конфигурацию, но и инициировать процедуры очистки журналов регистрации программно.
Для очистки журналов регистрации используется команда clear-event-log. Эта операция безопасна и не требует остановки служб, так как работает на уровне метаданных базы конфигурации кластера. Команда позволяет очищать логи как для всего кластера, так и для конкретных информационных баз.
rac clear-event-log --cluster=cluster_id --base=base_idПри работе с RAC важно сначала получить идентификаторы кластера и баз данных. Это можно сделать с помощью команды rac cluster list и rac infobase summary. Автоматизация этого процесса через скрипты (bat, sh, ps1) позволяет включить очистку в расписание задач операционной системы.
Очистка журналов регистрации в базе данных
Журнал регистрации событий хранится непосредственно в базе данных конфигурации (таблица _Log и связанные таблицы). В отличие от файлов ТЖ, эти данные занимают место в файлах данных СУБД (MDF/LDF для MS SQL или аналогах для PostgreSQL). Простое удаление записей через интерфейс 1С может быть крайне медленным на больших объемах.
Наиболее эффективным методом является использование встроенного механизма очистки через конфигуратор или консольную команду. При удалении старых записей важно учитывать, что в MS SQL это может вызвать рост файла транзакций (LDF), если не выполнен сброс журнала транзакций СУБД afterwards.
Для больших систем рекомендуется выполнять очистку пакетами, чтобы не блокировать работу пользователей на длительное время. Журнал регистрации содержит критически важную информацию для аудита, поэтому перед массовой очисткой всегда следует создавать резервную копию или выгружать данные в внешний файл.
| Метод очистки | Скорость выполнения | Влияние на пользователей | Сложность реализации |
|---|---|---|---|
| Интерфейс 1С | Низкая | Высокое (блокировки) | Низкая |
| Консольная команда rac | Средняя | Среднее | Средняя |
| SQL-скрипт (TRUNCATE) | Высокая | Минимальное | Высокая |
| Обработчик в 1С | Низкая | Зависит от кода | Средняя |
⚠️ Внимание: Использование прямых SQL-запросов (DELETE/TRUNCATE) к таблицам журнала регистрации поддерживается фирмой 1С только в редких случаях и может нарушить целостность данных, если в базе используются механизмы ссылок на логи. Сверяйте возможность такого вмешательства в официальной документации для вашей версии платформы.
☑️ План безопасной очистки журналов
Автоматизация процесса через планировщик задач
Ручная очистка логов — это путь к неизбежным ошибкам и забытым процедурам. Надежная система должна работать автономно. В среде Windows для этого идеально подходит Планировщик заданий, а в Linux — демон cron. Сценарий должен включать проверку свободного места и запуск утилиты rac или скрипта удаления файлов.
Пример скрипта для Windows может сначала проверять возраст файлов в папке srvinfo и удалять те, что старше 7 дней, используя команду forfiles. Затем скрипт вызывает rac для очистки журналов регистрации. Такой комбинированный подход обеспечивает полную гигиену сервера.
Не забывайте про логирование самой процедуры очистки. Скрипт должен записывать факт своего запуска и результаты работы в отдельный файл, чтобы в случае проблем администратор мог понять, сработала ли автоматика. Отсутствие логов очистки может создать ситуацию, когда скрипт перестал работать месяц назад, а диски уже заполнены.
Автоматизация должна быть отказоустойчивой: если диск переполнен настолько, что скрипт не может записать свой лог, система должна отправлять критическое уведомление администратору через email или мессенджер.
Типичные ошибки и решение проблем
Одной из самых частых проблем является ситуация, когда файлы логов удалены через проводник, но место на диске не освободилось. Это происходит в Linux-средах, когда процесс rphost продолжает удерживать дескриптор удаленного файла. В таком случае необходимо отправить сигнал процессу или перезапустить службу systemctl restart srv1cv83.
Другая распространенная ошибка — настройка фильтров ТЖ на логирование каждого шага выполнения (call, context). Это приводит к тому, что объем логов растет в геометрической прогрессии, замедляя работу самого сервера из-за интенсивной записи на диск. Оптимизация фильтров должна быть первым шагом при диагностике проблем с производительностью.
Также стоит учитывать особенности работы с кластерами в режиме управляемых приложений. Некоторые события могут дублироваться в разных рабочих процессах, что увеличивает общий объем данных. Анализ дубликатов помогает сократить объем хранимой информации без потери смысла.
Можно ли отключить технологический журнал полностью?
Да, это можно сделать, удалив или переименовав файл logcfg.xml. Однако это крайне не рекомендуется для промышленных серверов, так как вы лишитесь главного инструмента диагностики сбоев и анализа производительности. Лучше настроить строгие фильтры.
Как очистить логи, если служба 1С не запускается из-за переполнения диска?
В этом случае нужно освободить место вручную через консоль операционной системы или загрузочный носитель. Удалите старые файлы из папки srvinfo, после чего служба сможет запуститься. Автоматическая очистка через rac в этом случае недоступна.
Влияет ли очистка журналов регистрации на скорость работы 1С?
Да, влияет положительно. Переполненная таблица логов замедляет выполнение запросов к базе данных и увеличивает время проведения документов. Регулярная очистка поддерживает высокую производительность системы.
Где хранятся логи кластера серверов 1С?
По умолчанию в подкаталоге srvinfo внутри директории установки сервера 1С. Путь можно изменить в настройках кластера или через реестр/конфигурационный файл в зависимости от ОС.
Нужно ли перезагружать сервер после настройки logcfg.xml?
Да, изменения в файле конфигурации технологического журнала применяются только после перезапуска службы сервера 1С:Предприятия. Без перезапуска будут использоваться старые параметры ротации.