Очистка журналов на сервере 1С: что можно удалять, а что нет

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

Перепутаете — потеряете то, что нужно для расследований, или оставите гигабайты мусора. Сначала определите, какой из журналов разросся, потом выбирайте способ. Ниже — от безопасного к радикальному.

Найдите, что именно занимает место

Начните с замера. Откройте проводник или консоль на сервере и посмотрите размеры каталогов.

Где лежит журнал регистрации

Журнал регистрации хранится в каталоге кластера серверов, по умолчанию это srvinfo. Внутри — папки вида reg_1541, где число означает порт менеджера кластера. В ней — подпапки с идентификаторами информационных баз, а в каждой из них каталог 1Cv8Log.

Типичный путь в Windows выглядит так: C:\Program Files\1cv8\srvinfo\reg_1541\<идентификатор базы>\1Cv8Log. На Linux каталог srvinfo обычно лежит в домашней папке пользователя usr1cv8.

В 1Cv8Log вы увидите файлы трёх типов:

• 📄 .lgp — сами записи журнала, именно они занимают основной объём;
• 📄 .lgf — справочная часть (пользователи, компьютеры, события);
• 📄 .lgx — индексный файл.

Как понять, какая из баз разрослась: идентификаторы папок совпадают с идентификаторами баз в консоли администрирования кластера. Сравните размеры 1Cv8Log в разных папках — лидер сразу виден.

Где лежит технологический журнал

Технологический журнал по умолчанию не пишется вообще. Он включён только если в каталоге conf платформы (обычно рядом с каталогом установки 1cv8) есть файл logcfg.xml. Путь записи указан в нём в атрибуте location.

Если файла нет, а место всё равно уходит, смотрите в другое: дампы аварийных завершений, файлы кеша, папки временных данных. К журналам они не относятся.

Что трогать нельзя

В каталоге кластера лежат файлы, похожие на мусор, но им не являющиеся. Список кластера (1cv8wsrv.lst), файлы с описанием баз и контекстов сеансов удалять не нужно. Потеряете их — кластер придётся настраивать заново.

Что ещё съедает диск рядом с журналами

Прежде чем резать журналы, проверьте соседей. Часто виноваты не они:

• 💾 дампы аварийных завершений рабочих процессов: каждый может весить сотни мегабайт;
• 💾 локальные копии баз и выгрузки .dt, оставленные «на всякий случай»;
• 💾 файлы кеша и временные каталоги сервера;
• 💾 журналы самой операционной системы и СУБД, если база клиент-серверная.

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

Сократите журнал регистрации штатно

Это самый безопасный способ: платформа сама удаляет старые записи и не оставляет битых файлов.

Через конфигуратор

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

Название пунктов немного различается по версиям платформы. Если не нашли с первого раза, ищите по слову «журнал» в меню «Администрирование».

Если архив нужен

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

Сколько хранить

Единого срока нет, но есть рабочие ориентиры:

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

Как оценить, что чистка прошла

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

Настройте ротацию, чтобы не чистить вручную

Чистить раз в полгода — значит каждый раз бороться с последствиями. Лучше ограничить рост заранее.

Период разделения журнала регистрации

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

Мелкие файлы удобнее: старые периоды можно архивировать или удалять по одному, не трогая текущий.

Ротация технологического журнала

В технологическом журнале ротация задаётся в самом logcfg.xml атрибутом history в элементе log. Значение — число часов, которые хранятся файлы. По истечении срока платформа удаляет старое сама.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\1clogs\excp" history="24">
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Здесь пишутся только события исключений и хранятся сутки. Если нужен запас на выходные, ставьте history="72". Каталог из location лучше вынести на отдельный диск: если журнал вдруг разрастётся, он не забьёт системный раздел.

Уменьшите детализацию записи

Лучшая чистка — та, которой не пришлось заниматься. Если технологический журнал растёт на гигабайты в час, значит, вы пишете слишком много.

Что проверить в logcfg.xml:

