У меня есть несколько файлов журнала 2-8 ГБ от службы, которую я использую. Обычно эти файлы журналов меньше этого (порядка 50-250 МБ).
Я хотел бы проанализировать их и обобщить их, чтобы узнать, что происходит.
Есть ли инструменты, которые помогут автоматизировать это, или, по крайней мере, дать первый проход? Я рассматриваю возможность использования head, awk, cut, grep и т.д., Но они не очень автоматические.
Вы пробовали спленк? http://www.splunk.com/
Я обнаружил, что комбинация grep , cut , sort , uniq , head и tail полезна для одноразовой проверки журнала.
Похоже, каждая строка начинается с даты / времени.
$ 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]
Я использую команду cut , говоря, чтобы она оставляла поля 3 и выше и использовала пробел в качестве разделителя.
$ 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]
У меня было предчувствие, что большинство лишних строк вывода будет иметь похожий текст, поэтому я обрезал вывод до первых 20 символов после отметки времени.
$ cut -f3- -d' ' porter10.log | cut -b-20 | head
-------- (Port Cont
-------- LOG BEGINS
Common DLL [Version
Message DLL [Version
Protocol DLL [Versio
Затем я отсортировал, посчитал и отсортировал счетчики, чтобы определить, какие линии встречались чаще всего.
Похоже, что моя наивная техника удаления меток времени урезала некоторую полезную (не метку времени) информацию в несколько строк, оставив вместо этого некоторые голые числа.
Тем не менее, похоже, что все они происходили с одинаковой частотой и на порядок чаще, чем что-либо еще, поэтому я нашел своих подозреваемых.
Диапазон из 20 символов - догадка, а не жесткое правило. Возможно, вам придется выполнить этот шаг несколько раз, чтобы найти точку, которая выделяет необычные линии.
$ 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)
Итак, теперь, когда у меня есть список потенциальных кандидатов, я могу искать их в контексте, используя grep и параметр -C# lines-of-context:
$ grep -C3 '(1555)' porter10.log | head 03/10/2011 12:14:25.455 looking for DLC devices / start Decoding tbl_pao_lite.cpp (107) Decoding tbl_base.cpp (111) Decoding dev_single.cpp (1555) Decoding dev_dlcbase.cpp (77) Decoding tbl_carrier.cpp (55) Decoding tbl_route.cpp (66) -- Decoding tbl_loadprofile.cpp (67) Decoding tbl_pao_lite.cpp (107)
Если вышеуказанный подход не работает, попробуйте посмотреть на разные места в файле.
Похоже, в этом файле около 1,6 миллиона строк, поэтому я посмотрел на строку 800k.
Это подтвердило результаты моего подхода сортировки и подсчета.
$ wc -l porter10.log 1638656 porter10.log $ head -800000 porter10.log | tail Decoding dev_dlcbase.cpp (77) Decoding tbl_carrier.cpp (55) Decoding tbl_route.cpp (66) Decoding dev_carrier.cpp (65)
В этом случае вывод произошел из-за того, что в наших файлах конфигурации остались лишние записи в журнале отладки.
Вам нужно будет настроить этот подход, чтобы он соответствовал вашему конкретному файлу журнала, но основные ключи:
Если вы хотите проанализировать ваш файл во время роста, вы можете получить отличный результат с logtop :
Наиболее запрашиваемый IP:
tail -f /var/log/apache2/access.log | cut -d' ' -f1 | logtop
Наиболее запрашиваемый URL (если URL-адрес 7-го поля, это ваш файл?)
tail -f /var/log/apache2/access.log | cut -d' ' -f7 | logtop