Владимир Красильщик - Что надо знать о логировании прагматичному Java-программисту

Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Владимир Красильщик, Luxoft - Что надо знать о логировании прагматичному Java-программисту
Международная Java-конференция JPoint 2016
Москва, 22-23 апреля 2016
Расскажу про “лучшие практики” и неочевидные аспекты логирования, которым научился в процессе сопровождения и рефакторинга микросервисного "Ынтерпрайзного" приложения.

[@serhiir9999]

никогда не думал, что о логировании можно рассказать что-то интересное... оказалось таки можно

[@artemboiarshinov]

Есть несколько вопросов к докладчику: 1) В каком потоке (thread) происходит создание нового файла и зипование предыдущего? В том же потоке, в котором происходила запись в лог, повлекшая создание нового файла? Как-то это некрасиво по отношению к клиенту, чей запрос данная нить обрабатывает. 2) Зачем вообще писать логи в файл? По стандарту 12-факторных приложений сама аппка должна писать логи только в консоль, а уж чтением оттуда должны заниматься другие процессы (например, docker-контейнер может сливать логи из консоли в файл на диске, а оттуда они уже будут вычитываться Filebeat) 3) Что делать с MDC, если работа приложения основана на CompletableFuture или использует вызовы асинхронных методов? 4) Зачем была нужна обертка Alerts, если можно было натравить мониторинговые тулы на ключевые слова WARN и ERROR?

[@artemboiarshinov]

Универсальная Программная Архитектурная Диаграмма (УПАД) - просто отпад!

[@1pavka]

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

[@Das.Kleine.Krokodil]

Интересно, на чем сейчас логируют товарищи. Например в Log4j2 c версии 2.4. от 2016г есть ленивое логирование лямбдами

[@TheAndrej30000]

По поводу данных в логах мне не очень понятно. Это и правда очень удобно иметь логи со значением параметров, с которыми была запущена система. Разумеется, если "злоумышленник" получил доступ к таким логам, он получит информацию, но он с таким же успехом может получить доступ и к конфигам на сервере, и к базе данных и к чему угодно, если это не защищать. Просто такие логи нужно защищать. Ну а пароли, кредитные карты и прочее лучше вообще не получать в открытом виде :)

[@aeterosofficial]

Для меня этот доклад всё расставил на свои места