LINUX.ORG.RU
ФорумTalks

Парсер логов с sql интерфейсом

 ,


0

1

Я тут подумал, наверняка ведь есть много таких же как я, которые плохо знают всякие sort, unique, awk, sed, зато отлично помнят все про sql.

И каждый раз, когда надо почитать логи, вспоминание стандартных подходов занимает драгоценное время. Почему бы не написать утилиту с sql интерфейсом?

% cat file | awk {'print $1 $3 $7'}
% cat file | sqllp 'select 1 date, 3 ip, 4 url'

% cat file | awk {'print $3'} | sort -u
% cat file | sqllp 'select distinct 1 ip'

% cat file | sqllp 'select 1 ip, count(*) n group by ip order by n desc limit 10'

% cat file | sqllp 'select * where 4 ilike '%assets%'

И т.д. и т.п. Есть подозрение что такое уже сделали, может кто знает как поискать?



Последнее исправление: gistart (всего исправлений: 1)
Ответ на: комментарий от Stanson

Дураки какие-то плохо понимают то, что я написал

Это именно то, что я из вежливости не говорю вам.

gistart
() автор топика
Ответ на: комментарий от Stanson

Не взлетит. Перед тем, как запихать это всё в базу для нормального использования, надо будет написать парсер, который разберёт лог по полям, выставит соответствующие типы, проставит индексы и прочее.

Не, это можно сделать конечно. Но зачем, если можно сразу же этим парсером без бд выводить нужное? :)

shell-script ★★★★★
()
Ответ на: комментарий от gistart

Так в чём проблема разбить текстовый лог на поля и залить в БД?

И я не вижу ответа на вопрос:

Вот я пишу код, а код пишет логи.

Вы nginx пишете?

Stanson ★★★★★
()
Ответ на: комментарий от shell-script

И объяснили, почему

Вы хотели сказать, нихрена не поняли о чем речь, и затянули стандарное «нинужно»?

внутренним представлением данных в мускле и текстовым файлом
Слишком толсто.

Можете пояснить, почему awk работает? По вашим словам он просто не может работать. Странно как-то.

gistart
() автор топика
Последнее исправление: gistart (всего исправлений: 1)
Ответ на: комментарий от Stanson

Так в чём проблема

Не могу так сказать в чем ваша проблема, что-то связанное с пониманием прочитанного, или, возможно, с самим чтением?

gistart
() автор топика
Ответ на: комментарий от shell-script

Ну вот хочется ему вынь да положь SQL для логов. При этом, сам он делать ничего не хочет. :) Очередная вебмакака приползшая с венды, с воплями «а пачиму мне уже не сделали тут в вашем линухе зашибись?»

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)

Потому что это для неосиляторов, хомячков и прочих предателей истинного свободного линукс-сообщества.

Deleted
()
Ответ на: комментарий от gistart

Вы хотели сказать, нихрена не поняли о чем речь, и затянули стандарное «нинужно»?

Не нужно свои мысли приписывать мне.

Пилить утилиту, которая любой сферический лог в вакууме сможет распарсить и предоставит sql-интерфейс к нему во-первых накладно. Простой пример - дата. В одном логе - это unixtime, в другом это «YY/mm/dd HH/MM/SS», в третьем «dd month YY - HH:MM:SS». Как делать условный select по этому полю? Как вообще задать узнать, что это одно поле, а не два или более? Используя стандартные утилиты - легко: awk+date. Ты же предлагаешь написать это заново. Такие же вопросы будут и по поводу остальных полей. Четыре числа разделённых точками - не всегда айпишник. И т.д. и т.п. Поэтому нужен какой-то язык, используя который, человек может написать простейший парсер в одну строку и получить нужные данные. С твоим подходом надо будет сначала написать такой парсер, а потом к этому парсеру привинтить sql-интерфейс.

И тут мы подходим ко второму пункту. Мало того, что прикручивание к логам sql-интерфейса - это дополнительная работа. Фишка в том, что в 99.9% случаев это просто не нужно. Все эти стандартные утилиты, маны на которые ты не прочитал, очень просты на самом деле. В большинстве ситуаций сильно проще sql-запросов. Работа с ними идёт на автомате, читабельность таких однострочников значительно выше, чем у какого-нибудь select .. where ... join и т.п. Т.е. таки да. В данном случае классическое не нужно.

Можете пояснить, почему awk работает? По вашим словам он просто не может работать.

В каком месте я сказал, что awk не может работать? Ты сам это себе придумал и теперь требуешь от меня объяснить почему? Извиняй, телепатии не обучен, в твою голову заглянуть не могу.

shell-script ★★★★★
()
Ответ на: комментарий от Stanson

Или просто недавно познакомился с sql'ем и теперь восторженно ищет его везде где надо и не надо. :)

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Постараюсь объяснить последний раз.

