logging - 您遵循哪些准则来编写良好的日志记录语句

Question

我最近在我的项目代码库中发现了一条日志语句，上面写着“我在这里使用搜索参数==>============11/30/2008===1====00:00 AM”

在应用程序中编写良好的日志消息时，您遵循哪些准则？

Answer 1

那个“log”语句看起来更像是一个跟踪语句。

日志记录:显示正常事件和错误

跟踪:显示执行路径以及所有日志记录事件

就我个人而言，我希望通过日志记录来找出我的程序完成了哪些工作，并且希望使用跟踪语句来验证执行路径并找出出了什么问题。我会将跟踪语句路由到一个单独的文件，其中包含上下文的两种类型的日志消息。

因此您至少应该有 2 个日志级别，并且能够关闭性能跟踪。您应该能够将这些事件流路由到不同的位置。这使您可以轻松保留历史记录的日志，同时不会让它们与您只想跟踪问题的调试信息混在一起。

这里的很多答案都集中在您将包含在日志消息中的字段，但我认为日志调用的位置和日志记录级别更重要。如果您使用 log4net，您将能够通过配置文件随意包含/排除日期戳，但是如果不重新编译，您将无法放置或删除日志语句，因此认真考虑它们的去向是有意义的。除了标准字段(例如时间戳和线程 ID 等)之外，您还想知道进行调用的类和方法名称。如果您遵循 Log4net 等人以您关心的类型命名记录器的最佳实践，那么 Log4net 等人已经处理了类名称。除此之外，我通常会包含方法名称。这对于跟踪尤其必要，但我将其包含在所有日志消息中。

记录:

您想要了解有关将要执行什么操作的足够信息，以便在出现问题时返回并进行查看。好的候选者是消息 ID、电子邮件地址以及唯一标识工作项的内容。一旦此类数据可用，此类消息就应该出现，这样当您向下阅读日志文件时，您将看到类似“尝试用 y 执行 x”之类的内容，然后如果我们看到异常，我们知道需要查看哪个工作项才能了解失败的原因。

记录异常应与“尝试”日志消息配对，以便在读取日志时异常消息在上下文中有意义。这意味着要考虑异常处理的结构。如果您使用 .net，并且只想记录异常，而不是处理它，那么您想要重新抛出相同异常，而不是新的异常，所以只需执行“throw”而不是“throw e”其中“e”是您的异常实例。如果没有意义，请查看此内容。

追踪:

这实际上更简单，通常我会在感兴趣的方法的开头和结尾处显示一条消息，例如书挡。在条目中，您可以打印影响程序流程的关键方法参数。在方法末尾记录消息是可选的，通常您会对查看类似于堆栈跟踪的跟踪感兴趣。没有它们你也可以计算出执行路径。

性能:

对于字符串性能，如果您使用 log4net 或类似的东西，请使用“*Format”方法。这在内部将使用 StringBuilder，这样您就不会一直付出不可变字符串的代价。一般来说，关键是能够关闭跟踪以提高性能，并使日志记录足够简洁以便保留，即使日志消息的成本很高。如果正确完成，它们的数量就不应该成为问题。