Сепаратор для логов. Сжимаем логи для контекста LLM без потери читаемости

[remzalp]

Идея интересная, но не слишком универсальная. В целом логи смотрят (сужу по себе) для двух задач:
- мониторинг - но тут надо максимум информации для получения необходимых данных
- поиск ошибок - тут по большей части надо выделить только контекст ошибки, а это сама ошибка + цепочка событий, приводящая к ней, а вот тут Вы чуть-чуть не дожали.

Если следовать заветам OpenTelemetry, то каждый вызов и события, происходящие в пределах него должны быть помечены уникальным признаком, так что трассу можно отследить даже между несколькими микросервисами. А еще трейс из сообщения об ошибке можно развернуть до начала цепочки логов. Правда тут еще большой выбор форматор логов и где этот трейс искать.

И тут появляется новая концепция для logzip - сгруппировать по трейсам пакеты логов, устранить там переменные части (ид трейса, таймстамп лога, может быть что-то еще) и подвергнуть сжатию. В случае ошибок - сохранять максимум для первой однотипной, а повторяющиеся сжать.

В общем этакое RLE.

[Danusha0000000]

вообще не вижу проблем. топовые модели парсер и поиск используют если надо конкретно что то вычленить =)

[SurMaster]

Вы просто не работали с по настоящему большими логами

[CuriV]

Прикольно! Для offensive security тоже полезно. Скан nmap по большому скоупа сжал почти в два раза