У меня есть несколько файлов журнала 2-8 ГБ из службы, которую я запускаю. Обычно эти файлы журнала меньше этого (больше порядка 50-250 МБ).
Я хотел бы проанализировать их и суммировать их, чтобы выяснить, что происходит.
есть ли какие-либо инструменты, чтобы помочь автоматизировать этот процесс, или, по крайней мере, дать первый пас?
Я рассматриваю возможность использования head, awk, cut, grep и т. д. но они не очень автоматические.
2993
я обнаружил, что комбинация grep,cut,sort,uniq,head и tail полезны для специальной, одноразовой проверки журнала.
похоже, что каждая строка начинается с даты/времени.
Komp$ 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# опция строки контекста:
$ 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
 |  |  |  |  |  |  |  |  |  |
Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]
