Вдохновившись утилитой от Microsoft - LogParser, решил написать свою, кросс-платформенную утилиту для парсинга логов с выборкой данных по SQL-запросу с преферансом и куртизанками
На данный момент утилита поддерживает только логи от 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 ).
Результаты небольшого бенча:
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 сек.
Да, именно так. Для толстых логов наверное не пойдет (но это всегда можно поправить))))
Решил сделать так, чтобы меньше мусорить в системе.
P.S.: думаю можно добавить проверку размера лог-файла и при больших размерах сохранять на диск.
Если есть какой нибудь не сверх секурный, толстый лог, поделитесь кому не сложно для опытов
Встает вопрос: а действительно ли нужно экономить на спичках
Зачастую мне надо делать много sql-запросов и часто анализировать один и тот же лог => он часто будет мапится в память. Да, из памяти читать быстрее, но эта быстрота нивелируется временем считывания лога в память
Я бы посоветовал выгружать в файл, который создается в месте вызова утилиты с именем <имя лога>.sql. При запуске проверять: есть ли у нас уже сформированный sql по логу; если есть - читать оттуда. Если у нас 2 лога с одним именем, то предусмотреть параметр - имя выгружаемого файла, который всегда перезапишет старый, если он есть.
Возможно, Вам эта идея покажется разумной.
А вообще, это напоминает такие инструменты, как logstash, apache flume.
Да, возможно чем-то похожа на эти тулы. Я парсер писал изначально для разбора одного большого лога для построения нагрузочной модели, а потом решил сделать его более универсальным. В любом случае, спасибо за отзыв и конструктивную критику Буду думать, как еще улучшить\ускорить тулзу.
testomat.io управление авто тестами
).
Буду думать, как еще улучшить\ускорить тулзу.