Comments 4
Идея интересная, но не слишком универсальная. В целом логи смотрят (сужу по себе) для двух задач:
- мониторинг - но тут надо максимум информации для получения необходимых данных
- поиск ошибок - тут по большей части надо выделить только контекст ошибки, а это сама ошибка + цепочка событий, приводящая к ней, а вот тут Вы чуть-чуть не дожали.
Если следовать заветам OpenTelemetry, то каждый вызов и события, происходящие в пределах него должны быть помечены уникальным признаком, так что трассу можно отследить даже между несколькими микросервисами. А еще трейс из сообщения об ошибке можно развернуть до начала цепочки логов. Правда тут еще большой выбор форматор логов и где этот трейс искать.
И тут появляется новая концепция для logzip - сгруппировать по трейсам пакеты логов, устранить там переменные части (ид трейса, таймстамп лога, может быть что-то еще) и подвергнуть сжатию. В случае ошибок - сохранять максимум для первой однотипной, а повторяющиеся сжать.
В общем этакое RLE.
вообще не вижу проблем. топовые модели парсер и поиск используют если надо конкретно что то вычленить =)
Прикольно! Для offensive security тоже полезно. Скан nmap по большому скоупа сжал почти в два раза
Сепаратор для логов. Сжимаем логи для контекста LLM без потери читаемости