É bom usar tail -f em grandes arquivos de log

Question

Gostaria de monitorar um arquivo de log grande (próximo a 1 GB) para erros. Eu quero que isso seja perto do tempo real (alguns segundos de atraso são bons). Meu plano é usar tail -f | grep . Existe algum problema de desempenho ao usar esse método ao executá-lo por um longo período, digamos de zero bytes a 1 GB? Existe alguma prática de padrões usada para tal monitoramento? Observe que eu gostaria de fazer isso usando comandos unix padrão disponíveis no Solaris 10.

Se isso for possível, meu arquivo será revertido e eu tenho mais um problema para resolver :). usar tail -F ( --follow=name ) não é uma opção para mim porque -F não é suportado no servidor em que quero executar. Meu plano é usar um script que inicie essa cauda e faça uma pesquisa para descobrir se o arquivo está rolando. Se sim, mate a cauda e reinicie-a. Qualquer melhor abordagem?

    

Answer 1

No meu sistema linux (GNU coreutils 8.12), eu pude verificar (usando strace ) que tail -f ¹ usa a chamada do sistema lseek para pular rapidamente a maior parte do arquivo:

lseek(3, 0, SEEK_CUR)                   = 0
lseek(3, 0, SEEK_END)                   = 194086
lseek(3, 188416, SEEK_SET)              = 188416

Isso significa que o tamanho do arquivo rastreado não deve importar de qualquer maneira.

Talvez você possa verificar se o mesmo se aplica ao seu sistema. (Obviamente, deve ser o caso.)

-
^{1. Eu também tentei desabilitar o suporte ao inotify com o ---disable-inotify não documentado, apenas no caso.}

    

Answer 2

Se for invocado em um arquivo regular (em oposição a um pipe), tanto a cauda GNU quanto a cauda do OpenBSD (a menos que sejam chamadas com -n +N ) buscam o final do arquivo, então retrocederão para encontrar a linha onde deveria começar a imprimir. Eu não sei se o Solaris faz o mesmo, mas é uma abordagem razoável, então eu espero que a maioria dos unives faça o mesmo. Portanto, o tamanho do arquivo é irrelevante para o desempenho.

    

Answer 3

Eu faço isso todos os dias. Eu geralmente escaneio uma dúzia de logs em nossos servidores de teste e produção usando tail -f logs/*.{log,err,out} . A carga inicial é um pouco demais (dependendo do número de arquivos globbed), mas depois disso, o streaming é em tempo real.

Em vez de enviar para o grep, eu uso a funcionalidade exec em screen , pois eu geralmente vejo toda a saída (para tracebacks completos e mensagens relacionadas ao problema). Por exemplo,

!:sed -n s/.*Exception.*/
!:sed -n s/.*Exception.*/%pre%7/p
7/p

Para fazer com que o terminal bipe (ou pisque) sempre que a palavra Exceção for encontrada.