• ✅ нужны ли вам все события (<property name="all"/> пишет максимум свойств для каждого события);
• ✅ не включены ли события CALL, SDBL, DBMSSQL без фильтра по длительности — на живой базе они дают огромный поток;
• ✅ не забыли ли вы выключить отладочную настройку после расследования.

Типичная история: администратор включил подробный журнал на сутки для поиска причины тормозов, а выключить забыл. Через месяц диск заполнен. Привычка простая: сразу в момент включения заносите в календарь дату отключения.

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

Фильтр по длительности выглядит так:

<event>
  <eq property="name" value="DBMSSQL"/>
  <ge property="duration" value="1000000"/>
</event>

Значение duration указывается в микросекундах, то есть 1000000 — одна секунда. В журнал попадут только запросы, выполнявшиеся дольше секунды.

Удалите старые файлы вручную

Ручное удаление подходит для технологического журнала и для аварийных случаев, когда диск уже забит и штатный способ не запускается.

Технологический журнал

Файлы технологического журнала — обычные текстовые .log, разложенные по подпапкам процессов. Их безопасно удалять, потому что платформа лишь создаёт новые. Удалять лучше не всё подряд, а старше нужного срока. Свежие файлы часто открыты процессами, и система не даст удалить их, это нормально.

Порядок действий:

1. Определите каталог из location в logcfg.xml.
2. Отсортируйте файлы по дате изменения.
3. Удалите те, что старше, скажем, недели.
4. Если место не освободилось, проверьте корзину и теневые копии тома.

Журнал регистрации

Здесь осторожнее. Файлы .lgp и .lgf связаны между собой, и если убрать только часть, журнал перестанет открываться или покажет пустой период. Если история вам не нужна совсем, допустим радикальный вариант:

1. Выведите пользователей из базы и запретите вход.
2. Сделайте копию каталога 1Cv8Log на другой диск.
3. Удалите содержимое каталога 1Cv8Log целиком.
4. Откройте базу и проверьте, что журнал создаётся заново.

Не удаляйте отдельные .lgp-файлы выборочно: это самый частый способ сломать журнал так, что он перестаёт открываться.

Утилиты и сторонние инструменты

В инструкциях в сети иногда встречается упоминание утилиты chlogfile. В составе платформы 1С я такой программы не знаю, а проверить её происхождение в интернете проще, чем потом разбираться, что она сделала с файлами. Запускать неизвестный бинарник на рабочем сервере с доступом к базам не стоит.

Что реально есть под рукой:

Для разбора сторонними средствами копируйте журнал на отдельную машину, а не запускайте инструменты на боевом сервере.

Автоматизируйте чистку скриптом

Раз в неделю заходить на сервер и чистить руками никто не будет. Задача хорошо ложится на планировщик.

PowerShell на Windows

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

$path = "D:\1clogs"
$limit = (Get-Date).AddDays(-7)

$old = Get-ChildItem -Path $path -Recurse -File |
       Where-Object { $_.LastWriteTime -lt $limit }

$size = ($old | Measure-Object -Property Length -Sum).Sum / 1MB
$old | Remove-Item -Force -ErrorAction SilentlyContinue

"{0}: удалено {1} файлов, {2:N0} МБ" -f (Get-Date), $old.Count, $size |
    Add-Content "D:\1clogs\clean.txt"

Запустите его сначала с -WhatIf у Remove-Item, чтобы убедиться, что под выборку попадают только нужные файлы. Только потом добавляйте в «Планировщик заданий» запуск раз в сутки ночью.

Bash на Linux

На Linux хватает одной команды в cron:

find /var/log/1c -type f -name "*.log" -mtime +7 -delete

Перед первым запуском замените -delete на -print и посмотрите, что будет удалено.

Контроль места на диске

Чистка не заменяет мониторинг. Настройте оповещение, когда на разделе с журналами остаётся меньше 15–20% свободного места. Тогда вы заметите рост за дни, а не в момент, когда сервер встал. Для проверки подойдёт любой мониторинг, который у вас уже есть: Zabbix, встроенные оповещения Windows или простой скрипт с отправкой письма.

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