решение вращать файлы журнала

Я запускаю процесс демона, который должен работать бесконечно (так сказать, «сервис»), и хочу записать его вывод. Простое решение, такое как:

./long-running-process > log.out & 

… терпит неудачу как файл log.out :

  • скоро превысит размер, который я могу легко обработать с помощью текстового редактора, такого как emacs или vi
  • рискует истощить свободное пространство файловой системы.

Чтобы сохранить размер файла журнала, я мог использовать команду split bash:

 ./long-running-process | split -l 30000 

Это решение сохраняет управляемые по размеру файлы журнала, однако оно может не содержать суффиксов ( split: output file suffixes exhausted ) или, если пространство суффиксов огромно, это также может привести к истощению пространства файловой системы.

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

Есть ли такое решение или мне нужно реализовать его на уровне приложений?

Рубить бревна

В проекте Apache есть полезная команда rotatelogs предназначенная для поворота ввода, полученного через канал ввода. Читать о rotatelogs

Тогда есть также cronolog лучше время обработки. Веб-сайт Cronolog

Но если вы также вращаетесь, то стоит рассмотреть logrotate, но logrotate потребуется механизм для запуска нового файла журнала (отправить сигнал, перезапустить программу, …). Именно здесь могут войти rotatelogs / cronolog, если вы регистрируете стандартный вывод и не хотите перезапускать процесс.

Большинство современных дистрибутивов Linux include инструмент под названием logrotate который ОС затем использует для поддержки каталога /var/log . Вы можете использовать это тоже. Он запускается через cron , поэтому, если вы хотите, чтобы журналы вращались с определенной частотой, вам нужно настроить cronjob, который запускается по крайней мере так часто.

Примеры

Это будет вращать 2 файла access.log & error.log , сохраняя максимум 5 (текущие + 4 вращения). После перемещения текущего файла журнала, killall -HUP httpd отправляет работающему демону сигнал «Зависание», чтобы инициировать создание нового файла журнала, чтобы с этого момента начать запись в исходные файлы access.log и error.log , Этот также будет вращать файлы журнала, если их размер превышает 100 КБ.

  "/var/log/httpd/access.log" /var/log/httpd/error.log { rotate 5 mail www@my.org size 100k sharedscripts postrotate /usr/bin/killall -HUP httpd endscript } 

Этот файл будет вращать файлы журнала в каталоге /var/log/news/* montly, сохраняя 2 (текущий + 1). Этот набор правил будет сохранять журналы в их первоначальном состоянии, скорее они не будут сжаты ( .gz ), что является поведением по умолчанию.

  /var/log/news/* { monthly rotate 2 olddir /var/log/news/old missingok postrotate kill -HUP `cat /var/run/inn.pid` endscript nocompress } 

Должен ли я отправить kill -HUP?

Нет, это не обязательно, только если ваша заявка требует этого. Это то, что заставляет ваше приложение прекратить запись в текущий файл журнала (после того, как он был переименован из, скажем, access.log в access.log.1 ) и снова начать запись в исходное имя, access.log .

 /var/log/atop/atop.log { missingok weekly rotate 4 notifempty create 0600 root root } 

Рекомендации

  • Как: Ultimate Logrotate Command Tutorial с 10 примерами

для полноты copytruncate я также хотел бы упомянуть опцию copytruncate для logrotate :

  copytruncate Truncate the original log file to zero size in place after creating a copy, instead of moving the old log file and optionally creating a new one. It can be used when some program cannot be told to close its logfile and thus might continue writing (appending) to the previous log file forever. Note that there is a very small time slice between copying the file and truncating it, so some logging data might be lost. When this option is used, the *create* option will have no effect, as the old log file stays in place.