Поиск софтины для ручного анализа логов (греп с динамическими правилами)

у самого less есть команда &.

&pattern
  Display  only lines which match the pattern; lines which do not match the pattern are not displayed.  If pattern is empty (if you type & immediately followed by ENTER), any
  filtering is turned off, and all lines are displayed.  While filtering is in effect, an ampersand is displayed at the beginning of the prompt, as a reminder that some lines
  in the file may be hidden.

  Certain characters are special as in the / command:

  ^N or !
		 Display only lines which do NOT match the pattern.

  ^R     Don't interpret regular expression metacharacters; that is, do a simple textual comparison.

Но не получается редактировать, а не переписывать фильтр. И после сброса фильтра фокус уплывает.

Идеально было бы что-то с ncurses-интерфейсом.

Как напишешь - поделись)

Clickhouse

Clickhouse

Что-то я не понял как оно может мне помочь. Чем оно отличается от других СУБД? Предлагаешь импортировать лог в БД, затем делать select? По удобству это будет ещё хуже чем grep+less.

Нет лучше можно ещё еластисерч

Сам не пробовал, но коллега юзает

https://github.com/tigrawap/slit

Тогда уже lnav. Он и в репозиториях и весьма хорош.

Сначала создают проблему, не записывая структурированные логи, потом её героически решают…

lnav

Во! То что нужно! Спасибо.

pihter, велосипед отменяется!

Он и в репозиториях и весьма хорош.

В репозиториях дебиана кстати сейчас версия 0.8.4. А меню для редактирования фильтров добавлили в 0.8.5. (а последняя сейчас 0.9)

У них есть готововые static-билды в пакетах http://lnav.org/downloads

Сначала создают проблему, не записывая структурированные логи, потом её героически решают…

С чего ты взял что логи неструктурированные?

Что значит структурированные логи?

велосипед отменяется!

Эх, это завсегда скучно)

// спасибо что кастанул: мне ко двору решение

JSON, например.

Фанбои раста ripgrep рекомендуют. Попробуй, вдруг торт.

ну, строго говоря, обычные текстовые тоже в каком-то смысле структурированные

multitail?

JSON, например.

Вот тебе структуризатор2000:

sed 's/\\/\\\\/g;s/"/\\"/g;s/^/{"message":"/;s/$/"},/;$s/,$/]/;1s/^/[/' log.txt

Петросян.

Я к тому что почти у всех логов есть структура-LogFormat. А JSON сам по себе логи более структурированными не сделает. Только усложнит визуальное чтение.

Все логи всё равно в ELK складывают, а локально при необходимости можно и попарсить строчно.

Структура лога может от типа сообщения зависеть. На моём предыдущем проекте был как минимум десяток типов сообщений, у каждого свой набор атрибутов (помимо общего).

А, понял, спасибо

Все логи всё равно в ELK складывают

Что-то я так и не понял чем так хорош ELK. Несколько лет назад пробовал поднять elastiflow для анализа netflow, но за пару дней ничего хорошего не получилось и в экосистему ELK не смог вникнуть. Остался на ntopng.

elastiflow

ntopng

Никогда не слышал. Быстрый гуглёж привёл меня к выводу, что речь о сетевых мониторах.

Тут же параллельная проблема решается, — агрегация логов. Просто единое место, где их можно смотреть. Плюс фильтры, алерты и многое другое.

Но вообще, на основе Elasticsearch что только не делают. Я видел архитектуру, где в он был в качестве БД для рефералки у рекламной площадки, например.