Зафиксировать правила логирования в наших приложениях

[danilkuznetsov]

сегодня столкнулся с проблемой логов, где то есть подробные, где-то их нет почти

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

я предлагаю использовать у нас три основных уровня

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

2. warn на каждый exception или ошибку которую мы обрабатываем. Например не смогли найти пользователя или еще чего

3. error когда что-то реально сломалось и дальше работать нельзя никак

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

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

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

и раз уж сейчас смотрим на эту проблему закрыть в основных сервисах

в боте почти готово, надо только пройтись проверить, в user надо сделать, в геймификации Вадим делает

что скажете, прием ?

и да конфиг по логам максимально сделать одинаковым

вопрос надо ли добавлять уровень info на dao или только контроллер и сервисы ?

[danilkuznetsov]

@OlgaKulikova давай решим этот вопрос на будущее

Ребята что скажете ?

[OlgaKulikova]

Хочу уточнить. Пункт 2 и 3 - можно пример? Мне кажется, если мы знаем, что что-то сломалось, то мы обрабатываем эти ситуации так, чтобы можно было дальше работать. На практике я видела, что уровень эррор ставится в блоках catch, когда ловится эксепшн.

[OlgaKulikova]

Инфо можно и на уровень дао

[danilkuznetsov]

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

во все методы включая dao добавляем debug в начале метода плюс внутри перед вызовами другим сервисов или потенциально долгих операций ставим два вывода в debug в перед блоком и после него

по пункту 2 - это все exception которые мы обработали по пункту 3 это все критические поломки, типа нет соединения с базой или важным сервисом, без которых работа дальше не возможна

[OlgaKulikova]

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

[danilkuznetsov]

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

[OlgaKulikova]

@danilkuznetsov is this task done? where is it fixed?

[danilkuznetsov]

@OlgaKulikova yes, I did this task. I added new rules to workflow file. We implemented this rules in all old repositories in releasing process. We are going to implement this rules in all new projects.

Details in pr #37