Мое наблюдение за ротацией логов заключается в том, что для ротации любого файла журнала процесс logrotate выполняется в следующем порядке:
- копирует нужный файл журнала (назовем его file1.log) с новым именем (добавляя временную метку или номер к существующему имени, так что он становится file1.log-20140513),
- удаляет существующий файл (file1.log) и создает новый пустой файл журнала с исходным именем (file1.log),
- сжимает повернутый файл (file1.log-20140513), что создает новый сжатый файл (file1.log-20140513.gz), если установлена опция сжатия,
- удаляет повернутый файл (file1.log-20140513), и наконец,
- перейдите к следующему файлу и выполните для него те же 4 шага, что и выше.
У меня возникла следующая проблема с этим процессом:
- Мои файлы журналов имеют огромный размер (более 10 ГБ каждый), и у меня около 42 таких файлов журналов.
- Процессы, которые записывают в эти файлы, работают синхронно,
- DiskIO на сервере хорош, но все равно копирование занимает время, сжатие также занимает время, а сжатие также потребляет ресурсы ЦП.
- Я хочу, чтобы все вновь созданные файлы журналов начинались с одного и того же времени.
Для этого я хочу, чтобы logrotate перемещал файлы, что делает команда mv, которая переименовывает файлы вместо их копирования. Что касается сжатия, я могу отключить его и запустить его через другой скрипт, запланированный через cron. Но я хочу, чтобы logrotate перемещал файлы вместо их копирования.
Теперь я уверен, что авторы logrotate тоже об этом подумали, поскольку это, очевидно, экономит дисковый ввод-вывод и время, необходимое для выполнения всей операции logrotate, поэтому я хочу узнать, почему файлы копируются, а не перемещаются или переименовываются, и как этого добиться с помощью logrotate.
ПРИМЕЧАНИЕ: Я попытался сделать это вручную, то есть переместить файл, в который также писал запущенный процесс, и создать новый пустой файл с тем же именем и теми же разрешениями (которые являются root, что также является разрешением, с которым запущен процесс), но после перемещения и создания нового файла я увидел, что процесс ничего в него не пишет, поэтому пришлось перезапустить процесс, чтобы он записал в этот файл. Может ли кто-нибудь объяснить это поведение, почему logrotate удается заставить процесс писать в тот же файл, но я не могу использовать простые шаги.
решение1
Описанное вами поведение происходит только в том случае, если logrotate явно указано сделать это через copytruncate
директиву. Документация предупреждает о возможности потери некоторых данных журнала из-за такого поведения. Эту директиву следует использовать только в крайнем случае.
Стандартный метод ротации лог-файлов — переименовать и затем отправить сигнал процессу, чтобы он открыл новый лог-файл. Это быстрее и не приводит к риску потери части лога. Но это требует, чтобы процесс записи мог переключиться на новый лог-файл.
Сжатие можно отключить или отложить до следующей ротации. Если директива compress
используется, старые файлы журналов сжимаются. Если эта директива не используется, они не сжимаются.
Если используются оба compress
и delaycompress
, сжатие откладывается до следующей ротации. Таким образом, после каждой ротации два новейших файла журнала еще не будут сжаты.
решение2
после перемещения и создания нового файла я увидел, что процесс ничего в него не записывает, поэтому пришлось перезапустить процесс, чтобы он записал в этот файл
Процесс пишет в тот же файл, поэтому lograte копирует вместо перемещения. Когда вы удаляете журнал, процесс все равно пишет в журнал, и вы видите, что использование файловой системы растет, но файла нет. Перезапуск процесса освободит место на диске.
рассмотреть возможность
- меньше записывайте в журналы, вся ли регистрируемая информация необходима?
- прочитайте документацию, например:http://www.thegeekstuff.com/2010/07/logrotate-examples/