Утилита для парсинга логов - LogParser

sqlite
sql
logs
python
Теги: #<Tag:0x00007fedbb522208> #<Tag:0x00007fedbb5220c8> #<Tag:0x00007fedbb521f88> #<Tag:0x00007fedbb521e20>

(rmerkushin) #1

Вдохновившись утилитой от Microsoft - LogParser, решил написать свою, кросс-платформенную утилиту для парсинга логов с выборкой данных по SQL-запросу с преферансом и куртизанками :slight_smile:

На данный момент утилита поддерживает только логи от log4j, но в будущем планируется добавление новых форматов. В утилите реализована полная поддержка SQLite SQL, регулярные выражения в запросах, вывод в plain text и .xlsx и удаленный доступ к логам по sftp.

logparser -f log4j -i /path/to/log/file -q “SELECT * FROM LOG WHERE LEVEL = 'ERROR” -o /path/to/output/file.txt

Подробнее о работе утилиты и ее настойке можно почитать на github. Утилита доступна для скачивания в виде бинарных файлов для Mac OS и Windows (сборку под windows особо не проверял, т.к. сборка была из под виртуальной машины).

UPDATE:
Немного отрефакторил утилиту. Теперь повторная обработка не займет столько же времени. Так же добавил поддержку других кодировок логов (для эстетов хранящих логи в win-1251 :smiley: ).

Результаты небольшого бенча:

782.4 Mb, 3577723 строки
out - 613849 строки
Plain Text:
1 прогон - 36.902 сек.
2 прогон - 0.698 сек.
XLSX:
1 прогон - 41.823 сек.
2 прогон - 5.486 сек.

5.42 Gb, 20147926 строки
out - 178773 строки
1 прогон - 656.236 сек.
2 прогон - 29.190 сек.

Скачать


(Dmitriy Zverev) #2

Полезная утилита.
Поясните, пожалуйста, при каждом запуске лог загружается в SQLite в память?


(rmerkushin) #3

Да, именно так. Для толстых логов наверное не пойдет (но это всегда можно поправить))))
Решил сделать так, чтобы меньше мусорить в системе.

P.S.: думаю можно добавить проверку размера лог-файла и при больших размерах сохранять на диск.
Если есть какой нибудь не сверх секурный, толстый лог, поделитесь кому не сложно для опытов :slight_smile:


(Dmitriy Zverev) #4

Встает вопрос: а действительно ли нужно экономить на спичках
Зачастую мне надо делать много sql-запросов и часто анализировать один и тот же лог => он часто будет мапится в память. Да, из памяти читать быстрее, но эта быстрота нивелируется временем считывания лога в память
Я бы посоветовал выгружать в файл, который создается в месте вызова утилиты с именем <имя лога>.sql. При запуске проверять: есть ли у нас уже сформированный sql по логу; если есть - читать оттуда. Если у нас 2 лога с одним именем, то предусмотреть параметр - имя выгружаемого файла, который всегда перезапишет старый, если он есть.
Возможно, Вам эта идея покажется разумной.

А вообще, это напоминает такие инструменты, как logstash, apache flume.


(rmerkushin) #5

Да, возможно чем-то похожа на эти тулы. Я парсер писал изначально для разбора одного большого лога для построения нагрузочной модели, а потом решил сделать его более универсальным. В любом случае, спасибо за отзыв и конструктивную критику :smile: Буду думать, как еще улучшить\ускорить тулзу.

P.S.: Идеи и предложения приветствуются


(sidelnikovmike) #6

А как работает с большими логами?


(rmerkushin) #7

На больших логах не проверял еще. В ближайшее время буду рефакторить утилиту, прицеплю профайлер и проверю на больших объемах данных.

P.S.: Провел небольшой тест на файле 782.4 Mb - 3577723 строки с текущей реализацией, время обработки - 51.81 сек. Есть над чем поколдовать :slight_smile:


(rmerkushin) #8

update (подробности в шапке):

Сборка для mac
Сборка для win