Назад | Перейти на главную страницу

Изменение способа по умолчанию для LogRotate ротации файлов журнала

Мое наблюдение за логротацией заключается в том, что для ротации любого файла журнала процесс logrotate выполняется в следующем порядке

  1. копирует рассматриваемый файл журнала (давайте назовем его file1.log) с новым именем (добавив отметку времени или номер к существующему имени, чтобы оно стало file1.log-20140513),
  2. удаляет существующий файл (file1.log) и создает новый пустой файл журнала с исходным именем (file1.log),
  3. сжимает повернутый файл (file1.log-20140513), который создает новый сжатый файл (file1.log-20140513.gz), если установлена ​​опция сжатия,
  4. удаляет повернутый файл (file1.log-20140513) и, наконец,
  5. перейти к следующему файлу, чтобы проделать с ним то же самое, что и выше 4 шага.

У меня возникла следующая проблема с этим процессом:

  1. Мои файлы журналов огромны по размеру (более 10 ГБ каждый), и у меня есть около 42 таких файлов журналов.
  2. Процессы, которые записывают в эти файлы, работают синхронно,
  3. DiskIO на сервере хорош, но, тем не менее, копирование требует времени, и сжатие также требует времени, а сжатие также потребляет ресурсы ЦП.
  4. Я хочу, чтобы все вновь созданные файлы журналов имели журналы, начиная с одного и того же времени.

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

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

ПРИМЕЧАНИЕ: я попытался сделать это вручную, а именно переместить файл, в который также записывал запущенный процесс, и создать новый пустой файл с тем же именем и такими же разрешениями (который является root, который также является разрешением, которое процесс работает с), но после перемещения и создания нового файла я увидел, что процесс ничего не записывает в него, поэтому пришлось перезапустить процесс, чтобы он записал в этот файл. Может ли кто-нибудь объяснить это поведение, почему logrotate удается заставить процесс записывать в тот же файл, но я не могу использовать простые шаги.

Поведение, которое вы описываете, происходит только в том случае, если logrotate явно указано сделать это через copytruncate директива. Документация предупреждает о возможности потери некоторых данных журнала из-за такого поведения. Эту директиву следует использовать только в крайнем случае.

Стандартный метод ротации файлов журнала - это переименовать, а затем послать сигнал процессу, чтобы он открыл новый файл журнала. Это быстрее и без риска потери части журнала. Но для этого требуется, чтобы в процессе записи можно было переключиться на новый файл журнала.

Компрессию можно отключить или отложить до следующего вращения. Если compress используется директива, старые файлы журналов сжимаются. Если эта директива не используется, они не сжимаются.

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

после перемещения и создания нового файла я увидел, что процесс ничего не записывает в него, поэтому пришлось перезапустить процесс, чтобы он записал в этот файл

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

считать