Комментарии 23
К сожалению, на данный момент нет. В планах есть реализация user-defined шаблона как раз для парсинга обычных логов, ну а пока только sed и генерация JSON с помощью такой-то метери :)
https://blog.pkhamre.com/logging-to-logstash-json-format-in-nginx/
либо плагином:
https://github.com/jiaz/nginx-http-json-log
подумал, может есть нативная поддержка
Да, весьма неплохо именно в юзкейсе такой утилиты с простыми декларативными правилами на SQL-подобном языке. Мне в целом нравится.
Напомнило q для Python, только там работа ведётся с csv'шками.
Отличная утилита, к сожалению, не знал о ней. Спасибо за наводку на конкурента — будет с кем соревноваться.
В ней меня немного разочаровал тот факт, что таблицу нельзя использовать в подзапросе. То есть, такой запрос работает:
q "select * from data.csv"а такой — уже нет:
q "select * from (select * from data.csv) t"Пришлось делать через временный файл. А у вас как с этим дела?
Посмотрел более внимательно и обнаружил, что перед выполнением запроса все входные данные читаются в оперативную память, а потом уже идёт их обработка. Это фактически делает невозможным обработку действительно больших логов. Кроме того, в связки с tail -f работать не будет даже для самых простых запросов вида SELECT * WHERE f = "value"
Описываемый в статье jl-sql заточен именно под огромные логи, которые заведомо либо не влезают в память, либо вообще потенциально-бесконечны (реалтайм-поток). Поэтому jl-sql использует временное хранилище только там, где без него не обойтись, например, при сортировках.
Если сортировка не нужна, то результат на stdout будет выводиться сразу после получения отдельного объекта в stdin, не дожидаясь окончания всего потока объектов. Так работают запросы вида:
SELECT smth WHERE conditionПростые агрегационные запросы без GROUP BY тоже не будут требовать временного хранилища
SELECT SUM(`field`) WHERE conditionА вот JSON Path имеет смысл сделать в следующей мажорной версии, спасибо
Еще немного непонятно — как делать выборку по частичному совпадению? Тот же «like %...%», например?
Я для PHP подобного не встречал.
Еще немного непонятно — как делать выборку по частичному совпадению? Тот же «like %...%», например?
LIKE и регулярные выражения появятся в ближайшее время (пара дней)
LIKE и регулярные выражения появятся в ближайшее время (пара дней)Отлично, спасибо! Уже нашел начал использовать, а с like будет вообще идеально.
Еще заметил, что не работает конструкция в WHERE:
ts > (now() - INTERVAL 24 HOUR)
где ts — дата-время в формате «2017-01-19 14:50:45».
Работает как-то так:
(ts + INTERVAL 1 SECOND) > (now() - INTERVAL 24 HOUR)
т.е. получается, что время приводится к единому формату и только потом сравнивается. При этом в SELECT подобные манипуляции не нужны.
Хорошее замечание. К сожалению, о таком очевидном юзкейсе я не подумал заранее, но ничего, это исправимо.
Если ещё что-то заметите, то обязательно пишите — будем допиливать ;)
Зарелизил новую версию jl-sql v1.2.0 (jl-sql-api v2.4.0) с поддержкой LIKE и ILIKE (регистро-независимый LIKE). Ещё сделал поддержку автоматического приведения типов для дат, так что теперь
ts > (now() - INTERVAL 24 HOUR)должно работать.
Поддержки регулярных выражений пока нет.
Вот и регулярки подоспели
jl-sql-api v2.5.0 (2017-01-23)
REGEXPsupport:"string" REGEXP "/pattern/im"BETWEENsupportISsupport:
IS [NOT] NULLIS [NOT] BOOLand aliasIS [NOT] BOOLEANIS [NOT] NUMBERIS [NOT] ARRAYIS [NOT] OBJECTIS [NOT] STRING
Автору на заметку — есть очень интересная консольная утилита для json — jq, советую тоже обратить на неё внимание
jl-sql: SQL-запросы по JSON-логами в командной строке