Платформа ведения журнала, хорошая идея?
https://stackoverflow.com/questions/1606088
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Прежде всего, приношу извинения за субъективно звучащее название.Это задумано как прямой вопрос.
В настоящее время я работаю над набором инструментов:
- Служба C # Windows, предназначенная в первую очередь для обслуживания базы данных Oracle.
- Служба C # Windows (которая будет использоваться на нескольких узловых сайтах) для обработки содержимого базы данных.
- ASP.NET Веб-интерфейс для облегчения управления всей "системой"
В настоящее время службы Windows tho разработаны как консольные приложения (для облегчения отладки / разработки), и я нахожусь в процессе преобразования их в службы.После тестирования в течение пары дней с этими сервисами я обнаружил, что хотел бы повысить детализацию моего ведения журнала.Я обнаружил, что мне не хватает консоли.WriteLine() и я хотел бы предоставить альтернативный источник журнала, такой как плоский файл, для этого типа вывода.Это навело меня на мысль: "Должен ли я использовать фреймворк, или у меня его достаточно?"
Причина, по которой я упомянул аспекты, которые я разрабатываю, заключается в том, чтобы дать представление о моей ситуации.Была создана "Основная" библиотека DLL, общая для всех компонентов, абстрагирующая уровень взаимодействия между приложениями и базой данных.Именно в этой DLL был создан класс, который попытается "войти в таблицу в базе данных", иначе при сбое "войти в локальный журнал событий".Вот оно, вот масштабы ведения журнала.
Во всех вышеупомянутых инструментах существует множество примеров ведения журнала, не отличающихся от:
Log.LogError("Code", e.Message + "\n" + e.StackTrace);
Хотя этот метод довольно прост, он использует отражение для определения источника ошибки.
Мой Вопрос
Глядя на мое текущее решение для ведения журнала, оно кажется "достаточным" с точки зрения того, что оно делает и как оно интегрировано со всеми моими решениями.Тем не менее, я изучал фреймворки ведения журнала (в частности log4net), и их возможности впечатляют меня.Возможность, при необходимости в будущем, добавить другой формат вывода (например, SMTP-сервер) звучит для меня довольно круто!:)
Что я хотел бы знать, так это преимущества перехода на фреймворк (например, log4net)?В какой степени мне придется адаптировать свой код?Смотрю ли я просто на более зеленую траву на другой стороне или нет?И, наконец, но, вероятно, самое главное, правильно ли я поступаю?Должен ли я просто добавить возможность моего класса Log в "LogDebug" и покончить с этим?Последнее, что я хотел бы сделать, это полностью пересмотреть свой пакет, просто для "базовой" функции, но если есть другие преимущества (для дизайна, надежности, хорошей практики?и т.д.) Мне интересно.
Спасибо,
Решение
Правильное ведение журнала особенно полезно при запуске кода на нескольких удаленных системах, насколько я помню, log4net позволит вам отправлять ваши журналы на удаленный сервер системного журнала без особых затрат на кодирование (это означает, что вы можете просматривать свои журналы со всех компьютеров в одном централизованном месте). Это значительно сократит время, необходимое вам для получения информации, касающейся ошибки или проблемы с системой, а также должно дать вам представление о том, насколько распространена проблема.
Как упоминалось в других сообщениях, log4net также допускает несколько отправителей и несколько уровней ведения журнала, поэтому определите, где вам нужна определенная информация журнала (т.е.в базе данных или в локальном плоском файле, hey log4net даже позволяет вам передавать журналы через telnet), которые будут сохранены, - это абсолютная ерунда.
Что касается его реализации, есть несколько хороших сайтов, рассказывающих вам о настройке.То, как вы на самом деле используете объекты ведения журнала, которые предоставляет вам log4net, является архитектурным выбором, но вы могли бы просто изменить конструктор объекта, чтобы использовать объект log4net и из этого объекта просто использовать объект log4net в качестве консоли.Строка записи.
Я нахожу серию обучающих программ здесь особенно полезно, и в нем также будет рассказано более подробно, чем я могу здесь, о преимуществах и различных способах настройки log4net.
Другие советы
ДА.Использование существующей, проверенной платформы ведения журнала (такой как Log4net) - хорошая идея.
Log4Net настраивается во время выполнения (отлично подходит для отслеживания проблем в производственном коде).
Как отметил один из комментаторов, он также очень прост в использовании.
Да, вы определенно хотите использовать систему ведения журнала.Структура ведения журнала позволит вам:
- Установите уровни ведения журнала для разных экземпляров регистратора.
- Установите "добавляющие" или выходные данные для каждого из различных экземпляров регистратора.
Возможно, что еще более важно, если вы используете платформу ведения журнала, очень легко заменить одну реализацию платформы ведения журнала на другую (возможно, нулевую реализацию, которая просто отбрасывает сообщения);принимая во внимание, что если вы напишете все свои инструкции протоколирования напрямую, замена реализации станет кошмаром.
Я думаю, вам следует использовать Log4net просто потому, что его всегда лучше использовать повторно, чем создавать свой собственный.log4net использовался многими разработчиками и является довольно зрелым.
Подумайте о вашей перспективе на техническое обслуживание;через один или два месяца вам, возможно, потребуется немного подправить свой пользовательский класс ведения журнала, добавить некоторую поддержку многопоточности и т.д.И когда вы будете исправлять ошибки, возникшие в вашем классе ведения журнала, вам будет не хватать Log4net.
Что ж, одно из самых больших преимуществ заключается в том, что вам не нужно самостоятельно поддерживать код.В большинстве случаев фреймворки ведения журнала обладают гораздо большей функциональностью, чем ваше собственное решение.Поскольку они настолько сосредоточены на ведении журнала, эти фреймворки обычно довольно полны как по функциональности, так и по способам ее реализации.И потом, есть еще надежность;нет ничего хуже, чем платформа ведения журнала, которая ничего не регистрирует, потому что она прослушивается.;)
Возьмем, к примеру, ЭЛЬМА для ASP.net приложений.Он также включает уведомления, экспорт в различные целевые форматы и т.д.Вещи, которые довольно удобны, но вы никогда не создадите сами, если вам это действительно не нужно.
Очевидно, что количество необходимых изменений в вашем коде зависит как от вашего кода, так и от выбранного фреймворка.Трудно что-либо сказать по этому поводу.
Я собираюсь крикнуть об этом NLog (http://nlog-project.org/home) поскольку он не страдает от синдрома "Прямого переноса Java - затем перезаписи" большинства операционных систем .Сетевые библиотеки.
Одними из ключевых преимуществ для нас были очень быстрый регистратор.IsFooEnabled (изменяемое чтение) и общая производительность системы.
Хотя каждому свое, но лично я предпочитаю NLog для своих проектов (и некоторые мои клиенты тоже).
Приветствия, Флориан
Преимущество использования хорошей платформы ведения журнала, такой как Log4Net, заключается в том, что они оказывают небольшое влияние на ваш код с точки зрения строк кода, которые вы должны изменить (другими словами, вам нужно изменить только каждую существующую строку ведения журнала).
Кроме того, если вы обеспокоены изменением своего кода при смене фреймворков или если вы чувствуете, что хотите создать свой собственный, то вы всегда можете создать свой собственный интерфейс для a структура ведения журнала.После этого вам нужно будет изменить свой код только в одном месте.
Я думаю, системные администраторы ожидают, что службы будут регистрироваться в журнале событий приложения в Windows.
Посмотрите систему.Диагностика.Журнал событий, хотя log4net и в это тоже запишет..
Первоначальное утверждение в веб - сайт log4j может помочь в некоторых ваших вопросах, основополагающие принципы те же, что и в log4net:
С log4j можно включить ведение журнала во время выполнения без изменения двоичного файла приложения.log4j Пакет разработан таким образом, что эти инструкции могут оставаться в поставляемом коде без значительного снижения производительности затрат.Поведением ведения журнала можно управлять, редактируя конфигурацию файл, не касаясь приложения двоичный.
Используя иерархию регистратора, можно управлять тем, какой журнал инструкции выводятся произвольно высокая степень детализации, но также и большая простота.Это помогает уменьшить объем регистрируемых выходных данных и минимизировать затраты на ведение журнала.
В этом случае явно нет необходимости изобретать велосипед.Большинство фреймворков ведения журнала несколько просты, поэтому масштаб изменений, скорее всего, будет зависеть от размера ваших существующих программ.
если вы правильно напишете свой класс logger, его можно будет легко использовать для любых ваших нужд.Любой фреймворк может поразить вас множеством функций, но другой фреймворк - это еще одна переменная в вашем процессе отладки, поскольку он может выдать вам ошибку, которой не существует, или может выдать ошибку сам по себе в сочетании с вашим приложением.Если вы готовы провести бета-тестирование проекта программного обеспечения с открытым исходным кодом, это прекрасно...
На вашем месте я бы написал класс log с возможностью расширения его функциями, которые вы сочтете интересными для вашего проекта, на основе списка функций, которыми обладают известные фреймворки.Я не вижу никакой проблемы в том, чтобы записать что-то в файл, а затем отправить это через smpt, просто одна небольшая функция выполняет эту работу.
Более того, вы можете написать свой собственный класс, который будет довольно абстрактным, и поместить туда свой базовый код, если вам когда-нибудь понадобится использовать внешний фреймворк для тестирования, ваш класс сможет использовать его с минимальным воздействием на код.Просто взгляните, как там фреймворки реализованы на уровне кода.
подумайте о том, что вам нужно будет научиться правильно использовать эти фреймворки, когда на данный момент вам нужно записать только очень небольшую их часть...
