Владимир Красильщик - Что надо знать о логировании прагматичному Java-программисту
Вставка
- Опубліковано 8 лис 2016
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Владимир Красильщик, Luxoft - Что надо знать о логировании прагматичному Java-программисту
Международная Java-конференция JPoint 2016
Москва, 22-23 апреля 2016
Расскажу про “лучшие практики” и неочевидные аспекты логирования, которым научился в процессе сопровождения и рефакторинга микросервисного "Ынтерпрайзного" приложения. - Наука та технологія
никогда не думал, что о логировании можно рассказать что-то интересное... оказалось таки можно
Универсальная Программная Архитектурная Диаграмма (УПАД) - просто отпад!
Есть несколько вопросов к докладчику:
1) В каком потоке (thread) происходит создание нового файла и зипование предыдущего? В том же потоке, в котором происходила запись в лог, повлекшая создание нового файла? Как-то это некрасиво по отношению к клиенту, чей запрос данная нить обрабатывает.
2) Зачем вообще писать логи в файл? По стандарту 12-факторных приложений сама аппка должна писать логи только в консоль, а уж чтением оттуда должны заниматься другие процессы (например, docker-контейнер может сливать логи из консоли в файл на диске, а оттуда они уже будут вычитываться Filebeat)
3) Что делать с MDC, если работа приложения основана на CompletableFuture или использует вызовы асинхронных методов?
4) Зачем была нужна обертка Alerts, если можно было натравить мониторинговые тулы на ключевые слова WARN и ERROR?
В общем, люди вникают в настройки и состав фреймворков по части логирования, чтобы разрулить их отношения. Они еще настраивают все централизовано для удобства и уделяют много времени безопасности, ибо в приложениях за деньги крутятся много плохих дядек-мошенников. Доклад отличный.
Интересно, на чем сейчас логируют товарищи.
Например в Log4j2 c версии 2.4. от 2016г есть ленивое логирование лямбдами
Для меня этот доклад всё расставил на свои места
По поводу данных в логах мне не очень понятно. Это и правда очень удобно иметь логи со значением параметров, с которыми была запущена система. Разумеется, если "злоумышленник" получил доступ к таким логам, он получит информацию, но он с таким же успехом может получить доступ и к конфигам на сервере, и к базе данных и к чему угодно, если это не защищать. Просто такие логи нужно защищать.
Ну а пароли, кредитные карты и прочее лучше вообще не получать в открытом виде :)