☰

대용량 로그 파일에 tail -f를 사용해도 되나요?

tag-icon • tag-icon logs monitoring tail
대용량 로그 파일에 tail -f를 사용해도 되나요?

오류가 있는지 대용량 로그 파일(1GB에 가깝습니다)을 모니터링하고 싶습니다. 나는 이것이 실시간에 가깝기를 바랍니다(몇 초 정도 지연해도 괜찮습니다). 내 계획은 을 사용하는 것입니다 tail -f | grep. 장기간(예: 0바이트에서 1GB까지) 실행할 때 이 접근 방식을 사용하면 성능 문제가 있습니까? 이러한 유형의 모니터링에 대한 표준 관행이 있습니까? 이 작업을 수행하려면 Solaris 10에서 사용할 수 있는 표준 Unix 명령을 사용하고 싶습니다.

가능하다면 내 파일이 스크롤될 수도 있지만 여전히 해결해야 할 문제가 있습니다 :). tail -F( )를 사용하는 것은 내가 실행하려는 서버가 이를 지원하지 않기 --follow=name때문에 나에게 옵션이 아닙니다 . -F내 계획은 이 테일을 시작하고 파일이 스크롤되었는지 확인하기 위해 폴링하는 스크립트를 사용하는 것입니다. 그렇다면 tail을 종료하고 다시 시작하십시오. 더 좋은 방법이 있나요?

답변1

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

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

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

아마도 이것이 귀하의 시스템에서 작동하는지 확인할 수 있습니다. (물론 그래야 할 것 같습니다.)

— 1. 만일을 대비해
undocumented 를 사용하여 inotify 지원을 비활성화해 보았습니다 .---disable-inotify

답변2

(파이프가 아닌) 일반 파일에서 호출하는 경우 GNU tail과 OpenBSD tail(tail을 사용하여 호출하지 않는 한 -n +N)은 모두 파일의 끝을 찾은 다음 인쇄가 시작되어야 하는 줄에서 거꾸로 찾습니다. 솔라리스도 이 작업을 수행하는지 모르겠지만 이는 합리적인 접근 방식이므로 대부분의 unices도 동일한 작업을 수행할 것으로 예상됩니다. 따라서 파일 크기는 성능과 아무런 관련이 없습니다.

답변3

나는 매일 이것을 한다. 저는 일반적으로 테스트 및 프로덕션 서버에서 12개의 로그를 검색합니다 tail -f logs/*.{log,err,out}. 초기 로딩은 좀 무거우나(글로벌 파일 개수에 따라), 이후 스트리밍은 실시간으로 이루어집니다.

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

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

"예외"라는 단어가 발견될 때마다 터미널에서 경고음을 울리거나 깜박이게 만듭니다.

관련 정보