День 1492. #BestPractices Лучшие Практики Журналирования Независимо от того, какое ПО вы разрабатываете, вы так или иначе ведёте журнал. Это самый простой инструмент наблюдения, который у нас есть. Есть много ловушек, которые могут привести к бесполезным, объёмным и запутанным журналам. Вот несколько практик, которые позволят писать более качественные и согласованные по всей системе журналы. Журналы предназначены для разработчиков, вы будете единственным, кто их читает, поэтому, собираясь что-то логировать, спросите себя: - Поможет ли информация, которую вы собираетесь записать, отладить/понять поток? - Это нужно писать в журнал? Нельзя ли получить эту информацию из других мест? - Может ли логируемый объект быть огромным в производственной среде? Если да, можно ли записать только несколько его атрибутов? Когда вы решите, что писать в журнал, нужно понять, как это делать. 1. Согласованность Нужно поддерживать согласованность журналов во всей системе. Она ведёт к предсказуемости, что означает, что вы сможете осуществлять поиск по журналу, не вспоминая, в каком формате пишутся логи. 2. Уровень Важно выбрать правильный уровень журналирования. В .NET определены следующие уровни: - Trace (0) - наиболее подробные сообщения. Они могут содержать конфиденциальные данные приложения. Этот уровень отключен по умолчанию и никогда не должен включаться в производственной среде. - Debug (1) - используются для разборов и отладки во время разработки. Они должны в первую очередь содержать информацию, полезную для отладки, и не иметь долгосрочной ценности. - Information (2) - отслеживают общий поток исполнения приложения. Они должны иметь долгосрочную ценность. - Warning (3) - выделяют ненормальное или неожиданное событие в потоке приложения, но не приводят к остановке выполнения приложения. - Error (4) - выделяют, когда текущий поток выполнения останавливается из-за сбоя. Они должны указывать на сбой в текущем действии, а не на сбой всего приложения. - Critical (5) – описывают неустранимый сбой приложения или системы или катастрофический сбой, требующий немедленного вмешательства. - None (6) - не используется для записи сообщений журнала. Обозначает уровень на котором не должны записываться никакие сообщения. Наиболее распространённые ошибки — это ведение слишком подробных журналов уровня Information или полное отсутствие использования уровня Debug. 3. Бережливость Какой бы сервис логов вы ни использовали, он стоит денег, и быстрый способ сжечь деньги — писать в лог весь объект в виде json, который был относительно небольшим при разработке, но стал огромным в производственной среде. Журналы с огромными объектами бесполезны, их трудно читать, но они существуют, потому что так проще. Выберите атрибуты, которые являются наиболее важными и полезными для лога и которые действительно помогут вам разобраться в потоке исполнения. Иногда нужно знать, пустой ли объект или его свойство, тогда запишите в лог это, а не сам объект. 4. Уникальность Каждое сообщение журнала в системе должно быть уникальным. Если я открою журнал конкретного сервиса, я буду сбит с толку, увидев одни и те же логи из разных функций внутри сервиса. Мне будет проще начать отладку проблемы, чем копаться в тысячах одинаковых записей журнала. Т.е. журнал теперь бесполезен. Один из способов сохранить уникальность логов — обозначить имя сервиса и имя функции в качестве префикса для лога. Так гарантируется уникальность или, по крайней мере, сужается область поиска записей со всего сервиса до одной функции. Итого Ведение журнала - важный инструмент для любого ПО. Вы будете читать журнал всякий раз, когда нужно разобраться, почему написанный вами код не работает, поэтому не захламляйте его. Избавьте себя от проблем в будущем и заранее инвестируйте в продуманное ведение журнала. Источник: https://www.16elt.com/2023/01/06/logging-practices-I-follow/