Czy dobrze jest używać tail -f do dużych plików dziennika

Chciałbym monitorować duży plik dziennika (blisko 1 GB) pod kątem błędów. Chcę, aby było to blisko czasu rzeczywistego (kilka sekund opóźnienia jest w porządku). Mój plan to wykorzystanie tail -f | grep. Czy są jakieś problemy z wydajnością przy stosowaniu takiej metody, gdy jest ona uruchomiona przez długi czas, np. Od zera do 1 GB? Czy istnieją jakieś standardowe praktyki stosowane do takiego monitorowania. Zauważ, że chciałbym to zrobić za pomocą standardowych poleceń unix dostępnych w systemie Solaris 10.

Jeśli to możliwe, mój plik nawet przewraca się i mam jeszcze jeden problem do rozwiązania :). using tail -F( --follow=name) nie jest dla mnie opcją, ponieważ -Fnie jest obsługiwane na serwerze, na którym chcę to uruchomić. Moim planem jest użycie skryptu, który uruchomi ten ogon i sonduje, aby sprawdzić, czy plik jest zwinięty. Jeśli tak, zabij ogon i uruchom go ponownie. Jakieś lepsze podejście?

logs monitoring tail

— Manoj NV
źródło

Masz na myśli „zabić tail”, prawda?

— Stéphane Gimenez,

Tak, „zabij ogonem”, nie znajdź. Dzięki, zredagowałem pytanie

— Manoj NV,

Jeśli plik o rozmiarze 2 GB nie zawiera nowego znaku linii, jak działa tail?

Odpowiedzi:

W moim systemie Linux (GNU coreutils 8.12) mogłem sprawdzić (za pomocą strace), że tail -f¹ używa lseekwywołania systemowego do szybkiego pominięcia większości plików:

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

Oznacza to, że rozmiar śledzonego pliku i tak nie powinien mieć znaczenia.

Może możesz sprawdzić, czy to samo dotyczy twojego systemu. (Oczywiście tak powinno być.)

-
^{1. Próbowałem również wyłączyć obsługę inotify ---disable-inotifyw przypadku nieudokumentowanych , na wszelki wypadek.}

— Stéphane Gimenez
źródło

Prawdziwi ludzie czytają źródło (:

— Gilles 'SO- przestań być zły'

@Gilles. Nie mogę nauczyć OP (lub czytelnika), jak czytać źródło, jeśli jeszcze nie wie. O wiele łatwiej jest mu powiedzieć, żeby używał strace;)

— Stéphane Gimenez,

W rzeczywistości w systemie, który tail -Fnie jest obsługiwany, są szanse, że stracenie będzie dostępny…

— Stéphane Gimenez

trussjest odpowiednim narzędziem w systemie Solaris.

— Gilles „SO- przestań być zły”

i pokazuje podobne wywołania wyszukiwania. llseek (0, 0, SEEK_CUR) = 0, llseek (0, 0xFFFFFFFFFFF5FFF6, SEEK_END) = 7923269

— jlliagre

Jeśli jest wywoływany na zwykłym pliku (w przeciwieństwie do potoku), zarówno GNU, jak i OpenBSD (jeśli nie są wywoływane z -n +N) szukają końca pliku, a następnie działają wstecz, aby znaleźć linię, w której powinien rozpocząć drukowanie. Nie wiem, czy Solaris robi to samo, ale jest to rozsądne podejście, więc spodziewam się, że większość jednorożców zrobi to samo. Dlatego rozmiar pliku nie ma znaczenia dla wydajności.

— Gilles „SO- przestań być zły”
źródło

Robię to codziennie. Generalnie skanuję kilkanaście dzienników na naszych serwerach testowych i produkcyjnych tail -f logs/*.{log,err,out}. Początkowe ładowanie jest nieco większe (w zależności od liczby globowanych plików), ale potem strumieniowanie odbywa się w czasie rzeczywistym.

Zamiast wysyłać do grep, używam tej execfunkcji, screenponieważ chcę ogólnie zobaczyć wszystkie dane wyjściowe (w celu uzyskania pełnych informacji zwrotnych i komunikatów związanych z problemem). Na przykład,

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

Powoduje, że terminal emituje sygnał dźwiękowy (lub miga) za każdym razem, gdy zostanie znalezione słowo Wyjątek.

— Arcege
źródło