Я уже рассказывал о том, что и как пишется в логи, что из себя представляют логи. Пришло время разбираться, как с ними работать и учиться читать информацию в больших файлах логов..
Приложения на GreenData (какие и многие другие приложения) имеют фронтовую часть и бэковую часть. Соответственно ошибки у нас тоже могут возникать как на фронте, так и на бэке.
Как понять относится ошибка к «фронту» или к «бэку»?
Об этом нам скажет сама ошибка, давайте рассмотрим 2 примера ошибок:
Ошибка номер раз:
![](https://habrastorage.org/getpro/habr/upload_files/2a0/42c/fe1/2a042cfe1edd8faaa089a94162f891b9.png)
Ошибка номер два:
![](https://habrastorage.org/getpro/habr/upload_files/2ae/bf1/458/2aebf1458b2ed924f500df4e00c85b9d.png)
Первая ошибка относится к фронтовой, а вторая к бэковой. При нажатии на всплывающий popUp ошибки её можно скопировать, внизу по тексту почти всегда указывается "GDCEDescription": "Unexpected front error"
– ошибка на уровне фронта и "GDCEDescription": "Unexpected back error"
– ошибка на уровне бэка. Про ошибки фронта будет отдельная статья, а сегодня рассмотрим более подробно работу с ошибками бэка (см. пример 2).
Искать просто ошибку в логе – все равно, что искать иголку в стоге сена. Используем некоторую информацию, которая существенно упростит поиск.
Для поиска воспользуемся частью текста ошибки, а именно полем GUID (по сути, уникальный uid ошибки в логе) "guid": "70708102-98ad-48b3-90f8-2dd2ddb648ec
", я обычно пользуюсь программой GitBush для поиска текста. Берём только сам GUID, копируем его и ищем по основному файлу с логом.
![Отображение ошибки в логе приложения Отображение ошибки в логе приложения](https://habrastorage.org/getpro/habr/upload_files/6a2/0bc/d43/6a20bcd4359b237598ce2af7be112a5d.png)
Жмём ENTER и запускается поиск (в GitBush поиск происходит вверх, значит перед этим опускаемся в самый низ лога).
Нашли!
![](https://habrastorage.org/getpro/habr/upload_files/a31/544/641/a3154464124b8d8bb7c6f8e1c259593d.png)
Итак, давайте разберём, что же мы нашли.
GUID нас приводит к «шапке» самой ошибки, в которой мы наблюдаем дату и время, трэд [XNIO-1 task-35] и информацию о том, под кем упала ошибка kozlovsky api который выполняла система и POST https://your-stand.greendatasoft.ru/api/sys/dynamicObjects , а так же информацию о том, что возникло исключение Exception raised (чтобы читать логи советую подтянуть свой английский, ну или иметь навык пользоваться онлайн переводчиками).
![](https://habrastorage.org/getpro/habr/upload_files/6a3/e4d/06e/6a3e4d06e81c5b66aca3f558eca8eb25.png)
В данном примере мы с вами рассматриваем очень простой вариант ошибки, а именно -проблему в работе алгоритма. 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 алгоритма его открыть, и поставить пробел, поздравляю вы починили свою первую багу!
![](https://habrastorage.org/getpro/habr/upload_files/4bb/ae7/2e2/4bbae72e27995c0373ebd649cb826715.png)
Итак, мы с вами прошли 1 уровень сложности.
Теперь чуть усложним задачу и посмотрим на примере ошибки rollback-only при работе бизнес-процесса.
Встретиться с этой ошибкой можно в маршруте бизнес-процесса. Она может выглядеть вот так:
![Ошибка на этапе работы бизнес-процесса. Ошибка на этапе работы бизнес-процесса.](https://habrastorage.org/getpro/habr/upload_files/102/a4d/f8d/102a4df8d78783749dfafdda20febef5.png)
Во-первых, что нам нужно знать об этой ошибке, это то, что Transaction marked as rollbackOnly - следствие какой-то другой ошибки, то есть сама ошибка в том числе, найденная в логе, нам с вами ничем, не поможет. Но как указано в пояснении этого типа ошибки «истина где-то рядом».
И так мы с вами имеем 06161977-452d-495b-9167-035096a327ef
.
Попробуем найти это в логе:
![](https://habrastorage.org/getpro/habr/upload_files/231/a19/451/231a19451313fe1f6c2433851845379b.png)
Смотрим дальше, вверх!
Чтобы не потеряться будем искать ошибку в том же треде [wf-exec-6] (иначе можно наткнутся на чужую ошибку и запутаться).
И вот она!
![](https://habrastorage.org/getpro/habr/upload_files/14c/a50/cbb/14ca50cbb9b06d293c456b3525be903f.png)
У нас возникла ошибка в алгоритме 5827405 далее по тексту описано, что в алгоритме не хватает прав на создание новых экземпляров объектов у типа объекта с идентификатором 'ID_919867'
.
Для того чтобы понять, что не так с алгоритмом, давайте откроем его.
![](https://habrastorage.org/getpro/habr/upload_files/aa4/662/625/aa46626257f82c584f126532763b5525.png)
В таком алгоритме с использованием функции execAs под явно тестовым пользователем, пытались создать экземпляр типа.
На что у данного пользователя в явном виде прав нет.
Проблема найдена – теперь осталось решить ее (выдав права, в данном случае).
Логи приложений на GreenData, особенно с уровнем debug выглядят, на первый взгляд, страшно и не подъёмно, и мы подсознательно не хотим с этим сталкиваться. Но, это только на первый взгляд! В следующих статьях разберем другие часто встречающиеся ошибки.