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

Приложения на 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 выглядят, на первый взгляд, страшно и не подъёмно, и мы подсознательно не хотим с этим сталкиваться. Но, это только на первый взгляд! В следующих статьях разберем другие часто встречающиеся ошибки.

Комментарии (2)


  1. Batalmv
    09.05.2024 19:12
    +3

    Если вы для себя откроете grep / awk / cut ... то чтение логов будет занимать время, котороя я потратил на написание этого комментария :)

    Просто если уж "долбитесь" с файлами, что в целом не наказуемо, долбитесь хоть по человечески


    1. yanushu Автор
      09.05.2024 19:12

      Благодарю за совет)