Суммирование гигантских файлов журнала

Вы попробовали splunk? 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# опция строк контекста:

$ 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)

Успех!

В этом случае вывод происходил из-за некоторого избыточного входа отладки, оставляемого на в наших конфигурационных файлах.

Необходимо будет скорректировать этот подход для установки конкретному файлу журнала, но основные ключи:

1. Обрезка устанавливает метку времени
2. Обрезка к некоторой сумме строки это, вероятно, будет неизменно
3. Вид и считает то, что оставляют
4. Ищите крупнейших преступников в контексте