¿Está bien usar tail -f en archivos de registro grandes?

Me gustaría monitorear un archivo de registro grande (cerca de 1 GB) en busca de errores. Quiero que esto sea cercano al tiempo real (algunos segundos de retraso están bien). Mi plan es usar tail -f | grep. ¿Hay algún problema de rendimiento con el uso de este método cuando se ejecuta durante un tiempo prolongado, por ejemplo, de cero bytes a 1 GB? ¿Hay alguna práctica estándar utilizada para tal monitoreo? Tenga en cuenta que me gustaría hacer esto usando los comandos estándar de Unix disponibles en Solaris 10.

Si eso es posible, mi archivo incluso se da vuelta y tengo un problema más para resolver :). usar tail -F( --follow=name) no es una opción para mí porque -Fno es compatible con el servidor en el que quiero ejecutar esto. Mi plan es usar un script que comenzará esta cola y sondeará para encontrar si el archivo se reinicia. En caso afirmativo, elimine la cola y reiníciela. ¿Algún mejor enfoque?

En mi sistema Linux (GNU coreutils 8.12), pude comprobar (usando strace) que tail -f¹ usa la lseekllamada del sistema para omitir la mayor parte del archivo rápidamente:

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

Esto significa que el tamaño del archivo rastreado no debería importar de ninguna manera.

Tal vez pueda verificar si lo mismo se aplica en su sistema. (Obviamente, debería ser el caso).

-
^{1. También intenté deshabilitar el soporte de inotify con los indocumentados ---disable-inotify, por si acaso.}

Si se invoca en un archivo normal (a diferencia de una tubería), tanto la cola de GNU como la cola de OpenBSD (a menos que se llame con -n +N) buscan el final del archivo, luego funcionan hacia atrás para encontrar la línea donde debería comenzar a imprimir. No sé si Solaris hace lo mismo, pero es un enfoque razonable, por lo que espero que la mayoría de los unices hagan lo mismo. Por lo tanto, el tamaño del archivo es irrelevante para el rendimiento.

Hago esto todos los días. Generalmente escaneo una docena de registros en nuestros servidores de prueba y producción usando tail -f logs/*.{log,err,out}. La carga inicial es un poco demasiado (dependiendo del número de archivos globalizados), pero después de eso, la transmisión es en tiempo real.

En lugar de enviar a grep, uso la execfuncionalidad screenya que generalmente quiero ver toda la salida (para rastreos completos y mensajes relacionados con el problema). Por ejemplo,

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

Hacer que el terminal emita un pitido (o parpadee) cada vez que se encuentra la palabra Excepción.