Сколько войти в приложение и сколько это слишком много?

Question

Просто интересно, сколько людей заходят в свои приложения ???

Я видел это:

"Мне обычно нравится использовать журнал ошибок Уровень для регистрации любых исключений, которые пойман приложением. я использую уровень журнала INFO как «первый уровень» схема отладки, чтобы показать, когда я введите или выйдите из метода. Оттуда я использовать уровень журнала DEBUG для отслеживания Подробная информация. ЖУРНАЛ ЖУРНАЛА уровень используется для любых исключений, которые Я не смог поймать в моей сети на основе приложения. "

Который имел этот пример кода с ним:

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 строками кода. Метод также теряет некоторую ясность и простоту.

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

Значит, мне интересно, что делают люди? ура Энтони

Answer 1

... эй, могу ли я получить значок за то, что его цитируют как тему в SO вопросе? 8 ^ D

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

В приведенном мною примере этот метод ежедневно регистрируется в режиме WARN. Это означает, что единственное, что регистрируется «по умолчанию», - это исключение. Если мне позвонил один из моих клиентов с сообщением об ошибке в приложении, им не нужно было читать мне какое-то загадочное сообщение на экране, я проскакивал в журнале и мог видеть, что происходит. В большинстве случаев ответ тут же.

Что произойдет, если ответ недоступен? Log4net позволяет мне обновить мой файл конфигурации (не требуется повторная компиляция, нет необходимости получать доступ к какому-либо специальному системному файлу на веб-сервере с разрешения системного администратора) и перейти в режим INFO. Теперь вы начинаете видеть второй слой регистрации. Возможно, код никогда не попадал в определенный цикл. Возможно, для поиска данных был пустой набор записей. Этот второй уровень отладки полезен, и журнал только немного увеличивается. Как только это будет сделано, я могу снова изменить конфигурацию и вернуться к легкой регистрации.

Естественно, если что-то ДЕЙСТВИТЕЛЬНО сумасшедшее, тогда я перехожу на полный уровень отладки и хочу знать, о чем сообщает каждая переменная, с какими DataRows я имею дело, и что происходит в приложении. На моем нынешнем месте работы у нас нет возможности выполнять удаленную отладку в наших веб-приложениях, и мы не всегда можем подключиться к производственной базе данных без потенциального расширения данных, поэтому следующая полная отладка - это следующая лучшая вещь.

Я согласен с большинством людей, которые считают, что чрезмерное ведение журнала может привести к выходу приложения из строя и вызвать больше проблем, чем оно того стоит. Если бы не рекомендовал этот вид подробного входа в приложение, либо, если приложение не гарантирует его по соображениям безопасности. Тем не менее, возможность использовать подробное ведение журнала при необходимости и без необходимости перекомпилировать мой код ОГРОМНО на мой взгляд, и если у вас есть инфраструктура, которая может позволить это легко (например, log4net), то я скажем, получилось красиво и многословно, и достаточно просто мысленно отфильтровать ссылки на код журнала, если вам нужно вернуться к самому коду.

Я прошу прощения, если я звучу в обороне или разглагольствования, я не имею в виду это в любом отношении. Я просто хотел представить немного больше информации о том, как и почему я настраивал логирование с помощью log4net в упомянутом методе. 8 ^ D

Answer 2

Это скорее сторона программирования art .

Вы не хотите регистрировать все. Но вы захотите зарегистрировать наиболее важные части системы.

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

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

ИМХО, регистрация каждого входа / выхода из метода является излишней и также создаст шум, тем более что вы можете просто встроить трассировку стека.

А для производительности используйте профилировщик .

Answer 3

Вы правы, что это делает код более сложным для чтения и сопровождения. Одна из рекомендаций - рассмотреть возможность использования инструмента AOP (Аспектно-ориентированного программирования), чтобы отделить логику логирования от логики приложения. Castle Windsor и Spring - это две вещи, которые приходят на ум в сообществе .Net, и вы можете их исследовать.

Answer 4

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

Для .NET вы можете использовать библиотеку AOP PostSharp, чтобы помочь регистрировать вход и выход функции вместе со значениями аргументов и т. Д.

Для получения справки о том, сколько нужно зарегистрировать приложение, ознакомьтесь со статьей «Системное ведение журнала и анализ журнала », автор Marcus Ranum.

Надеюсь, это поможет.

Answer 5

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

RWendi

Answer 6

С точки зрения безопасности регистрация может быть интересной темой. Я написал запись в блоге в CSO Online некоторое время назад после нескольких DDOS-атак. Это раздел, в котором я говорил о ведении журнала, надеюсь, это немного поможет:

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