|
Парсер логов
|
|||
---|---|---|---|
#18+
В продолжение топика Нетривиальная задача анализа текстовых сообщений Поскольку автор слился а тема провисла в воздухе считаю своим долгом ее продолжить здесь. Но для проверки некоторых теорий которые прозвучали в теме нам нужен парсер много-строчных месседжей в логах. Тоесть сообщения в которых длинные стектрейсы должны быть 1 месседжем. Вот так я его себе вижу. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Здесь dateformat - это некая регулярка которая проверяет что строка начитается именно с timestamp в нужном нам формате. Надо также исходить из предположения что лог может быть очень большим. До терабайтов. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 17:52 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
поясни в чём задача и в чём сложность? И вообще зачем парсить логи вручную? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 17:59 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
IMHO "парсер много-строчных месседжей" - в общем виде не решаемо ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:04 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev IMHO "парсер много-строчных месседжей" - в общем виде не решаемо строго говоря да. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:04 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Давайте не вобщем. Решим в частных случаях. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:15 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
mayton Давайте не вобщем. Решим в частных случаях. А в чем проблема? Считываем, если первое таймстемп - новое сообщение Если нет - продолжение предыдущего Но если в тексте сообщения затясался перевод строки и нечто похожее на таймпстемп - ой ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:21 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev mayton Давайте не вобщем. Решим в частных случаях. А в чем проблема? Считываем, если первое таймстемп - новое сообщение Если нет - продолжение предыдущего Но если в тексте сообщения затясался перевод строки и нечто похожее на таймпстемп - ой Это - принимается как нормально. Тоесть парсер отработал хорошо. Без претензий. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:25 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
mayton Дурной топик. Т.к. если "исключения и java stacktrace", то "Во первых - медленно, т.к. сравнение схожести имеет сложность O(n * m) где n,m длина сообщений" полный бред, т.к. вполне можно проидексировать по исключению и методу, где оно возникает. Читать всю галиматью, которую там могли понаписать - не интересно. Ставьте более-менее логичную задачу, которую хотя бы теоретически, можно в реальном мире где-то применить. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:28 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Другими словами если ошибка существует, то за день можно сотни тысяч сообщений в логах поиметь и каждое уникально Что у них за говно система такая? Сотни тысяч сообщений в логах.... т.е. сотни тысяч клиентов НЕ смогли выполнить функционал/задачу - и всем на это в течении дня пофиг? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 18:30 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Да. Топик дурной. Но когда ентерпрайз дорастает до неприличных размеров - админы и девопсы ведут базу знаний по извесным дефектам. И для них на прод-саппорте очень часто стоит тайм-критичная задача - проанализировать если ERROR уже известный - то принять решение по таблице и действовать. Если дефекто новый и неизвестный - то на установление его истинности уходит время. Я частично был связан с прод-саппортом лет 10 назад и я примерно понимаю себе тот уровень ужаса который бывает продуктовых логах. По поводу формата логов и формата сообщений. Не со стороны log4j а со стороны программиста. Там фиксить никто никогда ничего не будет. Всё - minor tech debt. Поэтому часто девопсы брошены сами разбираться с дефектом. Сегодня с этим чуть лучше. Помогает Kibana с которой я работал и Splunk с которым мне не приходилось работать а также Графит и Графана. Но я честно не помню есть там подобный функционал для Fuzzy группировки ошибок по степени схожести. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 19:15 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
mayton, а просто триггеры из регулярок на логи уже не модны? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 20:10 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Мы не можем написать регулярку на новый тип ошибки которой еще не было. Мы можем просто предполагать что новый ERROR слишком далеко находится от всех известных групп месседжей которые берем за образцы известных ошибок. Грубо говоря речь идет о системе которая обучается. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 20:14 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Занафига ей обучаться, если рядом с системой на 100 тысяч (!) ошибок явно должен находится админ и не один (!) ? Максимум о чем может идти речь, это отсеять известные (ранее встречавшиеся ошибки), возможно с указанием ID таска в Jira по которой они фиксились и с именами людей которым нужно дать пизьдюлей депримировать за то, что эти ошибки возникли вновь. А такого по ISO 9000 быть не должно В ПРИНЦИПЕ. Т.е. ошибка по определению (ISO 9000) или новая или у нее есть имя и должность, кого нужно уволить (т.е. она в уже базу занесена _руками_ и обучаться там нечему). Ну и опять таки, повторюсь... видел я интерпрайзы... но 100 тыс. ошибок... вокруг этого интерпрайза уже ночью будет толпа привезенных из кроватей разработчиков, которых пинками разбудили и заставили ошибку искать/править. А на утро, после починки, все причастные еще и бесплатный секас без вазелина получат. А если у кого-то нормально по 100 тысяч (!) ошибок в сутки - то в общем, все хорошо! Расслабиться, получать удовольствие и продолжать пилить российский бюджет. Одной сотней ошибок меньше, одной сотней ошибок больше - ему (бюджету) не страшно. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 21:46 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
mayton ...есть там подобный функционал для Fuzzy группировки ошибок по степени схожести. И что эта "группировка по степени схожести может дать" ? В прошлый раз был Null Pointer Exception - разработчики его исправили за 15 минут, а в поза-прошлый раз, еп#$^ полторы недели, пока нашли причину... Сейчас у нас опять Null Pointer Exception ! УРА ! Не страшно ! Это уже наша любимая и знакомая ошибка с высокой степенью схожести. Так что ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.10.2020, 22:10 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Как-то так наверное яснее будет. Месседж с признаком уровня. И там выше я ошибся. Заменил на AutoClosable. Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 12:12 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsev mayton ...есть там подобный функционал для Fuzzy группировки ошибок по степени схожести. И что эта "группировка по степени схожести может дать" ? В прошлый раз был Null Pointer Exception - разработчики его исправили за 15 минут, а в поза-прошлый раз, еп#$^ полторы недели, пока нашли причину... Сейчас у нас опять Null Pointer Exception ! УРА ! Не страшно ! Это уже наша любимая и знакомая ошибка с высокой степенью схожести. Так что ли? Твой вопрос звучит так. Mayton - задлянафига тебе сдалась эта тема? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 12:20 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
mayton Твой вопрос звучит так. Mayton - задлянафига тебе сдалась эта тема? примерно да. Т.к. с логами я в первую очередь вижу совершенно другую проблему 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 не возможно. "Голая" ошибка - вообще никакой информации не несет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 12:43 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Я надеялся что этому топику посвятим 2 часа. Напишем парсер и переключимся на более интересную задачу. Тоесть где - то так. 0.5 sp на парсер и 13 sp на кластеризацию. По поводу интересов. В продолжение Архивариусов. Задачи текстовой кластеризации я считаю интересны но мало изученны. И алгоритмы по имплементации - более заточены на физику и математику чем на текст. Даже в org.apache.commons.math3.ml.* в роли обучающего вектора выступает вовсе не текст вектор вещественных чисел. Вот провести аналогию между текстом и безразмерным вектором - вот инженерная задача. И я именно над ней думаю. А парсер - просто инструмент. У меня есть много идей как это сделать но нужны "живые" данные. Логи например. Из других полезных кейсов. - Определение авторстава статьи-документа. - Выявление спама и рекламы в форумах (хотя для спама используют Байес) - Ну и биологии генетике еще много чего можно придумать. Интересна также оптимизация. Я хотел пощупать JNI + команды современных процессоров SSE/AVX и умножение вещественных толстых векторов друг на друга - тоже хороший повод. Java - медленно умножает и я хотел посмотреть какое ускорение получится. (вот здесь https://stackoverflow.com/questions/529457/performance-of-java-matrix-math-libraries один господин измерял матричные операции и увидел что разница от 4 секунд до 150) Вобщем для меня было 2 повода занятся логами. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 13:03 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Ну если так, то могу предложить более интересную задачу для AI Разбор назначения платежа в банковской выписке Заполняется человеком (поэтому всегда неточно), но часто повторяются определенные паттерны: Оплата счета N 12345 за воду Оплата счета за фев. N 12345 за воду Аванс за февраль по счету N 12345 Предоплата за фев. по счету N 12345 Предоплата за янв. за воду счет N 12345 Оплата аванса по счету N 12345 за воду за фев. и так далее... и так по десятку тысяч строк в день С одной стороны, есть типовые фразы (паттерны) которые можно вычлинить и по ним раскидывать. С другой стороны, все время что то новое и нужен некоторый интерфейс поиска и заведения новых паттернов. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 13:12 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Да тоже можно. Но ввиду того что автор родительского топика не дал больше никаких inputs, (более того, он позорно сбежал, ругая нас) я решил перенести дискуссию в другое место. Здесь мы можем уже расширить постановку. Логи и назначения платежей - просто частные случаи текстового вектора для некой обобщенной системы поиска кластеров. Код: java 1. 2. 3.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 13:19 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
И при этом и для логов и для реквизитов платежей у нас будет система - нечеткая. Со множеством настроечных параметров. Тоесть сразу она не взлетит. Ее придется обучать. И долго запускать на разных настройках. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 13:27 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Главная идеологическая проблема обучающийся системы - кто будет отвечать за ошибки ? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 13:29 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Такой вопрос задают ко всем нечетким системам. Пускай бизнес сам решает кто ответит. Тоже самое что спрашивать гугл, кто ответит за то что сайт не был найден в топе. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 13:38 |
|
Парсер логов
|
|||
---|---|---|---|
#18+
Я с ИИ дел не имел (одно время смотрел /безуспешно/ OpenCV, хотел сделать бота для игры, задачу не реализовал, ИИ обучить не смог) есть у меня массив данных за 2 месяца строка == счет на который отнесен, тип счета (обычный, аванс), месяц нужно: 1) научится вычленять из строки номер счета (сейчас сделано дубово, 10 цифр подрят номер счета, хотя может встречаться и ИНН, как разделяют номер счета от ИНН - не знаю) 2) желательно определять, что это аванс за какой-то период 3) что-то еще ))) на какие либы смотреть, как их обучать ... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2020, 14:36 |
|
|
start [/forum/topic.php?fid=59&msg=40010973&tid=2120648]: |
0ms |
get settings: |
27ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
426ms |
get tp. blocked users: |
2ms |
others: | 292ms |
total: | 833ms |
0 / 0 |