Можно ли использовать tail -f для больших файлов журналов?

Я хотел бы контролировать большой файл журнала (около 1 ГБ) на наличие ошибок. Я хочу, чтобы это было близко к реальному времени (задержка в несколько секунд - это хорошо). Мой план заключается в использовании tail -f | grep. Есть ли проблемы с производительностью при использовании такого метода при его длительном запуске, скажем, от нуля байтов до 1 ГБ? Существуют ли стандарты практики, используемые для такого мониторинга. Обратите внимание, что я хотел бы сделать это, используя стандартные команды Unix, доступные в Solaris 10.

Если это возможно, мой файл даже переворачивается, и у меня есть еще одна проблема, чтобы разобраться :). использование tail -F( --follow=name) не вариант для меня, потому что -Fне поддерживается на сервере, на котором я хочу запустить это. Мой план состоит в том, чтобы использовать скрипт, который запустит этот хвост и опросит, чтобы определить, перевернут ли файл. Если да, то убейте хвост и перезапустите его. Есть ли лучший подход?

В моей системе Linux (GNU coreutils 8.12) я смог проверить (используя strace), что tail -f¹ использует lseekсистемный вызов, чтобы быстро пропустить большую часть файла:

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

Это означает, что размер отслеживаемого файла в любом случае не должен иметь значения.

Может быть, вы можете проверить, применяется ли то же самое в вашей системе. (Очевидно, так и должно быть.)

-
^{1. Я также попытался отключить поддержку inotify с недокументированными ---disable-inotify, на всякий случай.}

Если он вызывается в обычном файле (в отличие от канала), хвост GNU и хвост OpenBSD (если не вызывается с помощью -n +N) ищут конец файла, а затем работают в обратном направлении, чтобы найти строку, с которой он должен начать печать. Я не знаю, делает ли Solaris то же самое, но это разумный подход, поэтому я ожидаю, что большинство объединений сделают то же самое. Поэтому размер файла не имеет значения для производительности.

Я делаю это каждый день. Я обычно сканирую около десятка журналов на наших тестовых и производственных серверах, используя tail -f logs/*.{log,err,out}. Начальная загрузка немного велика (в зависимости от количества файлов, сгруппированных), но после этого потоковая передача осуществляется в режиме реального времени.

Вместо отправки в grep, я использую execфункциональность, screenтак как я хочу, как правило, видеть все выходные данные (для полных трассировок и сообщений, связанных с проблемой). Например,

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

Вызывать звуковой сигнал (или мигание) терминала при каждом обнаружении слова Exception.