Question

只是想知道有多少人在他们的应用程序中登录???

我见过这个：

“我通常喜欢使用ERROR日志记录任何异常的级别被应用程序抓住了。我会用的 INFO日志级别为“第一级” 调试方案，以显示我进入或退出方法。从那里我使用DEBUG日志级别进行跟踪详细资料。致命日志 level用于任何异常我没有抓住我的网络应用。“

其中包含此代码示例：

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

这是编程的 art 方面。

您不想记录所有内容。但是您需要记录系统中最关键的部分。

从广义上考虑您的计划，并尝试确定在生产中出现问题时您需要哪些信息。

首先，应用程序的所有核心逻辑模块都应具有日志记录功能。装饰部件，例如UI /动画不应该需要记录。

恕我直言，记录每个方法的入口/出口都是过度的，并且还会产生噪音，特别是因为你可以嵌入一个堆栈跟踪。

为了提高性能，请使用 profiler 。

Answer 2

...嘿，我是否在SO问题中获得被引用作为主题的徽章？ 8 ^ d

但严重的是，我想澄清一下上面关于日志记录的一点是我对“详细”日志记录的理由部分是基于我正在利用log4net本身的功能这一事实。

在我提供的示例中，该方法每天以WARN模式登录。这意味着“默认情况下”唯一记录的是发生异常。如果我从我的一个客户那里得到一个关于在应用程序中出错的电话，他们就不必在屏幕上看到一些神秘的消息，我跳进日志并看看发生了什么。大多数时候，答案就在那里。

如果没有答案，会发生什么？ Log4net允许我更新我的配置文件（无需重新编译，无需通过sysadmin的批准访问Web服务器上的某些特殊系统文件）并进入INFO模式。现在您开始看到第二层日志记录。也许代码从未进入某个循环。也许数据检索有一个空记录集。第二级调试很有帮助，日志只会略大一些。完成后，我可以再次更改配置并返回光记录。

当然，如果事情真的很疯狂，那么我会进入完整的调试级别，我想知道每个变量报告的内容，我正在处理的DataRows以及应用程序中发生了什么。在我目前的工作地点，我们无法对我们的Web应用程序进行远程调试，并且我们无法在不增加数据的情况下始终使用生产数据库，因此完成此调试是最好的选择。

我同意大多数人的意见，即过度的日志记录确实会导致应用程序崩溃并导致更多问题而不是值得。如果不建议在应用程序中进行这种详细的日志记录，除非应用程序出于安全原因对其进行保证。但是，能够在需要时利用详细日志记录而无需重新编译我的代码在我看来是一个巨大的好处，如果你有一个可以轻松实现它的框架（例如log4net），那么我说变得好看又冗长，如果你不得不重新使用代码本身就很容易过滤掉日志代码引用。

如果我听起来有防御性或咆哮，我道歉，我不是故意的。我只想提供更多背景知识，了解如何以及为什么我在上述方法中使用log4net设置日志记录。 8 ^ d

Answer 3

这是对的，这确实使代码更难以阅读和维护。一个建议是考虑使用AOP（面向方面编程）工具将记录逻辑与应用程序逻辑分开。城堡温莎和春天是您可能想要研究的.Net社区中的两个想法。

Answer 4

从安全角度来看，日志记录可能是一个有趣的话题。在一些DDOS攻击之后，我在CSO Online上写了blog entry一段时间。这是我谈到日志记录的部分，希望它有所帮助：

日志限制等技术只写日志，并使用日志服务器可以加强追溯力系统的安全性。可能之后公司发生了DDoS攻击毫无疑问，我想调查一下攻击。只是调查如果正确的水平可能记录已被使用。太多了日志很快就会被填满这可能是DoS的原因首先。太少了日志将毫无价值，因为他们不包含足够的信息抓住罪犯。

Answer 5

至少你应该记录错误并调用外部组件...你提供的样本就是我称之为TOO的大量记录......没有记录你是在一个方法的开头，或者在方法的最后，甚至是传递给方法的参数......它浪费了磁盘空间，你的日志文件会立刻变得非常大......

RWendi

Answer 6

要确定多少日志记录就不容易了。函数中的日志代码太多，如示例所示，会掩盖实际的逻辑代码。日志条目太多会使日志嘈杂。但是太少的日志不是很有帮助!!

对于.NET，您可以使用AOP库PostSharp来帮助记录函数的输入和退出以及参数的值等。

有关确定记录应用程序的数量的帮助，请查看此文章"System Logging and Log Analysis＆＃34;作者：Marcus Ranum。

希望这有帮助。

在应用程序中登录多少以及多少？

6 个答案: