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

Изменение способа ротации файлов журнала 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 удается заставить процесс писать в тот же файл, но я не могу использовать простые шаги.

решение1

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

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

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

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

решение2

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

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

рассмотреть возможность

Связанный контент