É bom usar tail -f em arquivos de log grandes

Gostaria de monitorar um arquivo de log grande (próximo a 1 GB) quanto a erros. Eu quero que isso seja quase em tempo real (alguns segundos de atraso é bom). Meu plano é usar tail -f | grep. Há algum problema de desempenho ao usar esse método ao executá-lo por um longo período, digamos de zero bytes a 1 GB? Existem práticas padrões usadas para esse 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 ainda rola e eu tenho mais um problema para resolver :). using tail -F( --follow=name) não é uma opção para mim porque -Fnão é suportado no servidor em que desejo executar isso. Meu plano é usar um script que inicie essa cauda e faça uma pesquisa para descobrir se o arquivo está rolando. Se sim, então mate o rabo e reinicie-o. Alguma abordagem melhor?

logs monitoring tail

— Manoj NV
fonte

Você quer dizer "matar o tail", certo?

— Stéphane Gimenez

Sim, "matar cauda", não encontrar. Obrigado, editou a pergunta

— Manoj NV

Se um arquivo com tamanho de 2 GB não contém um novo caractere de linha, como funciona a cauda?

Respostas:

No meu sistema Linux (GNU coreutils 8.12), pude verificar (usando strace) se tail -f¹ usa a lseekchamada do sistema para pular a maior parte do arquivo rapidamente:

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 forma alguma.

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

-
^{1. Tentei também desativar o suporte para inotificar os não documentados ---disable-inotify, apenas por precaução.}

— Stéphane Gimenez
fonte

Homens reais leem a fonte (:

— Gilles 'SO- stop be evil'

@Gilles. Não posso ensinar ao OP (ou ao leitor) como ler a fonte, se ele ainda não souber. Muito mais fácil dizer a ele para usar strace;)

— Stéphane Gimenez

Na verdade, em um sistema onde tail -Fnão é suportado, as chances são de que stracenão está disponível ...

— Stéphane Gimenez

trussé o utilitário correspondente no Solaris.

— Gilles 'SO- stop be evil'

e mostra chamadas de busca semelhantes. llseek (0, 0, SEEK_CUR) = 0, llseek (0, 0xFFFFFFFFFFF5FFF6, SEEK_END) = 7923269

— jlliagre

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 seja chamada com -n +N) procuram o final do arquivo, depois trabalham para trás para encontrar a linha onde deve começar a imprimir. Não sei se o Solaris faz o mesmo, mas é uma abordagem razoável, por isso espero que a maioria das empresas faça o mesmo. Portanto, o tamanho do arquivo é irrelevante para o desempenho.

— Gilles 'SO- parar de ser mau'
fonte

Eu faço isso todos os dias. Geralmente, varro uma dúzia de logs nos nossos servidores de teste e produção usando tail -f logs/*.{log,err,out}. O carregamento 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, uso a execfuncionalidade, screenpois geralmente desejo ver toda a saída (para rastreamentos completos e mensagens relacionadas ao problema). Por exemplo,

!:sed -n s/.*Exception.*/\007/p

Para fazer o terminal emitir um bipe (ou piscar) sempre que a palavra Exceção for encontrada.

— Arcege
fonte