Комментарии 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?
Вот не уверен, что связывание строк и обработка многострочных записей в логе сильно пересекающаяся функциональность. Не, можно, конечно, строить индекс по типу N — строка лога, N+1 связана с N, тип связи "продолжение строки", N+2 связана с N + 1, тип связи "продолжение строки". Но как-то избыточно выглядит, с одной стороны, а, с другой, нужен будет дополнительный индекс для поиска текста, пускай слова error разбитого на несколько строк.
В общем, далеко не очевидно, что одна запись лога — одна строка. Часто атомарно пишется несколько строк вместе как одна строка. Причём может быть с одной временной меткой на всю запись (лично мне чаще встречается), а может быть по одной общей метке и прочей метаинформации на каждую строку.
Время в логах