solução para girar arquivos de log

Question

Estou executando um processo daemon que terá que ser executado indefinidamente (um 'serviço', por assim dizer) e desejo registrar sua saída. Uma solução simples como:

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

... falha como o arquivo log.out :

• logo excede o tamanho que posso manipular facilmente com um editor de texto como emacs ou vi
• corre o risco de esgotar o espaço livre do sistema de arquivos.

Para manter o tamanho do arquivo de log gerenciável, eu poderia usar o comando split bash:

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

Essa solução mantém os arquivos de log criados gerenciáveis em tamanho, mas pode ficar sem sufixos ( split: output file suffixes exhausted ) ou, se o espaço do sufixo for enorme, também pode esgotar o espaço do sistema de arquivos.

Portanto, estou olhando para uma solução que gerará vários arquivos de log, com cada arquivo de log sendo gerenciável em tamanho, e também girará entre eles para que haja um teto no espaço total em disco que será reivindicado.

Existe tal solução disponível ou eu tenho que implementá-la no nível do aplicativo?

    

Answer 1

Para cortar os logs

O projeto Apache tem um comando útil rotatelogs projetado para girar a entrada recebida por meio de um canal de entrada. Leia sobre rotatelogs

Em seguida, há também a manipulação de tempo cronolog melhor. site do Cronolog

Mas se você também estiver girando, vale a pena considerar o logrotate, mas o logrotate precisará de um mecanismo para disparar um novo arquivo de log (enviar um sinal, reiniciar o programa, ...). É aqui que o rotatelogs / cronolog pode entrar, se você estiver registrando o stdout e não quiser reiniciar o processo.

    

Answer 2

A maioria das distribuições Linux modernas inclui uma ferramenta chamada logrotate , que o SO usa para manter o diretório /var/log . Você pode usá-lo também. Ele é expulso via cron , então se você quiser que os logs sejam rotacionados com uma certa frequência, então você precisa configurar um cronjob que seja executado com frequência.

Exemplos

Isto irá rodar os 2 ficheiros access.log & error.log , mantendo no máximo 5 (atual + 4 rotações). Depois de realocar o arquivo de log atual, killall -HUP httpd envia um sinal "Desligar" para o daemon em execução para acionar a criação de um novo arquivo de log para iniciar o registro a partir dos arquivos originais access.log e error.log . Este também irá rodar os arquivos de log se o tamanho deles exceder 100k.

   "/var/log/httpd/access.log" /var/log/httpd/error.log {
       rotate 5
       mail [email protected]
       size 100k
       sharedscripts
       postrotate
           /usr/bin/killall -HUP httpd
       endscript
   }

Este rotacionará os arquivos de log no diretório /var/log/news/* montly, mantendo 2 (atual + 1). Esse conjunto de regras manterá os logs em seu estado original, em vez de não serem compactados ( .gz ), que é o comportamento padrão.

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

Tenho que enviar kill -HUP?

Não, isso não é obrigatório, somente se seu aplicativo exigir isso. Isso é o que aciona o aplicativo para parar de gravar no arquivo de log atual (depois de ter sido renomeado de access.log para access.log.1 ) e começar a registrar novamente no nome original, access.log .

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

Referências

• HowTo: O último tutorial de comandos do Logrotate com 10 exemplos

Answer 3

pelo motivo de integralidade também gostaria de mencionar a opção copytruncate para 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.