любой сферический лог в вакууме

Было сказано, да и так понятно, что это не требуется.

Простой пример - дата.

По умолчанию каждое поле пусть будет строкой. Если хотите воспринимать его по другому — пишите преобразование явно. Об этом было в каментах выше.

Для часто используемых типов можно и нужно использовать стандартные кастеры: 1::date, cat(1, ' ', 2)::date — где date переберет все разумные форматы, или 1::datefmt('...') — если автор вашего формата самый умный.

Используя стандартные утилиты - легко: awk+date

Вы не первый кто это говорит, может, будете первым кто на деле покажет как надо делать в случаях, приведенных в каментах выше, и чтобы решение было простым?

В каком месте я сказал, что awk не может работать?

Когда рассказывали мне, что под каждый конкретный формат лога надо адаптировать утилиту?

Извиняй, телепатии не обучен

Очень надеюсь, что хоть чтению обучены на базовом уровне.

gistart
() автор топика
Ответ на: комментарий от gistart

стандартные кастеры: 1::date, cat(1, ' ', 2)::date — где date переберет все разумные форматы, или 1::datefmt('...') — если автор вашего формата самый умный.

Ну например(sed можно заменить на awk, awk на perl и т.д).

date -d "$(echo '2018/03/30 15/05/00' | sed 's|/|-|g;s|-|:|3g') next day" +%s
Это если дата в кастомном формате. По этому полю сортируешь, или считаешь или делаешь, что душе угодно. Или выводишь в нужном формате.

Если же дата в секундах от начала эпохи, то сразу считаешь/сортируешь, а в конце выводишь в нужном формате date -d @1522497900 +формат

А что за стандартные кастеры и вообще, что это там у тебя за набор скобочек с циферками не особо понятно человеческому взгляду. А ведь простота в том и заключается, чтобы человеку было просто писать и читать при работе с логом.

Когда рассказывали мне, что под каждый конкретный формат лога надо адаптировать утилиту?

Читать, похоже, надо тебе научиться. Я говорил, что под каждый формат нужен свой парсер. На awk такой парсер написать можно. Для твоей утилиты кто будет парсер писать? И опять же, зачем писать парсер и sql-интерфейс, когда просто парсера уже достаточно?

shell-script ★★★★★
()
Ответ на: комментарий от gistart

Вы не первый кто это говорит, может, будете первым кто на деле покажет как надо делать в случаях, приведенных в каментах выше, и чтобы решение было простым?

Может ты уже перестанешь гнать дебильную пургу про парсеры и типы и прочтёшь уже наконец man date?

$ date --date='01 Mar 2018 00:00:04 +0300' +'%s'
1519851604
$ date --date='Mar 01 2018 00:00:04' +'%s'
1519851604
$ date --date='2018-03-01 00:00:04' +'%s'
1519851604
$ date --date='03/01/2018 00:00:04' +'%s'
1519851604
$ date --date='03/01/2018 00:00:04 + 1 day' +'%s'
1519938004
$ date --date='- 1 month' +'%s'
1519992574

Как сравнивать целые числа тоже надо рассказать?

Сцуко, всё уже написано давным-давно, специально для простого, удобного и быстрого парсинга логов. Вот уж что-что, а парсинг логов в линуксе - самый удобный, фичастый и быстрый.

Но нет, вместо того, чтобы просто прочитать несколько манов, на что уйдёт времени в разы меньше чем на срачики на лоре, надо мечтать о пердоленьи с какими-то выдуманными велосипедами и при этом ещё возмущаться.

Stanson ★★★★★
()
Ответ на: комментарий от shell-script

sed 's|/|-|g;s|-|:|3g'
что это там у тебя за набор скобочек с циферками не особо понятно человеческому взгляду.

даже не смешно

