На этот пост, как и смысль меня сподвигли посты из бложика
fantom
В первую очередь создаю для себя, так как стало сложно как то организовать методологию хранения и структурирования информации. В последнее время я сильно ударился головой в архитектуру сложных масштабированных приложений, и существует множество паттернов, и тулзов для их решения. Наверно я начну...
dev-cs.ru
Из одной интересных тем для AMXX мне показалось уместным бы реализовать какую-то общую систему логоирования.
Но, начать хотелось бы по порядку.
В статье на Хабре, нашёл срарую, но, как мне показалось подходящую информацию.
Мой опыт разработки в основном строится вокруг разнообразных сетевых cервисов под Windows и Linux. Я обычно стремлюсь добиться максимальной кроссплатформенности...
habr.com
Самое важное, для себя подчеркнул пока-лишь это:
Сколько логировать
Серьезная проблема для разработчика. Всегда хочется получать больше информации, но код начинает выглядеть очень плохо. Я руководствуюсь следующими соображениями.
Вывод в лог это по сути комментарий. Логирование уровня
Trace по большей части их и заменяет.
Уровни
Trace и
Debug читают разработчики, а все что выше — техподдержка и админы. Поэтому до уровня
Info сообщения должны точно отвечать на вопросы: «Что произошло?», «Почему?» и по возможности «Как исправить?». Особенно это касается ошибок в файлах конфигурации.
Качественный состав уровней логирования уже разобран в предыдущей статье, здесь рассмотрим только количественный состав:
- Trace — вывод всего подряд. На тот случай, если Debug не позволяет локализовать ошибку. В нем полезно отмечать вызовы разнообразных блокирующих и асинхронных операций.
- Debug — журналирование моментов вызова «крупных» операций. Старт/остановка потока, запрос пользователя и т.п.
- Info — разовые операции, которые повторяются крайне редко, но не регулярно. (загрузка конфига, плагина, запуск бэкапа)
- Warning — неожиданные параметры вызова, странный формат запроса, использование дефолтных значений в замен не корректных. Вообще все, что может свидетельствовать о не штатном использовании.
- Error — повод для внимания разработчиков. Тут интересно окружение конкретного места ошибки.
- Fatal — тут и так понятно. Выводим все до чего дотянуться можем, так как дальше приложение работать не будет.
Далее, имея какие-то удобно структуризированные логи хотелось бы их своевремено получать, и хранить.
Я нашёл некоторый выход из этой ситуации. Можно использовать
Sentry API Reference
Тем самым, заранее подготовленные логи, присылать в мощный сервис. Подход имеет преемущества, но и недостатки.
Из преемуществ - можно почитать описание к Sentry - станет ясно.
А, о недостатках - как минимум - падение. Оно не гарантирует нам доставку логов в Sentry. По всей видимости этот вопрос временно решается записью логов в файлы .log, всё так же структурированно. А, в дальнейшем, можно уже будет поговорить о преемуществах работы c сервером в контейнере Docker и описании работы с
docker events
Начну с простого, попробую на суд представить систему логирования, быть может, вместе мы найдём лучшее решение. Пошёл писать.
И сходу нашёл полезную, готовую, похожую реализацию.
В статье дано базовое описание пакета Logging. Ведение логов, позволяет устранит много проблем как в процессе разработки так и в процессе эксплуатации.
webdevblog.ru