Сколько нужно регистрировать в приложении, а сколько - слишком много?
Просто интересно, сколько людей заходят в свои приложения ???
Я видел это:
"I typically like to use the ERROR log level to log any exceptions that are caught by the application. I will use the INFO log level as a "first level" debugging scheme to show whenever I enter or exit a method. From there I use the DEBUG log level to trace detailed information. The FATAL log level is used for any exceptions that I have failed to catch in my web based applications."
Который был с этим образцом кода:
Public Class LogSample
Private Shared ReadOnly Log As log4net.ILog = log4net.LogManager.GetLogger(GetType(LogSample))
Public Function AddNumbers(ByVal Number1 As Integer, ByVal Number2 As Integer) As Integer
Dim intResults As Integer
Log.Info("Starting AddNumbers Method...")
Log.Debug("Number1 Specified: " & Number1)
Log.Debug("Number2 Specified: " & Number2)
intResults = Number1 + Number2
Try
intResults = Number1 + Number2
Catch ex As Exception
Log.Error("Error Adding Nubmers.", ex)
End Try
Log.Info("AddNumbers Method Complete.")
Return intResults
End Function
End Class
Но это, кажется, так много добавляет к методу. Например, класс, который обычно состоит из 7 строк кода, внезапно превращается в 12 строк кода. При этом метод теряет ясность и простоту.
Но говоря, что наличие регистрации на месте может быть полезным. Например, мониторинг производительности в производственной системе, отслеживание аномальных ошибок в производственной среде (не то чтобы у вас все это ведение журнала было включено постоянно.
Поэтому мне интересно, что люди делают? Ваше здоровье Энтони
Ответы 6
Вы правы в том, что это действительно затрудняет чтение и сопровождение кода. Одна из рекомендаций - рассмотреть возможность использования инструмента АОП (аспектно-ориентированного программирования), чтобы отделить логику ведения журнала от логики приложения. Castle Windsor и Spring - две вещи, которые приходят на ум в сообществе .Net, и вы, возможно, захотите изучить их.
С точки зрения безопасности ведение журнала может быть интересной темой. Я написал запись в блоге в CSO Online некоторое время назад после нескольких DDOS-атак. В этом разделе я говорил о ведении журнала, надеюсь, это немного поможет:
Techniques such as log throttling, write only logs, and using log servers can strengthen the retroactive security of a system. After a possible DDoS attack has occurred the company will no doubt want to investigate the attack. An investigation is only possible if the correct level of logging has been used. Too much and the logs will quickly become filled, which could be the reason for the DoS in the first place. Too little and the logs will be worthless because they don’t contain enough information to catch the criminal.
Это скорее искусство сторона программирования.
Вы не хотите регистрировать все. Но вам нужно будет регистрировать самые важные части системы.
Просто подумайте о своей программе в широком смысле и попытайтесь определить, какая информация вам понадобится в случае, если что-то сломается в работе.
Для начала, все основные логические модули вашего приложения должны иметь функцию ведения журнала. Декоративные детали, например. Пользовательский интерфейс / анимация не должны регистрироваться.
IMHO, регистрация каждого входа / выхода метода является излишним, а также создает шум, особенно потому, что вы можете просто встроить трассировку стека.
А для повышения производительности используйте профайлер.
Ведение журнала - это автономный профилировщик. У вас может не быть ничего, кроме этого.
... эй, а я получу значок за то, что меня процитировали как тему в SO-вопросе? 8 ^ D
А если серьезно, то одну вещь, которую я хочу прояснить по поводу приведенного выше комментария о журналировании, заключается в том, что отчасти мое оправдание «подробного» журналирования основано на том факте, что я использую возможности самого log4net.
В представленном мною примере этот метод ведет журнал ежедневно в режиме WARN. Это означает, что единственное, что регистрируется «по умолчанию», - это если возникает исключение. Если мне звонит один из моих клиентов по поводу ошибки в приложении, ему не нужно читать мне какое-то загадочное сообщение на экране, я захожу в журнал и вижу, что происходит. В большинстве случаев ответ тут же.
Что произойдет, если ответ недоступен? Log4net позволяет мне обновить мой файл конфигурации (не требуется повторная компиляция, нет необходимости получать доступ к какому-то специальному системному файлу на веб-сервере с одобрения системного администратора) и перейти в режим INFO. Теперь вы видите второй уровень регистрации. Возможно, код так и не дошел до определенного цикла. Возможно, при извлечении данных был пустой набор записей. Этот второй уровень отладки полезен, и журнал становится только немного больше. Как только это будет сделано, я могу снова изменить конфигурацию и вернуться к легкому ведению журнала.
Естественно, если что-то ДЕЙСТВИТЕЛЬНО сумасшедшее, я перехожу на уровень полной отладки и хочу знать, что сообщает каждая переменная, с какими DataRows я имею дело и что происходит в приложении. На моем текущем месте работы у нас нет возможности выполнять удаленную отладку в наших веб-приложениях, и мы не всегда можем подключиться к производственной базе данных без потенциального пополнения данных, поэтому полноценная отладка - это лучший вариант.
Я согласен с большинством людей в том, что чрезмерное ведение журнала может действительно вывести приложение из строя и вызвать больше проблем, чем оно того стоит. Я бы не рекомендовал такой вид подробного ведения журнала в приложении, если только приложение не требует этого из соображений безопасности. Тем не менее, возможность использовать подробное ведение журнала, когда это необходимо, и без необходимости перекомпилировать мой код, на мой взгляд, дает преимущество ОГРОМНЫЙ, и если у вас есть структура, которая может это легко разрешить (например, log4net), тогда я говорю, что будьте красивыми и подробными, и это достаточно легко мысленно отфильтровать ссылки кода журнала, если вам нужно вернуться в сам код.
Прошу прощения, если я защищаюсь или разглагольствую, я не имею в виду это ни в коем случае. Я просто хотел предоставить немного больше информации о том, как и почему я настраиваю ведение журнала с помощью log4net в упомянутом методе. 8 ^ D
Эй, чувак ... прими это как дополнение к тому, что я использовал тебя как источник. Между прочим, отличная статья, и она побудила меня переосмыслить некоторые вещи, так что не воспринимайте это как плохо.
Ведение журнала - это, по сути, автономный отладчик, в котором вы должны заранее подготовить все вопросы.
Как минимум, вы должны регистрировать ошибки и вызовы внешнего компонента ... Предоставляемый вами образец - это то, что я бы назвал СЛИШКОМ много журналов ... Нет смысла регистрировать то, что вы находитесь в начале метода или в конец метода или даже параметры, которые были переданы методу ... Это пустая трата дискового пространства, ваш файл журнала станет очень большим в кратчайшие сроки ...
Определить, сколько журналов достаточно, непросто. Слишком много кода регистрации в функции, как в вашем примере, скрывает фактический логический код. Слишком много записей в журнале делает журнал шумным. Но слишком мало журналов не очень помогает !!
Для .NET вы можете использовать AOP-библиотеку PostSharp, чтобы помочь регистрировать вход и выход из функции вместе со значениями аргументов и т. д.
Если вам нужна помощь в определении объема журналирования вашего приложения, прочтите статью ««Системный журнал и анализ журналов» Маркуса Ранума.
Надеюсь это поможет.