Jedną z rzeczy, których nigdy nie widziałem, z powodów, których nie wyobrażam sobie, jest zmiana formatu pliku dziennika Apache na łatwiejszą do analizy wersję z informacjami, które są dla Ciebie ważne.
Na przykład nigdy nie używamy podstawowego uwierzytelniania HTTP, więc nie musimy rejestrować tych pól. Ja jestem ciekaw, jak długo każde żądanie zajmuje służyć, więc dodamy, że w. W jednym projekcie, chcemy też wiedzieć (na naszej równoważenia obciążenia) czy jakieś serwery służą żądania wolniej niż inni, więc zalogować nazwę serwera, do którego jesteśmy z powrotem proxy.
Oto fragment konfiguracji apache jednego serwera:
# We don't want to log bots, they're our friends
BrowserMatch Pingdom.com robot
# Custom log format, for testing
#
# date proto ipaddr status time req referer user-agent
LogFormat "%{%F %T}t %p %a %>s %D %r %{Referer}i %{User-agent}i" standard
CustomLog /var/log/apache2/access.log standard env=!robot
Nie można tak naprawdę powiedzieć, że między każdym polem znajduje się dosłowny znak tabulacji (\ t). Oznacza to, że jeśli chcę przeprowadzić analizę w Pythonie, być może pokażę na przykład statusy inne niż 200, mogę to zrobić:
for line in file("access.log"):
line = line.split("\t")
if line[3] != "200":
print line
Lub gdybym chciał zrobić „kto łączy obrazy na gorąco”? to byłby
if line[6] in ("","-") and "/images" in line[5]:
W przypadku adresów IP w dzienniku dostępu poprzedni przykład:
grep -o "[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}" logfile | sort -n | uniq -c | sort -n
staje się mniej więcej tak:
cut -f 3 log | uniq -c | sort -n
Łatwiejszy do odczytania i zrozumienia oraz znacznie mniej kosztowny obliczeniowo (bez wyrażenia regularnego), co w przypadku dzienników o pojemności 9 GB ma ogromną różnicę w zakresie czasu. Kiedy robi się to NAPRAWDĘ fajnie, jeśli chcesz zrobić to samo dla agentów użytkownika. Jeśli twoje dzienniki są rozdzielane spacjami, musisz ręcznie dopasować wyrażenie regularne lub wyszukać ciąg znaków. W tym formacie jest to proste:
cut -f 8 log | uniq -c | sort -n
Dokładnie tak samo jak powyżej. W rzeczywistości każde podsumowanie, które chcesz zrobić, jest dokładnie takie samo.
Dlaczego, u licha, miałbym spędzać procesor mojego systemu na awk i grep, kiedy cięcie zrobi dokładnie to, czego chcę rzędów wielkości szybciej?