代码与日志记录比率？

Question

记录比例的理想代码是什么？我不习惯编写日志，因为我开发的大多数应用程序没有太多日志记录。

最近虽然我改变了工作，但我注意到你看不到调用log4net的应用程序代码。我很欣赏这很有用，但是确实有太多的调试语句就像没有任何调试语句一样糟糕吗？

有一些日志记录语句可以告诉您每个方法何时开始和结束以及它们返回的内容。几乎任何事情都完成了。

在编译时使用反射来添加日志语句是不是更容易，因此当你试图查看代码时它们不会妨碍它？

同样在强大的IDE和远程调试的这些日子里，很多日志记录真的很麻烦吗？

Answer 1

由于log4net在不堵塞资源方面做得很好，我对日志记录有点冗长，因为当你必须更改为调试模式时，你拥有的信息越多越好。这是我通常记录的内容：

DEBUG等级

• 传入的任何参数 方法
• 我检索的结果集中的任何行计数
• 传递给方法时可能包含可疑数据的任何数据行
• 任何“生成的”文件路径，连接字符串或其他在环境“拼凑”时可能被混淆的值。

信息等级

• 方法的开始和结束
• 任何主要循环的开始和结束
• 任何主要案例/开关陈述的开始

错误级别

• 处理异常
• 无效的登录尝试（如果安全性存在问题）
• 我截获报道的错误数据

致命等级

• 未处理的例外情况。

还有很多日志记录详细信息阻止我在收到错误消息时询问用户他们在做什么。我可以很容易地将它拼凑在一起。

Answer 2

完整的日志文件非常有用。考虑将应用程序部署在银行等某个地方的情况。您无法进入并手动调试它们肯定不会向您发送数据。您可以获得的是一个完整的日志，可以指出您遇到问题的位置。拥有多个日志级别非常有用。通常，应用程序将以一种模式运行，以便仅报告致命错误或严重错误。当您需要调试它时，用户可以打开调试或跟踪输出并获取更多信息。

您所看到的那种日志记录看起来确实过多，但我不能说在不了解应用程序以及可能部署的位置的情况下确定这一点。

Answer 3

  

同样在强大的IDE和远程调试的这些日子里，很多日志记录真的很麻烦吗？

是的，绝对，尽管许多不熟练的开发人员犯的错误是尝试使用错误的方法修复错误，通常倾向于在应该调试时进行日志记录。每个地方都有一个地方，但至少有一些地方几乎总是需要伐木：

• 为了检查实时代码中的问题，与调试器暂停会影响计算结果（授权，日志记录会对像这样的实时进程的时序产生轻微影响，但多大程度上取决于软件）< / LI>
• 发送给可能无法访问调试器的beta测试人员或其他同事的构建
• 用于将数据转储到磁盘，这可能不容易在调试器中查看。例如，某些IDE无法正确解析STL结构。
• 了解程序正常流程的“感觉”
• 除了评论之外，为了使代码更多可读，例如：

// Now open the data file
fp = fopen("data.bin", "rb");

以上评论可以很容易地放在日志记录中：

const char *kDataFile = "data.bin";
log("Now opening the data file %s", kDataFile);
fp = fopen(kDataFile, "rb");

那就是说，你在某些方面是正确的。使用日志记录机制作为一个美化的堆栈跟踪记录器将生成质量非常差的日志文件，因为它没有为开发人员提供足够有用的故障点来检查。所以这里的关键显然是正确和谨慎地使用日志记录调用，我认为这可归结为开发人员的自由裁量权。您需要考虑自己基本上为自己制作日志文件;您的用户并不关心他们，并且通常会严重误解他们的内容，但您可以使用它们来至少确定您的程序行为不端的原因。

此外，日志文件很少会指向某个错误的直接来源。根据我的经验，它通常会提供一些有关如何复制错误的信息，然后通过复制或调试它的过程，找出问题的原因。

Answer 4

实际上有一个很好的库可以在你说PostSharp之后添加日志。它允许您通过基于属性的编程，以及除了记录之外的许多其他非常有用的东西来实现它。

我同意你所说的对于伐木有点过分。

其他一些人提出了一些好处，尤其是银行业务场景和其他关键任务应用。可能需要进行极端记录，或者至少能够在需要时打开和关闭它，或者设置不同的级别。

Answer 5

没有必要进行大量记录。 （生产中）没有理由知道每种方法何时开始和结束。也许你需要在某些方法上使用它，但在日志文件中有那么多噪音使它们几乎不可能有效地分析。

您应该记录重要事件发生的时间，例如错误，用户登录（审核日志），已启动的事务，更新的重要数据......等等。如果您遇到无法从日志中找到的问题，那么您可以在必要时添加更多内容......但仅在必要时才会添加。

另外，仅为了您的信息，在编译时添加登录将是所谓的Aspect Oriented Programming的示例。记录将是“交叉问题”。

Answer 6

我认为“记录到代码比率”是对问题的误解。

