Обновить
Комментарии 8
Хороший функционал. Давно нечто подобное ищу, отчаялся, уже начал сам писать себе вьювер для логов) У вас там функционала для работы (хотя бы поиска) с многострочными сообщениями нет? Кому как, но для меня это была бы киллер-фича. Нигде не смог такого найти.
Спасибо за ваш комментарий.
Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
Конечно. Проблема в том, что все лого-вьюверы-анализаторы, которые я видел, работают со строками. Строка — якобы одна запись в логе, и запись в логе — якобы одна строка. Сомнительное допущение. Внезапно бывают приложения, которые пишут многострочные сообщения в лог. Например:

// Одна строка:
2020-07-16T17:05:00.123 ERROR Something went wrong!
// Много строк:
2020-07-16T17:05:00.123 ERROR Something went wrong! SmthWrongException:
stacktrace
stacktrace
stacktrace
stacktrace
stacktrace
stacktrace
// Одна строка:
2020-07-16T17:05:00.123 INFO Request received: {"data":{"action":"delete","id":"123qwe"}}
// Много строк:
2020-07-16T17:05:00.123 INFO Request received:
{
"data":
{
"action":"delete",
"id":"123qwe"
}
}


Для примера с переносами строк типичный поиск работает очень плохо, если нужно найти записи, где action было delete для некоторого id. В вырожденном случае, как здесь, можно искать "delete.*\n.*123qwe", но не всегда известно количество строк между delete и 123qwe. Поиск по "delete|123qwe" выдаст кучу мусора. Между тем, для нормального поиска есть вся информация. Ну, конечно, с вводом message pattern'а: "{YYYY-MM-DDThh:mm:ss.fff} {level} {message}" — где {message} может содержать переносы строки.

Пара примеров мультистрочного поиска при неизвестном количестве строк:


grep -Pzo '(?s)delete.*?123qwe' sample.log
perl -0777 -ne 'm/(delete.*?123qwe)/s; print $1' sample.log

Впрочем, понятно, что конкретное решение зависит от конкретных целей.

Спасибо за разъяснения.
На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.

Не думали об интеграции с чем-то относительно стандартизированным, типа opentracing?

Какого рода интеграцию вы имеете ввиду? Например, интеграция с DLT понятна — декодирование и разбиение на столбцы для удобства чтнения. С opentracing немного не ясно, что именно нужно интегрировать. Поясните пожалуйста.

Вот не уверен, что связывание строк и обработка многострочных записей в логе сильно пересекающаяся функциональность. Не, можно, конечно, строить индекс по типу N — строка лога, N+1 связана с N, тип связи "продолжение строки", N+2 связана с N + 1, тип связи "продолжение строки". Но как-то избыточно выглядит, с одной стороны, а, с другой, нужен будет дополнительный индекс для поиска текста, пускай слова error разбитого на несколько строк.


В общем, далеко не очевидно, что одна запись лога — одна строка. Часто атомарно пишется несколько строк вместе как одна строка. Причём может быть с одной временной меткой на всю запись (лично мне чаще встречается), а может быть по одной общей метке и прочей метаинформации на каждую строку.

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