Как аналитик учился java log читать. Часть вторая: простые ошибки
Я уже рассказывал о том, что и как пишется в логи, что из себя представляют логи. Пришло время разбираться, как с ними работать и учиться читать информацию в больших файлах логов…
Приложения на GreenData (какие и многие другие приложения) имеют фронтовую часть и бэковую часть. Соответственно ошибки у нас тоже могут возникать как на фронте, так и на бэке.
Как понять относится ошибка к «фронту» или к «бэку»?
Об этом нам скажет сама ошибка, давайте рассмотрим 2 примера ошибок:
Ошибка номер раз:
Ошибка номер два:
Первая ошибка относится к фронтовой, а вторая к бэковой. При нажатии на всплывающий popUp ошибки её можно скопировать, внизу по тексту почти всегда указывается »GDCEDescription": "Unexpected front error" — ошибка на уровне фронта и »GDCEDescription": "Unexpected back error" — ошибка на уровне бэка. Про ошибки фронта будет отдельная статья, а сегодня рассмотрим более подробно работу с ошибками бэка (см. пример 2).
Искать просто ошибку в логе — все равно, что искать иголку в стоге сена. Используем некоторую информацию, которая существенно упростит поиск.
Для поиска воспользуемся частью текста ошибки, а именно полем GUID (по сути, уникальный uid ошибки в логе) »guid": "70708102-98ad-48b3-90f8-2dd2ddb648ec», я обычно пользуюсь программой GitBush для поиска текста. Берём только сам GUID, копируем его и ищем по основному файлу с логом.
Отображение ошибки в логе приложения
Жмём ENTER и запускается поиск (в GitBush поиск происходит вверх, значит перед этим опускаемся в самый низ лога).
Нашли!
Итак, давайте разберём, что же мы нашли.
GUID нас приводит к «шапке» самой ошибки, в которой мы наблюдаем дату и время, трэд [XNIO-1 task-35] и информацию о том, под кем упала ошибка kozlovsky api который выполняла система и POST https://your-stand.greendatasoft.ru/api/sys/dynamicObjects, а так же информацию о том, что возникло исключение Exception raised (чтобы читать логи советую подтянуть свой английский, ну или иметь навык пользоваться онлайн переводчиками).
В данном примере мы с вами рассматриваем очень простой вариант ошибки, а именно -проблему в работе алгоритма. groovy.lang.MissingPropertyException: No such property: return1 for class: Script_algorithm_5818311
Поняли мы с вами об этом исходя из двух частей текста 1. groovy.lang.MissingPropertyException — это класс ошибки groovy, языка на котором работают алгоритмы GreenData и не посредственно Script_algorithm_5818311. Здесь помимо прямого указания на то, что это алгоритм, указана также его ID. Представляете, как это удобно (всё благодаря нашим замечательным разработчикам, которые в том числе прописывают какие исключения бывают!)!
Вы спросите «Но в чём же собственно ошибка?!». А здесь всё просто — как мы видим в тексте из лога, к нам попала и проблемная часть самого алгоритма, кто-то опечатался и после return не поставил пробел return1. Чтобы исправить данную ошибку, нам нужно по id алгоритма его открыть, и поставить пробел, поздравляю вы починили свою первую багу!
Итак, мы с вами прошли 1 уровень сложности.
Теперь чуть усложним задачу и посмотрим на примере ошибки rollback-only при работе бизнес-процесса.
Встретиться с этой ошибкой можно в маршруте бизнес-процесса. Она может выглядеть вот так:
Ошибка на этапе работы бизнес-процесса.
Во-первых, что нам нужно знать об этой ошибке, это то, что Transaction marked as rollbackOnly — следствие какой-то другой ошибки, то есть сама ошибка в том числе, найденная в логе, нам с вами ничем, не поможет. Но как указано в пояснении этого типа ошибки «истина где-то рядом».
И так мы с вами имеем 06161977-452d-495b-9167-035096a327ef.
Попробуем найти это в логе:
Смотрим дальше, вверх!
Чтобы не потеряться будем искать ошибку в том же треде [wf-exec-6] (иначе можно наткнутся на чужую ошибку и запутаться).
И вот она!
У нас возникла ошибка в алгоритме 5827405 далее по тексту описано, что в алгоритме не хватает прав на создание новых экземпляров объектов у типа объекта с идентификатором 'ID_919867'.
Для того чтобы понять, что не так с алгоритмом, давайте откроем его.
В таком алгоритме с использованием функции execAs под явно тестовым пользователем, пытались создать экземпляр типа.
На что у данного пользователя в явном виде прав нет.
Проблема найдена — теперь осталось решить ее (выдав права, в данном случае).
Логи приложений на GreenData, особенно с уровнем debug выглядят, на первый взгляд, страшно и не подъёмно, и мы подсознательно не хотим с этим сталкиваться. Но, это только на первый взгляд! В следующих статьях разберем другие часто встречающиеся ошибки.
Habrahabr.ru прочитано 7931 раз
