应用程序中需要记录多少日志？什么程度的日志记录过多？

Question

只是想知道人们在他们的应用程序中记录了多少日志？我见过这个：

“我通常喜欢使用ERROR日志级别来记录应用程序捕获的任何异常。我将使用INFO日志级别作为“第一级”调试方案，以显示我何时进入或退出方法。从那里开始，我使用DEBUG日志级别跟踪详细信息。FATAL日志级别用于我未能在基于Web的应用程序中捕获的任何异常。”

其中包含了这个代码示例：

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行代码。该方法也失去了一些清晰和简单性。

但是话说回来，拥有日志记录的好处是很大的。例如，在生产系统中进行性能监控，在生产中追踪异常错误（并不是您所有时候都需要开启此日志记录）。

因此，我想知道人们是如何做到的呢？ 谢谢 安东尼

- vdhant

---

https://dev59.com/_UXRa4cB1Zd3GeqPrWMW - Milan Babuškov

Answer 1

这更多涉及编程的艺术方面。

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

只需从整体上考虑您的程序，并尝试确定在生产环境中出现故障时需要哪些信息。

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

我认为，记录每个方法的进入/退出都会产生过多的噪音，特别是因为您可以嵌入堆栈跟踪。

对于性能问题，请使用分析器。

- chakrit

---

日志记录是一种离线分析工具。你可能没有其他的选择。 - Thorbjørn Ravn Andersen

Answer 2

……嘿，我在SO问题中被引用，能得到徽章吗？8^D

但是说真的，我想澄清一下上面关于日志记录的评论，其中部分理由是基于我正在利用log4net本身的功能。

在我提供的示例中，该方法以WARN模式每天记录一次。这意味着“默认情况下”只记录发生异常的内容。如果我的客户给我打电话说应用程序出现错误，他们不必向我念屏幕上的加密消息，我可以查看日志并了解正在发生的情况。大多数时候，答案就在那里。

如果答案不容易获得会怎么样？Log4net允许我更新配置文件（无需重新编译，无需获取sysadmin批准的某个特殊系统文件），然后进入INFO模式。现在你开始看到第二层日志记录。也许代码从未到达某个循环。也许数据检索具有空记录集。这种第二级别的调试非常有用，而且日志仅略微增大。完成此操作后，我可以再次更改配置并回到轻量级日志记录。

当然，如果情况确实很疯狂，那么我会进入完全调试级别，并想知道每个变量的报告，我正在处理哪些数据行以及应用程序的运行情况。在我目前的工作场所，我们无法对我们的Web应用程序进行远程调试，并且我们不能总是在不改变数据的情况下访问生产数据库，因此拥有这种完全调试是次优选择。

我同意大多数人的观点，即过度记录可能会导致应用程序崩溃并引起更多问题，除非出于安全原因，否则不建议在应用程序中使用这种详细记录。然而，当需要时能够利用详细日志记录并且无需重新编译代码是我认为巨大的好处，如果您有一个可以轻松实现它的框架（例如log4net），那么我建议您尽情记录，如果必须返回到代码本身，则很容易过滤掉日志代码引用。

如果我听起来很防御或发牢骚，我对此表示歉意，我没有任何意图。我只是想提供有关如何以及为什么在上述方法中使用log4net设置我的日志记录的更多背景信息。8^D

- Dillie-O

---

嘿，老兄……把我用作信息来源，当做是一种赞美吧。顺便说一下，你写的文章很棒，它激发了我重新思考一些事情，所以不要把它看成是一件坏事。 - vdhant

日志记录本质上是一种离线调试器，您必须事先准备好所有问题。 - Thorbjørn Ravn Andersen

Answer 3

您说得没错，这确实使代码更难以阅读和维护。建议考虑使用AOP（面向切面编程）工具来将日志记录逻辑与应用程序逻辑分离。在.Net社区中，Castle Windsor和Spring是两个值得研究的工具。

- SaaS Developer

Answer 4

决定记录多少内容并不容易。与您的示例中一样，在函数中有太多的日志代码会淹没实际的逻辑代码。太多的日志条目使日志嘈杂。但是记录太少又不太有帮助！

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

如果需要确定要记录多少应用程序日志，请查看Marcus Ranum的文章"系统记录和日志分析"。

希望这可以帮到您。

- tranmq

Answer 5

从安全角度来看，日志记录可能是一个有趣的话题。我曾在一段时间前在CSO Online上写了一篇博客文章，针对几次DDOS攻击。这是我谈论日志记录的部分，希望能有所帮助：

技术手段，如日志限流、仅写日志和使用日志服务器，可以增强系统的反向安全性。在可能发生DDoS攻击后，公司无疑会想要调查这次攻击。只有使用了正确级别的日志记录，才能进行调查。如果记录过多，日志将很快变满，这可能是DoS攻击的原因。如果记录过少，日志将毫无价值，因为它们不包含足够的信息来抓住罪犯。

- joebasirico

Answer 6

在最基本的情况下，您应该记录错误和调用外部组件...您提供的示例是我所谓的过度记录...记录您进入方法的起点或结束点甚至传递给该方法的参数是没有意义的...这浪费了磁盘空间，您的日志文件很快就会变得非常大...

RWendi

- RWendi