Как почистить логи сервера 1С и не потерять нужные данные

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

В инфраструктуре 1С обычно присутствуют четыре источника логов: журнал регистрации информационной базы (хранится в самой базе), технологический журнал сервера 1С (текстовые файлы на диске), журналы СУБД (PostgreSQL, MS SQL) и системные логи агента сервера. У каждого свой механизм очистки, и универсальной кнопки «удалить всё» нет — и это правильно, потому что журнал регистрации часто требуется для аудита и расследования инцидентов.

Какие логи есть у сервера 1С и где они лежат

Прежде чем что-то удалять, определите, что именно занимает место. Журнал регистрации хранится внутри информационной базы: в файловом варианте это отдельный каталог рядом с файлом 1Cv8.1CD, в клиент-серверном — данные в таблицах СУБД. Его размер не виден простым просмотром папок в клиент-серверном варианте, но косвенно оценивается по росту базы.

Технологический журнал — это каталоги с текстовыми файлами, которые сервер 1С пишет, если настроен файл logcfg.xml. По умолчанию на Linux-сервере они обычно лежат в каталоге данных кластера (как правило, /opt/1cv8 или в домашнем каталоге пользователя, под которым работает агент), на Windows — в каталоге srvinfo или в пути, указанном в конфигурации. Именно технологический журнал чаще всего «съедает» диск: при включённом полном логировании запросов он может писать гигабайты в сутки.

Отдельно стоят журналы СУБД: WAL-файлы PostgreSQL, журнал транзакций MS SQL, логи ошибок и медленных запросов. Их чистка выполняется средствами самой СУБД и по своим правилам — удалять файлы WAL вручную категорически нельзя.

Очистка журнала регистрации через конфигуратор

Штатный способ уменьшить журнал регистрации — функция сокращения в конфигураторе. Откройте базу в режиме конфигуратора, перейдите в меню «Администрирование» и выберите пункт «Настройка журнала регистрации». В открывшемся окне есть кнопка «Сократить», которая позволяет удалить все события до указанной даты.

Перед сокращением конфигуратор предложит сохранить удаляемую часть журнала в файл. Сделайте это обязательно: выгруженная копия занимает немного места, а при необходимости расследовать старое событие её можно будет открыть. Храните выгрузку вне сервера — например, в архивном каталоге файлового хранилища.

Учтите ограничение: сокращение журнала регистрации выполняется в монопольном режиме и на больших базах может занять значительное время. Планируйте операцию на нерабочие часы и предупредите пользователей. В клиент-серверном варианте после сокращения физический размер базы на диске может не уменьшиться сразу — для высвобождения места потребуется реорганизация таблиц средствами СУБД.

1. 1
   Сделайте резервную копию базы или хотя бы выгрузку журнала
2. 2
   Откройте базу в конфигураторе в монопольном режиме
3. 3
   Перейдите: Администрирование → Настройка журнала регистрации
4. 4
   Нажмите «Сократить», укажите дату, до которой удалить события
5. 5
   Отметьте сохранение удаляемой части в файл и укажите путь
6. 6
   Дождитесь завершения и проверьте, что журнал открывается и содержит нужный период

Настройка уровня регистрации событий

Чтобы журнал не пришлось чистить каждый месяц, сократите объём записываемых событий. В том же окне настройки журнала регистрации доступны уровни детализации: можно отключить регистрацию информационных сообщений, ошибок фоновых заданий или предупреждений, оставив только значимые события — изменение данных и доступ.

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

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

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

Технологический журнал управляется файлом logcfg.xml, который размещается в каталоге конфигурации кластера. Если логирование было включено для диагностики и забыли выключить — это самая частая причина переполнения диска. Проверьте наличие файла и содержащихся в нём настроек.

Чтобы остановить запись, отключите или сузьте конфигурацию: удалите файл logcfg.xml либо оставьте в нём только нужные события с ограничением глубины хранения. Изменения подхватываются сервером без полной переустановки, но для гарантированного применения агент сервера иногда перезапускают. После отключения старые каталоги с логами можно удалять вручную — это обычные текстовые файлы, на работу сервера их удаление не влияет.

Пример минимальной конфигурации с ограничением хранения логов по времени:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/var/log/1c/techlog" history="72">
    <event><eq property="name" value="EXCP"/></event>
    <property name="all"/>
  </log>
</config>

Параметр history задаёт глубину хранения в часах — сервер сам удаляет файлы старше указанного срока. Это ключевой механизм ротации: без него каталоги копятся бесконечно. Если технологический журнал нужен постоянно (например, для сбора ошибок), всегда задавайте history и следите, чтобы под каталог логов было выделено достаточно места.

Очистка логов СУБД: PostgreSQL и MS SQL

В PostgreSQL основной «пожиратель» диска — WAL-файлы в каталоге pg_wal. При правильно настроенной работе старые сегменты удаляются автоматически после контрольных точек. Если pg_wal растёт бесконечно, причина обычно в сломанной архивации, зависшей реплике или параметре wal_keep_size с избыточным значением. Решение — исправить причину, а не удалять файлы: ручное удаление WAL почти гарантированно разрушает кластер.

Текстовые логи ошибок PostgreSQL (каталог log внутри данных или отдельный путь из postgresql.conf) чистятся безопасно: старые файлы можно удалять или архивировать, либо настроить ротацию параметрами log_rotation_age и log_rotation_size. Также полезен внешний logrotate на уровне операционной системы.

В MS SQL журнал транзакций (.ldf) усекается при резервном копировании журнала в полной модели восстановления либо автоматически в простой модели. Если .ldf разросся, сделайте резервную копию журнала транзакций, а затем при необходимости сожмите файл через DBCC SHRINKFILE — но сжатие делайте разово, а не по расписанию, потому что регулярное сжатие фрагментирует файл и замедляет работу. Сами текстовые журналы ошибок SQL Server циклически перезаписываются и обычно не требуют вмешательства.

Автоматизация и профилактика

Разовая чистка решает симптом, но не причину. Чтобы ситуация не повторялась, настройте ротацию всего, что ротировать можно: history в logcfg.xml для технологического журнала, logrotate для текстовых логов Linux, регламентное резервное копирование журнала транзакций в MS SQL. Для журнала регистрации добавьте в календарь администратора регулярное сокращение с архивной выгрузкой.

Настройте мониторинг свободного места на дисках сервера 1С и СУБД с порогом предупреждения заранее, а не когда остались последние гигабайты. Простейший скрипт с проверкой заполнения и отправкой уведомления избавляет от большинства аварийных чисток «в пожарном порядке».

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

Как проверить результат очистки

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

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

По СУБД контрольный признак — стабилизация размера: pg_wal должен держаться в пределах ожидаемого объёма, а .ldf после усечения не должен снова стремительно расти. Если рост продолжается, проблема не в логах, а в настройках, и чистка повторится бесконечно.

Частые вопросы