代码与日志记录比率？

Question

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

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

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

在编译时使用反射添加日志语句的插件是不是更容易,所以当你试图查看代码时它们不会妨碍它？

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

Answer 1

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

调查级别

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

信息水平

• 方法的开始和结束
• 任何主要循环的开始和结束
• 任何主要case/switch语句的开头

错误级别

• 处理异常
• 登录尝试无效(如果安全性有问题)
• 我截获报告的错误数据

致命等级

• 未处理的例外情况.

此外,还有大量的日志记录详细信息阻止我在收到错误消息时询问用户他们正在做什么.我可以轻松地将它拼凑在一起.

Answer 2

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

您所看到的那种日志记录似乎确实过多,但我不能说在不了解应用程序以及可能部署的位置的情况下确定这种情况.

Answer 3

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

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

• 为了检查实时代码中的问题,与调试器暂停将影响计算结果(授予,记录将对这样的实时过程中的时序产生轻微影响,但多大程度上取决于软件)
• 对于发送给可能无法访问调试器的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

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

您应该记录重要事件发生的时间,例如错误,用户登录(审计日志),已启动的事务,更新的重要数据......等等.如果您遇到无法从日志中弄清楚的问题,那么您可以在必要时添加更多内容......但仅在必要时添加.

此外,仅为了您的信息,在编译时添加登录将是所谓的面向方面编程的示例.测井将成为"交叉问题".

Answer 6

我认为"记录到代码比率"是对问题的误解.

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

然后,您可以使用所有修复错误的信息,这是您自己在日志文件中添加的信息.没有调试会话(无论如何在生产环境中都是禁止的) - 没有对输入数据进行调查 - 什么都没有!

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

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

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

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