Регистрация хороших / проверенных практик - EntLib

Question

В настоящее время я работаю над регистрацией для нашего корпоративного приложения.Мы (команда) договорились об использовании библиотеки Enterprise.И мне нужно сделать какой-нибудь документ на эту тему, но я новичок, и это довольно сложно.Мне нужно, если вы можете сделать несколько замечаний, что указывать.И каковы лучшие практики.Пока я нашел только конкретные статьи о том, как сделать это в коде, это не то, чего я хочу, мне нужно немного поговорить о том, что регистрировать, как регистрировать, что и так.Это приложение MVC, написанное на .Net

Answer 1

У меня есть общая теория о приборостроении. Все начинается с «мысленного эксперимента». Представьте, что в приложении вообще нет инструментария, и оно развертывается в Production. Что именно произойдет, чтобы заставить нас пожелать, чтобы мы проинструктировали приложение?

Мой ответ таков: в общем, существует ряд вещей, о которых приложение знает, о которых мы хотели бы, чтобы они нам сообщали. Это набор вещей, которые мы должны использовать.

1. Возможно, нам хотелось бы знать, как часто происходит определенное событие (например, сколько раз пользователь выходил из системы, поскольку сеанс истек).
2. Может статься, что нам хотелось бы знать о любых необработанных исключениях (почти бесплатно получить это с помощью ASP.NET Health Monitoring, но все же).
3. Возможно, нам хотелось бы, чтобы мы знали с сайта вызова пять фрагментов некоторого кода, который только что вызвал исключение.

В первом случае предлагается добавить счетчик производительности. Второй предлагает нам включить мониторинг здоровья. Третий предполагает, что мы регистрируем некоторую дополнительную информацию во время исключения (и затем используем throw;, чтобы позволить распространению исключения).

На мой взгляд, ни в одном из этих случаев не стоит тратить время на регистрацию каждой записи и выхода из функции и всех параметров, а также на то, что мы должны перехватывать каждое исключение и регистрировать его перед его сбросом (или игнорированием).

Это означает, что программа дает нам «слишком много информации».

Answer 2

Рассмотрите свою аудиторию.В этих сценариях появляется журнал

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

для отладки / трассировки.Аналогично ведению журнала ошибок, но записывает, даже когда ничего не пошло не такПеред ошибкой трудно сказать, какая трассировка будет наиболее ценной, поэтому вы часто регистрируете области, в которых, как вы подозреваете, есть ошибки, или области, в которых по факту вы захотите узнать, какие методы выполнялись.EntLib оптимизирован для такого рода журналирования.EntLib на самом деле не лучший для других целей ведения журналов, которые я перечислю здесь.

для настройки производительности, в этом случае вы действительно хотите, чтобы ведение журнала было временным или просто улавливало случаи низкой производительности.

для безопасности, где вы пытаетесь обнаружить случаи "плохого поведения". Аудитория может быть отделом кадров или правоохранительными органами.

для бизнес-ориентированных вещей.В этом случае аудитория является клиентом.

Answer 3

Размышляя о своей стратегии ведения журналов, очень важно подумать о том, как ваши записи в журнале будут впоследствии использоваться или обрабатываться.Слишком часто ценная контекстная информация теряется, когда события сглаживаются во время регистрации;тем самым делая журналы менее полезными для устранения неполадок.

Семантическая регистрация позволяет сохранить семантическую ценность дискретных полезных нагрузок.Это также помещает усилия в нужное место и делает ваш код приложения чище.Я обсуждаю это далее в этом сообщении .

Answer 4

Как правило, вы должны подумать о своих требованиях (если нет бизнес-требований, то о технических требованиях) и попытаться их удовлетворить.

С точки зрения количества регистрируемых материалов, я бы предпочел больше инструментов, чемменьше (при условии, что уровни можно поворачивать вверх и вниз).Вы будете благодарны, когда столкнетесь с той странной производственной проблемой, которая не имеет никакого смысла.

Вот некоторые соображения:

• Возможность включения различных уровней ведения журнала
• Возможность включения ведения журнала для разных сборок / классов
• Возможность включенияведение журнала для различных функциональных областей
• Возможность ведения журнала записей / выходов / таймеров метода
• Возможность изменения уровней ведения журнала во время выполнения без изменения кода
• Где находятся журналы?Центральный репозиторий или различные распределенные журналы?
• Что такое формат ведения журнала (например, XML)?Стандартизированная информация или ad-hoc?
• Вам нужны уникальные идентификаторы событий?
• Будет ли протоколирование инициировать оповещения / уведомления (например, Tivoli)?Если да, каковы требования?
• Нужно ли иметь возможность создавать отчеты / запросы в журналах

Также рассмотрите возможность использования внедрения политики / AOP для сквозных задач ведения журнала.

Я бы порекомендовал не использовать Приоритет, если у вас нет веских причин для этого (категория и серьезность, вероятно, должны быть достаточно гибкими). ​​

Answer 5

Ниже приведены некоторые рекомендации по входу в производственную систему:

• Регистрируйте только те вещи, которые полезны или превышают определенный уровень ведения журнала. Не устанавливайте ведение журналаслишком низкий уровень, это приведет к тому, что многие вещи будут регистрироваться.Если вы ведете слишком много журналов, это повлияет на производительность вашего приложения, так как ведение журнала включает файловый ввод / вывод.

• Также регистрируйте имя потока и имя класса, полезно отладить, если кодывыполняются несколькими потоками.