在我的工作中，我偶尔会遇到这样的情况，即Java程序中的错误无法在生产环境之外再现，并且客户不希望它再次发生。

然后，您可以使用所有修复错误的信息，这是您自己在日志文件中添加的信息。没有调试会话（无论如何都禁止在生产环境中使用） - 没有在输入数据上戳 - 什么都没有！

所以日志是你的时间机器回到错误发生的时候，因为你无法提前预测你需要修复一个尚未知的错误的信息 - 否则你可以在第一时间修复错误 - 你需要记录很多东西...

究竟什么东西取决于场景，但基本上足以确保你永远不会怀疑发生在哪里：）

当然，这意味着会发生大量的日志记录。然后，您将创建两个日志 - 一个包含所有内容，只保留足够长的时间以确保您不需要它，另一个具有可以保存更长时间的非平凡信息。

将日志记录视为过多，通常由那些没有必要修复错误的人来完成：）

Answer 7

当您在应用程序的测试版发布过程中遇到错误而无法重现时，您知道应该进行过多的日志记录。同样地，如果客户报告错误但您无法重现错误，则过多的日志记录功能可以节省时间。

Answer 8

如果你有一个客户场景（即，那些你的机器没有物理访问权限的人），那些“太多日志记录”的东西就是重新绘制函数和几乎所有它们调用的东西（几乎没有任何东西） ）。或者在操作期间每秒被调用100次的其他函数（程序启动是可以的，因为根据我的经验，这可以记录获取/设置例程的100次调用，这是大多数问题的起源）。

否则，当你错过一些能明确告诉你用户机器上的问题的关键日志点时，你就会自己踢。

（注意：这里我指的是为面向开发人员的日志启用跟踪模式时发生的日志记录，而不是面向用户的正常操作日志。）

Answer 9

我个人认为，首先没有硬性规定。我有一些应用程序可以记录很多，进出方法，以及通过中间更新状态。这些应用程序虽然是预定的进程，但仍然可以通过另一个存储成功/失败的应用程序解析日志。

我发现在所有现实中，许多用户应用程序不需要大量的日志记录，因为如果出现问题，您将进行调试以跟踪那里的值。此外，您通常不需要记录日志费用。

但是，这实际上取决于项目。

Answer 10

默认情况下，有多少行正在记录？我在一个系统上工作的非常像你所描述的那样 - 只是启动它会导致超过20MB的日志被写入如果日志记录被提升，但即使是调试我们也没有把它全部转向所有模块。默认情况下，它会在输入代码模块和主要系统事件时记录。它非常适合调试，因为QA可以将日志附加到票证，即使它不可重现，您也可以看到问题发生时的情况。如果您正在进行严格的多线程处理，那么日志记录仍然比我使用过的任何IDE或调试器都要好。

Answer 11

在我的工作中，我编写了很多Windows服务。对我来说，伐木不是奢侈品;它实际上是我唯一的UI。当我们部署到生产环境时，我们将无法访问调试，甚至无法访问我们的服务所写的数据库，如果没有记录，我们将无法知道出现的任何问题的具体细节。

话虽如此，我确实认为简洁的记录方式是最好的方法。日志消息往往局限于应用程序的业务逻辑，例如“从帐户xxx接收的消息”而不是“输入的函数yyy”。我们记录异常，线程启动，环境设置和时间的回显。除此之外，我们期待调试器识别开发和QA阶段中的逻辑错误。

Answer 12

我发现自从我开始使用TDD以来，日志记录就不那么必要了。它可以更容易地确定错误所在的位置。但是，我发现日志记录语句可以帮助理解代码中发生的事情。当然，调试器可以帮助您了解正在发生的事情。但是，如果我希望能够获得对正在发生的事情的高级视图，我可以更容易地将输出行匹配到一行代码中。

但是，我应该添加的一件事是：确保您的日志语句包含日志语句所在的模块！我无法计算我必须返回的次数，并找到日志声明的实际位置。

Answer 13

我必须承认，在开始编程时，我或多或少记录了“Dillie-O”所描述的所有细节。

相信我......在生产部署的最初几天，我们非常依赖日志文件来解决数百个问题。

一旦系统稳定，我慢慢开始删除日志条目，因为它们的值增加开始减少。 （在那个时间点没有Log4j。）

我认为，代码到日志条目的比例取决于项目和环境，并且不需要是一个恒定的比率。

如今我们在使用Log4j等软件包进行日志记录，动态启用日志级别等方面具有很大的灵活性。

但是如果程序员没有正确使用它，比如什么时候使用，什么时候不使用INFO，DEBUG，ERROR等以及日志消息中的细节（我看过日志消息，比如“Hello X，您好XX，Hello XXX等“只有程序员可以理解的”这个比率将继续保持较高且ROI更少。

Answer 14

我认为另一个因素是正在使用的工具集/平台及其附带的约定。例如，在J（2）EE世界中，日志记录似乎非常普遍，而我记不起在Ruby on Rails应用程序中编写日志语句。