IMHO "парсер много-строчных месседжей" - в общем виде не решаемо

А в чем проблема?
Считываем, если первое таймстемп - новое сообщение
Если нет - продолжение предыдущего

Но если в тексте сообщения затясался перевод строки и нечто похожее на таймпстемп - ой

Дурной топик. Т.к. если "исключения и java stacktrace", то "Во первых - медленно, т.к. сравнение схожести имеет сложность O(n * m) где n,m длина сообщений" полный бред, т.к. вполне можно проидексировать по исключению и методу, где оно возникает.

Читать всю галиматью, которую там могли понаписать - не интересно.

Ставьте более-менее логичную задачу, которую хотя бы теоретически, можно в реальном мире где-то применить.

Другими словами если ошибка существует, то за день можно сотни тысяч сообщений в логах поиметь и каждое уникально

Что у них за говно система такая?

Сотни тысяч сообщений в логах.... т.е. сотни тысяч клиентов НЕ смогли выполнить функционал/задачу - и всем на это в течении дня пофиг?

Занафига ей обучаться, если рядом с системой на 100 тысяч (!) ошибок явно должен находится админ и не один (!) ?

Максимум о чем может идти речь, это отсеять известные (ранее встречавшиеся ошибки), возможно с указанием ID таска в Jira по которой они фиксились и с именами людей которым нужно дать пизьдюлей депримировать за то, что эти ошибки возникли вновь. А такого по ISO 9000 быть не должно В ПРИНЦИПЕ.

Т.е. ошибка по определению (ISO 9000) или новая или у нее есть имя и должность, кого нужно уволить (т.е. она в уже базу занесена _руками_ и обучаться там нечему).

Ну и опять таки, повторюсь... видел я интерпрайзы... но 100 тыс. ошибок... вокруг этого интерпрайза уже ночью будет толпа привезенных из кроватей разработчиков, которых пинками разбудили и заставили ошибку искать/править. А на утро, после починки, все причастные еще и бесплатный секас без вазелина получат.

А если у кого-то нормально по 100 тысяч (!) ошибок в сутки - то в общем, все хорошо! Расслабиться, получать удовольствие и продолжать пилить российский бюджет. Одной сотней ошибок меньше, одной сотней ошибок больше - ему (бюджету) не страшно.

И что эта "группировка по степени схожести может дать" ?

В прошлый раз был Null Pointer Exception - разработчики его исправили за 15 минут, а в поза-прошлый раз, еп#$^ полторы недели, пока нашли причину...

Сейчас у нас опять Null Pointer Exception ! УРА ! Не страшно ! Это уже наша любимая и знакомая ошибка с высокой степенью схожести.

Так что ли?

примерно да.

Т.к. с логами я в первую очередь вижу совершенно другую проблему

1) В распределенной системе - понять какие связанные действия с других серверов породили данную ошибку. Т.е. у нас 20 нод типа A и 20 нод типа B. Нода типа A вызывает ноду типа B, в логах 17 ноды B обнаружено странное сообщение. Возникает проблема, связать ее с соответствующим трейсом на соответствующей (какой?) нодой A.

2) Онлайн обработка и оперативное реагирование - скорее должен быть не паттер Parser - Interator, а что-то типа Parser - Listener. Т.к. файл логов хочется все же мониторить в режиме близком к online.

Опять таки, сильно удивлюсь, если нет стандартных средств/пакетов для обработки анализа логов. По крайне мере в компании в которой работал, логи явно зашкаливали за террабайты (некоторые подсистемы на AWS хостились на _сотни_ инстансев), но у админов/старших разработчиков проблем с их поиском, анализом и обработкой не было.

Но там и 100 тыс. ошибок в сутки не было. Такое просто не допускалось и было не вообразимо . Были "странный" ошибки, возможно десяток в неделю (при нескольких сотнях тысяч реальных пользователей, х.з. сколько миллионов реквестов), причина которых была не установленна. Но и они как-то мониторились, т.е. руководство знало, что они появляются и сколько их было ))) переодически подходило и говорило "на этой недели опять на проде 2-а раза сообщение о разрыве связи было - надо с этим что-то делать".

А массовое возникновение ошибок и их классификация - мне такое представить сложно. Т.к. если такое после рестарта (апдейта) сервера возникло, то тут же админы сервер остановят и откатят софт на предыдущию версию.

IMHO & AFAIK

p.s. ну а написать парсер - это же дело 30 минут. Только не очень понятно, какой в нем толк. Т.к. без осмысленной аналитики логов (что уже зависит от конкретной прикладной системы) это совершенно бысмысленное перекладывание логов из файлов в логи в БД.

p.p.s. ну и в нормальных логах нужно: таймстемп, реквест (если Web/REST) где произошла проблема, прикладной юзер где произошла проблема, ID актора (если AKKA), поток (если многопоточка) ... и т.д. и т.п. Без этого востановить последовательность событий и __первопричину__ IMHO не возможно.
"Голая" ошибка - вообще никакой информации не несет.

Ну если так, то могу предложить более интересную задачу для AI

Разбор назначения платежа в банковской выписке

Заполняется человеком (поэтому всегда неточно), но часто повторяются определенные паттерны:

Оплата счета N 12345 за воду
Оплата счета за фев. N 12345 за воду
Аванс за февраль по счету N 12345
Предоплата за фев. по счету N 12345
Предоплата за янв. за воду счет N 12345
Оплата аванса по счету N 12345 за воду за фев.
и так далее... и так по десятку тысяч строк в день

С одной стороны, есть типовые фразы (паттерны) которые можно вычлинить и по ним раскидывать. С другой стороны, все время что то новое и нужен некоторый интерфейс поиска и заведения новых паттернов.

Главная идеологическая проблема обучающийся системы - кто будет отвечать за ошибки ?

Я с ИИ дел не имел (одно время смотрел /безуспешно/ OpenCV, хотел сделать бота для игры, задачу не реализовал, ИИ обучить не смог)

есть у меня массив данных за 2 месяца
строка == счет на который отнесен, тип счета (обычный, аванс), месяц

нужно:
1) научится вычленять из строки номер счета (сейчас сделано дубово, 10 цифр подрят номер счета, хотя может встречаться и ИНН, как разделяют номер счета от ИНН - не знаю)
2) желательно определять, что это аванс за какой-то период
3) что-то еще )))

на какие либы смотреть, как их обучать