记录与调试

Question

背景：我继承了一个Web应用程序，旨在创建本地和远程设备之间的即时连接。最近有大量的移动部件：应用程序本身发生了重大变化;开发工具链刚刚更新;本地和远程设备都经过“修改”以支持这些变化。

好的一面是它有一个合理的日志记录系统，可以将调试消息写入文件，它将同时记录到文件和实时用户屏幕。我有机会重新使用整个日志/调试机制。

示例：

• 所有邮件都带有时间戳，并以严重性级别为前缀。
• 日志适用于客户。他们记录了系统对他/她的请求的回复。
• 任何标识问题的日志也都会提出解决方案。
• 调试适用于开发人员和技术支持。他们揭示了系统内部。
• 调试指示生成它们的函数和/或行。
• 客户可以动态调整调试级别以设置详细程度。

问题：您作为开发人员或被视为消费者的哪些最佳做法可以生成有用的日志和调试？

---

编辑：到目前为止，有很多有用的建议，谢谢！澄清：我对要记录的内容更感兴趣：内容，格式，等 .--以及这样做的原因 - 而不是具体的工具。

你见过的最好的日志是什么让他们最有帮助？

感谢您的帮助！

Answer 1

有些人从不使用调试器但会记录所有内容。这是不同的哲学，你必须做出自己的选择。您可以找到许多建议like these或this one。请注意，这些建议与语言无关......

Coding Horror guy得到an interesting post关于日志记录问题以及为什么滥用日志记录在某些条件下浪费时间。

我只是认为日志记录用于跟踪可能保留在生产中的内容。调试用于开发。也许这是一种看待事物的过于简单的方式，导致一些人使用日志进行调试，因为他们无法忍受调试器。但调试器模式也可能浪费时间：你不必像某种测试用例那样使用它，因为它没有被写下来并且会在调试会话后消失。

所以我认为我对此的看法是：

• 使用日志框架（ log4 系列工具）在开发和生产环境中通过开发和生产环境记录必要且有用的跟踪
• 调试模式，用于处理失控的特殊奇怪情况
• 测试用例很重要，可以节省在地狱迷宫调试会话中花费的时间，用作反向回归方法。请注意，大多数人不使用测试用例。

编码恐怖说抵制记录所有内容的倾向。这是对的，但我已经看到一个hudge应用程序以一种漂亮的方式（通过数据库）完全相反......

Answer 2

使用任何日志框架完成的absolutley最有价值的事情是“一键式”工具，即使应用程序部署在属于客户的计算机上，也会收集所有日志并将其邮寄给我。

并在记录内容方面做出正确的选择，这样您就可以大致按照应用程序中的主要路径进行操作。

作为框架，我使用了标准（log4net，log4java，log4c ++）

当已经有一个好的开箱即用时，不要实现自己的日志框架。大多数人只是重新发明轮子。

Answer 3

不要混淆日志记录，跟踪和错误报告，我知道的一些人会创建一个日志文件，以便获取我想要的信息。

如果我想把所有东西都弄清楚，我会分成以下内容：

  

  
• 追踪 - ＆gt;使用输入和转储每个操作和步骤，加时间戳   该阶段的输出数据（ugliest和   最大的文件）
  
• 记录 - ＆gt;仅记录业务流程步骤，客户端进行查询以便记录   查询标准和输出数据   仅此而已。
  
• 错误报告/调试 - ＆gt;记录的异常详细说明了它的位置   发生，加时间戳，输入/输出   数据，如果可能，用户信息等
  

这样一来，如果发生任何错误并且错误/调试日志没有包含我喜欢的足够信息，我总是可以grep -A 50 -B 50 'timestamp' tracing_file来获取更多细节。

修改 正如前面所说，坚持使用像python的内置日志记录模块这样的标准软件包总是很好。除非语言中没有标准库，否则滚动自己并不是一个好主意。我喜欢在一个小函数中包装日志记录，通常采用消息和值来确定它进入哪个日志，即。 1 - 跟踪，2 - 记录，4 - 调试，因此向所有3等发送7个值的值。

Answer 4

我只是将您的日志系统设置为具有多个日志记录级别，对于我编写的服务，我几乎每个操作都有一个日志/审计，并且它被分配了审计级别1-5，数字越大，您获得的审计事件越多。

1. 最基本的日志记录：启动，停止和重新启动
2. 基本日志记录：处理x个文件等
3. 标准记录：开始处理，完成处理等
4. 高级日志记录：处理中每个阶段的开始和结束
5. 一切：采取的每一项行动

您可以在配置文件中设置审核级别，以便可以即时更改。

Answer 5

我发现一些一般的经验法则在服务器端应用程序中很有用：

• requestID - 为每个传入（HTTP）请求分配一个请求ID，然后在每个日志行上记录该请求ID，以便您稍后可以通过该ID轻松地查找这些日志并查找所有相关行。如果您认为将该ID添加到每个日志语句非常繁琐，那么至少java日志框架使用Mapped Diagnostic Context（MDC）使其透明。
• objectID - 如果您的应用程序/服务处理操作某些具有主键的业务对象，则将该主键附加到诊断上下文也很有用。之后，如果有人提出问题“这个对象何时被操纵？”您可以通过objectID轻松地grep并查看与该对象相关的所有日志记录。在这种情况下，实际使用Nested Diagnostic Context代替MDC是有用的。
• 何时登录？ - 每当您跨越重要的服务/组件边界时，至少应该记录。这样，您可以稍后重建调用流并深入查看似乎导致错误的特定代码库。

由于我是Java开发人员，我还将提供Java API和框架的经验。

<强> API

我建议使用Simple Logging Facade for Java（SLF4J） - 根据我的经验，它是记录的最佳门面：

• 功能齐全：它没有遵循最小公分母方法（如公共日志记录）;相反，它正在使用降级优雅方法。
• 具有适用于几乎所有流行的Java日志框架（例如log4j）的适配器
• 提供了有关如何将所有旧式日志记录API（log4j，commons-logging）重定向到SLF4J的解决方案

<强>实施 与SLF4J一起使用的最佳实现是logback - 由同一个创建SLF4J API的人编写。

Answer 6

使用现有的日志记录格式，例如Apache使用的格式，然后您可以搭载许多可用于分析格式的工具。