Znalazłem, że kombinacja grep
, cut
, sort
, uniq
, head
, i tail
są pomocne dla dziennika inspekcji, jednorazowej ad-hoc.
Sprawdź górę pliku dziennika
Wygląda na to, że każda linia zaczyna się od daty / godziny.
$ head porter10.log
03/10/2011 12:14:25 -------- (Port Control [Version 5.2 (Milestone 4)]) --------
03/10/2011 12:14:25 -------- LOG BEGINS --------
03/10/2011 12:14:25 Common DLL [Version 5.2 (Milestone 4)] [Version Details: 5.2.4]
03/10/2011 12:14:25 Message DLL [Version 5.2 (Milestone 4)] [Version Details: 5.2.4]
Usuń znacznik czasu
Korzystam z cut
polecenia, aby zachować pola 3 i nowsze oraz użyć spacji jako separatora.
$ cut -f3- -d' ' porter10.log | head
-------- (Port Control [Version 5.2 (Milestone 4)]) --------
-------- LOG BEGINS --------
Common DLL [Version 5.2 (Milestone 4)] [Version Details: 5.2.4]
Message DLL [Version 5.2 (Milestone 4)] [Version Details: 5.2.4]
Przytnij do niezmiennej części linii
Miałem przeczucie, że większość nadmiarowych wierszy wyjściowych będzie miała podobny tekst, więc przyciąłem wynik do pierwszych 20 znaków po znaczniku czasu.
$ cut -f3- -d' ' porter10.log | cut -b-20 | head
-------- (Port Cont
-------- LOG BEGINS
Common DLL [Version
Message DLL [Version
Protocol DLL [Versio
Sortuj i znajdź największe liczby
Następnie posortowałem, policzyłem i posortowałem liczby, aby znaleźć, które linie występowały najczęściej.
Wygląda na to, że moja naiwna technika usuwania znaczników czasu narzuciła kilka użytecznych (niezwiązanych ze znacznikiem czasu) informacji w kilku liniach, pozostawiając mi raczej nagie liczby.
Wygląda jednak na to, że wszystkie występowały z tą samą częstotliwością i rzędem wielkości częściej niż cokolwiek innego, więc znalazłem moich podejrzanych.
Zasięg 20 znaków to przeczucie, a nie trudna zasada. Być może trzeba będzie uruchomić ten krok wiele razy, aby znaleźć najsłodsze miejsce oddzielające niezwykłe linie.
$ cut -f3- -d' ' porter10.log | cut -b-20 | sort | uniq -c | sort -n
13827 Error (266) to Remot
13842 Error decode for dev
17070 Error Writing to Ret
46506 **** Checkpoint ****
181820 (65)
181820 (67)
181821 (111)
181821 (1555)
181821 (55)
181821 (66)
181821 (77)
181980 (107)
Szukaj kandydatów w kontekście
Teraz, gdy mam już listę potencjalnych kandydatów, mogę ich szukać w kontekście przy użyciu grep
opcji -C#
linii kontekstu:
$ grep -C3 '(1555)' porter10.log | głowa
03/10/2011 12: 14: 25.455 szuka urządzeń DLC / start
Dekodowanie tbl_pao_lite.cpp (107)
Dekodowanie tbl_base.cpp (111)
Dekodowanie dev_single.cpp (1555)
Dekodowanie dev_dlcbase.cpp (77)
Dekodowanie tbl_carrier.cpp (55)
Dekodowanie tbl_route.cpp (66)
-
Dekodowanie tbl_loadprofile.cpp (67)
Dekodowanie tbl_pao_lite.cpp (107)
Podejście Monte-Carlo - sprawdź środek pliku dziennika
Jeśli powyższe podejście nie działa, spróbuj spojrzeć na różne miejsca w pliku.
Wygląda na to, że w tym pliku znajduje się około 1,6 miliona linii, więc spojrzałem na linię 800k.
Potwierdziło to wyniki mojego podejścia sortowania i liczenia.
$ wc -l porter10.log
1638656 porter10.log
głowa $ -800000 porter10.log | ogon
Dekodowanie dev_dlcbase.cpp (77)
Dekodowanie tbl_carrier.cpp (55)
Dekodowanie tbl_route.cpp (66)
Dekodowanie dev_carrier.cpp (65)
Powodzenie!
W tym przypadku wynik był spowodowany pozostawieniem nadmiaru rejestrowania debugowania w naszych plikach konfiguracyjnych.
Konieczne będzie dostosowanie tego podejścia do konkretnego pliku dziennika, ale główne klucze to:
- Przytnij znaczniki czasu
- Przytnij do pewnej części linii, która prawdopodobnie nie ulegnie zmianie
- Sortuj i policz, co zostało
- Szukaj największych przestępców w kontekście