Я говорил, что под каждый формат нужен свой парсер.
И в процессе у тебя возникнет немало трудностей как минимум с производительностью и постоянным разбором формата лога из-за чего твою утилиту нужно будет постоянно переписывать(или же настраивать свои сервера

Вот тут вы говорите, что утилиту надо переписывать. Ежу понятно, что под каждый формат лога нужно писать свой запрос (или скрипт, как с авком), но не парсер.

И опять же, зачем писать

Вас никто ничего писать не просит, успокойтесь.

gistart
() автор топика
Ответ на: комментарий от Stanson

Молодой человек, возьмите себя в руки.

gistart
() автор топика
Ответ на: комментарий от gistart

Т.е. твоя утилита сначала приведёт кастомную дату из текстового лога в тип даты постгреса, а потом назад декодирует этот формат в читабельный вид? Окай.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Все же наблюдаю проблему с чтением у вас.

По умолчанию каждое поле пусть будет строкой. Если хотите воспринимать его по другому — пишите преобразование явно. Об этом было в каментах выше.

Строку в дату переводить нужно, только если с ней потом хочется что-нибудь сделать. Просто для вывода это не требуется.

gistart
() автор топика
Ответ на: комментарий от gistart

Вот только меня интересует именно, как ты на sql сделаешь из 'YYYY/mm/dd HH/MM/SS' unixtimestamp, а не как отобразить дату в постгресовской консоли.

shell-script ★★★★★
()
Ответ на: комментарий от gistart

Как ты не приведя строку, в которой лежит дата к единому формату будешь делать вывод «за три дня, начиная с первого марта», например?

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

как ты на sql сделаешь из 'YYYY/mm/dd HH/MM/SS' unixtimestamp

не могу представить зачем бы мне это было нужно, но вот:

postgres=# select extract(epoch from to_timestamp('2018/03/01 01/03/04', 'YYYY/mm/dd HH/MM/SS'));
 date_part  
------------
 1519855204
(1 row)

а не как отобразить дату в постгресовской консоли.

Для неграмотных — я показываю парсинг строки в дату с угадыванием формата ранее, и с заданным форматом сейчас.

gistart
() автор топика
Ответ на: комментарий от shell-script

сначала приведёт кастомную дату из текстового лога в тип даты постгреса, а потом назад декодирует этот формат в читабельный вид

не «постгреса», а «воспринимаемый функциями работы с датой»

если надо работать со строкой как с датой — то да, все верно

gistart
() автор топика
Ответ на: комментарий от gistart

Отлично.

Итого, для работы твоей утилиты надо реализовать какой-то парсер, который разберёт файл на поля, определит их тип, приведёт всё к постгресовскому внутреннему представлению, и реализовать его встроенные функции.

Вот только раньше ты говорил просто про sql, а сейчас у тебя уже пошли чисто постгресовские встроенные функции.

Что дальше?

Тогда уж лучше сразу написать парсер, который загонит лог в базу. Но об этом я уже писал выше. Если есть такой парсер, то и без базы можно выводить всё как угодно.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Это от проблем с чтением вам все еще не понятно. Не могу вам станцевать в ответ на вопрос, только отошлю к ранее написанному в каментах.

gistart
() автор топика
Последнее исправление: gistart (всего исправлений: 1)
Ответ на: комментарий от gistart

Что мной было прочитано не так?

Вот это?

> select extract(epoch from to_timestamp('2018/03/01 01/03/04', 'YYYY/mm/dd HH/MM/SS'));
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'epoch from to_timestamp('2018/03/01 01/03/04', 'YYYY/mm/dd HH/MM/SS'))' at line 1

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

check the manual that corresponds to your MariaDB

у меня постгрес под рукой, я на нем демонстрировал идею

Что мной было прочитано не так?

очевидно вы прочитали postgres как mariadb — тяжелый случай

gistart
() автор топика
Последнее исправление: gistart (всего исправлений: 2)
Ответ на: комментарий от shell-script

я кстати тоже так могу)

xc» date -d "$(echo '2018/03/30 15/05/00' | sed 's|/|-|g;s|-|:|3g') next day" +%s
fish: $(...) is not supported. In fish, please use '(echo)'.                                            
    

gistart
() автор топика
Ответ на: комментарий от gistart

Да не важно, что у тебя под рукой. Суть в том, что ты предлагаешь в «утилиту для анализа логов» запихать полпостгреса(ну или любой другой СУБД). И в этом главная проблема. Ты почему-то в упор не хочешь понять, что заместо готовых и простых утилит, предлагаешь написать их аналог, который загонит лог в базу, а потом использовать функции этой самой базы.

Может быть в каких-то отдельных случаях это и будет удобно. Тогда берут и пишут парсеры с помощью всё тех же утилит(или используя полноценный ЯП), от которых ты хочешь избавиться. Пишут под каждую конкретную ситуацию, потому что в общем случае, предлагаемое тобой решение оверхед, который к тому же не будет удобнее стандартного набора.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

запихать полпостгреса
загонит лог в базу
использовать функции этой самой базы

Терминальная стадия к сожалению, извините, помочь вам не смогу с вашими дальнейшими вопросами.

gistart
() автор топика

Во-первых, ты хочешь Микрософтовский LogParser.

Во-вторых, чего мучаешься? Залей свой лог в sqlite однострочником, и делай селекты хоть до посинения.

В-третьих, прикрути этот однострочник к ведению логов, и храни сразу бинарные.

baka-kun ★★★★★
()
Ответ на: комментарий от undertaker

Для особых извращенцев есть вот такое

Для особых есть OSquery, а кому-то даже asql достаточно.

baka-kun ★★★★★
()

как насчет писать логи сразу в sqlite какой-то? :)

invy ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.