Logging Framework, хорошая идея?

Question

Прежде всего, извинения за субъективно звучащее название. Это задуман как прямой вопрос.

В настоящее время я работаю над набором инструментов:

• Служба C # Windows, в первую очередь поддерживать базу данных Oracle.
• Служба C # Windows, (которая будет используется на сайтах с несколькими узлами) для обрабатывать содержимое базы данных.
• Веб-интерфейс ASP.NET для облегчить управление в целом "Система"

В настоящее время службы Windows разработаны как консольные приложения (для упрощения отладки / разработки), и я нахожусь в процессе преобразования этих служб в службы. После тестирования в течение нескольких дней с этими службами я обнаружил, что хотел бы повысить степень детализации ведения журнала. Я обнаружил, что мне не хватает Console.WriteLine (), и я хотел бы предоставить альтернативный источник журнала, такой как плоский файл для этого типа вывода. Это заставило меня задуматься: «Должен ли я использовать фреймворк или мне достаточно?»

Причина, по которой я упомянул аспекты, которые я разрабатываю, состоит в том, чтобы дать представление о моей ситуации. Была создана «основная» DLL, общая для всех компонентов, абстрагирующая уровень взаимодействия между приложениями и базой данных. Именно в этой DLL был создан класс, который будет пытаться "войти в таблицу в базе данных", иначе при ошибке "войти в локальный журнал событий". Вот и все, это степень ведения журнала.

В вышеупомянутых инструментальных средствах есть несколько случаев регистрации, не отличающихся от:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

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

Мой вопрос

Глядя на мое текущее решение для ведения журнала, оно кажется «достаточным» с точки зрения того, что оно делает и как оно интегрировано со всеми моими решениями. Тем не менее, я смотрел на каркасы журналов (особенно log4net), и их возможности меня впечатлили. Возможность, если потребуется в будущем, добавить другой выходной формат (например, SMTP-сервер) звучит для меня немного круто! :)

Что я хотел бы знать, это преимущества перехода на фреймворк (например, log4net)? Насколько мне придется адаптировать мой код? Или я просто смотрю на зеленую траву на другой стороне? И, наконец, но, наверное, самое главное, я поступаю правильно? Должен ли я просто добавить возможность к своему классу Log в «LogDebug» и покончить с этим? Последнее, что я хотел бы сделать, это полностью пересмотреть мой пакет, просто для «базовой» функции, но если есть другие преимущества (дизайн, надежность, хорошая практика и т. Д.), Я заинтересован.

Спасибо,

Answer 1

Да. Хорошая идея - использовать существующую, проверенную среду ведения журналов (например, Log4net).

Log4Net настраивается во время выполнения (отлично подходит для отслеживания проблем в рабочем коде).

Как отметил комментатор, он также очень прост в использовании.

Answer 2

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

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

Что касается его реализации, есть несколько хороших сайтов, рассказывающих вам о настройке. То, как вы на самом деле используете объекты журналирования, которые предоставляет вам log4net, является архитектурным выбором, но вы можете просто изменить конструктор объекта на объект log4net, и из этого объекта просто использовать объект log4net так же, как Console.WriteLine. .

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

Answer 3

Да, вы определенно хотите использовать каркас журналирования. Каркас ведения журнала позволит вам:

• Установить уровни ведения журнала для разных экземпляров регистратора.
• Установите «appenders» или вывод для каждого из различных экземпляров регистратора.

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

Answer 4

Я собираюсь поблагодарить NLog (http://nlog -project.org / home ), поскольку он не страдает от синдрома «Прямой порт Java - затем переписать» большинства oss .Net libs.

Некоторыми ключевыми преимуществами для нас были очень быстрый Logger.IsFooEnabled (volatile read) и общая производительность системы.

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

Ура, Florian

Answer 5

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

Например, ELMAH для приложений ASP.net. Он также включает уведомления, экспорт в различные целевые форматы и т. Д. Вещи, которые довольно удобны, но вы никогда не создадите сами, если вам это действительно не нужно.

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

Answer 6

Я думаю, что вы должны использовать Log4net просто потому, что всегда лучше использовать повторно, чем создавать свои собственные вещи. log4net используется многими разработчиками и довольно зрелый.

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

Answer 7

Я думаю, что системные администраторы ожидают, что службы войдут в журнал событий приложений в Windows.

Посмотрите System.Diagnostics.EventLog, хотя log4net также запишет в него ..

Answer 8

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

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

Answer 9

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

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

Кроме того, вы можете написать свой собственный класс, который будет довольно абстрактным, и поместить туда свой базовый код, если вам когда-нибудь понадобится использовать внешнюю среду для тестирования, ваш класс сможет использовать ее с минимальным воздействием на код. Просто посмотрите, как там реализованы фреймворки на уровне кода.

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

Answer 10

Первоначальное утверждение на сайте log4j может помочь в некоторых ваших вопросах, основные принципы те же, что и в log4net:

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

Используя иерархию логгера, это можно контролировать, какой журнал выписки выводятся произвольно тонкая зернистость, но также и легкость. Это помогает уменьшить объем зарегистрированных выводить и минимизировать стоимость каротаж.

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