큰 로그 파일에서 tail -f를 사용하는 것이 좋습니까?

오류가 있는지 큰 로그 파일 (1GB에 근접)을 모니터링하고 싶습니다. 나는 이것이 실시간에 가깝기를 원한다 (몇 초 지연이 좋다). 내 계획은 tail -f | grep입니다. 0 바이트에서 1GB와 같이 장시간 실행할 때 이러한 방법을 사용하는 데 성능 문제가 있습니까? 그러한 모니터링에 사용되는 표준 관행이 있습니까? Solaris 10에서 사용 가능한 표준 unix 명령을 사용하여이 작업을 수행하려고합니다.

가능하다면 파일이 롤오버되고 정렬하는 데 하나 더 문제가 있습니다. :). 이것을 실행하려는 서버에서 지원되지 않기 때문에 tail -F( --follow=name) 사용 은 옵션 -F이 아닙니다. 내 계획은이 꼬리를 시작하고 파일이 롤오버되었는지 확인하기 위해 폴링하는 스크립트를 사용하는 것입니다. 그렇다면 꼬리를 제거하고 다시 시작하십시오. 더 나은 접근법?

내 리눅스 시스템 (GNU coreutils 8.12)에서 ¹는 시스템 호출을 사용하여 대부분의 파일을 빠르게 건너 뛰는 strace것을 확인 (사용 ) 할 수있었습니다 .tail -flseek

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

이것은 추적 된 파일의 크기가 어쨌든 중요하지 않다는 것을 의미합니다.

시스템에 동일하게 적용되는지 확인할 수 있습니다. (당연히 그렇습니다.)

—
^{1. 또한 ---disable-inotify만일의 경우 를 위해 문서화되지 않은으로 inotify 지원을 비활성화하려고 시도했습니다 .}

파이프와는 달리 일반 파일에서 호출 된 경우 GNU tail과 OpenBSD tail은 (와 함께 호출되지 않는 한 -n +N) 파일 끝을 찾은 다음 거꾸로 작업하여 인쇄를 시작할 행을 찾습니다. 솔라리스가 똑같은지를 알지 못하지만 합리적인 접근 방식이므로 대부분의 유니스가 똑같이 할 것으로 기대합니다. 따라서 파일 크기는 성능과 관련이 없습니다.

나는 매일 이것을한다. 나는 일반적으로를 사용하여 테스트 및 프로덕션 서버에서 수십 개의 로그를 스캔합니다 tail -f logs/*.{log,err,out}. 초기로드는 (글로브 된 파일 수에 따라) 약간 많지만 그 후 스트리밍은 실시간입니다.

grep으로 보내는 대신 일반적으로 모든 출력 (문제와 관련된 전체 추적 및 메시지)을보고 싶기 때문에 exec기능을 사용합니다 screen. 예를 들어

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

예외라는 단어가 발견 될 때마다 터미널에서 경고음 (또는 깜박임)이 발생합니다.