День 2421. #BestPractices
Вещи, Которые Я Делаю в Каждом Проекте .NET. Продолжение
Начало

3. Логирование
Конкретная библиотека не имеет значения: Serilog, NLog или log4net. Но не используйте их напрямую. Используйте везде ILogger, чтобы единственное место, которое бы знало о конкретной его реализации – был файл program.cs. По возможности используйте структурное логирование. Также помните о том, что каждый журнал должен содержать некоторую ключевую информацию, например, ID пользователя или ID корреляции. Так вы сможете отслеживать как один запрос проходит через разные сервисы, и что там происходит. Иногда полезно включать короткий sha Git-коммита, чтобы если появляется ошибка, и вы её исправляете, вы могли сравнить, получаем ли мы больше исключений в последней версии, чем получали раньше?

Также важно разделять, как вы логируете нужную информацию. Например, в системе управления пользователями нужно регистрировать, кто внёс каждое изменение. Иногда мы думаем: «Есть же логгер, запишем в лог». Скорей всего, это не лучшее место. Рассмотрим о логи, метрики и аудиты.

Логи должны быть ориентированы на разработчиков. Вы не должны их передавать бизнесу. Это исключения с трассировками стека, ответы от внешних API, разные этапы процесса обработки и т.п.
Кроме того, многие путают уровни логирования. Например, сваливают всё в Information. Вы вызываете 3 API и хотите логировать их ответы. Это информация уровня отладки (Debug). А Information – это результат запроса: мы обработали столько-то записей за такое-то время, т.е. одна запись на запрос пользователя.
Используйте предупреждения (Warning) вместо ошибок (Error). Логи уровня предупреждения работают так: если у вас одно предупреждение, это не страшно, но если их много, то что-то не так. Классический пример: пользователь вводит неверный пароль и блокирует свою учётную запись на пять минут. Одно событие – не важно, но если их тысячи за короткий промежуток времени, возможно, происходит что-то не то (например, кто-то пытается проникнуть в систему).
Ошибки (Error) — это необработанные исключения. Многие просто игнорируют ошибки в логах. Не стоит так делать. Нужно выяснить первопричину и определить, волнует ли нас это. Может это предупреждение, а может реальная ошибка в коде. Постарайтесь очистить ошибки из лога, потому что худший человек, которому стоит сообщать о проблемах, — это ваши пользователи.
И, наконец, критический уровень (Critical) используется, когда приложение не может загрузиться. Например, нужно сначала обратиться к БД или к Azure Key Vault, чтобы извлечь секреты. Если это не удаётся, приложение не может работать.

Стоит подумать, как долго хранятся логи. Azure Log Analytics по умолчанию хранит только 30 дней. И если вы пытаетесь сохранить историческую информацию, например: «кто что изменил?», то ваш ответ бизнесу «Мы храним только 30 дней логов» вряд ли будет удовлетворительным. Аналогично, многие системы записывают логи в буфер и потом скидывают на диск. Так что, если отключится питание, последние логи потеряются. Это нормально, если логи используются только как описано выше, и не хранят важной для бизнеса информации.

Метрики делятся на 2 типа:
- уровня приложения: процессор, сеть, память, глубина очереди и т.п.
- бизнес-метрики: сколько размещено заказов, сколько раз нажимали эту кнопку, или сколько просмотрели эту страницу.
Как долго нужно хранить эти данные? Это должен быть разговор с бизнесом.

Аудиты - это регистрация того, кто, когда и что делал в приложении. В таких случаях вообще нельзя использовать логи. Самый простой способ — хранить данные аудита в БД вместе с данными. В одной транзакции вносите и изменение, и запись, кто его сделал.

Поэтому, когда кто-то говорит: «Нам нужно логировать это в следующий раз», - подумайте, какое хранилище данных использовать и на какой срок нужны эти данные.

Продолжение следует…

Источник: https://youtu.be/SvcRvolP2NE