我正在开始一个新项目，并在思考我应该记录什么。日志文件仅用于帮助开发人员发现错误。用例是当抛出未处理的异常时，会向开发人员发送通知，该开发人员可以访问日志文件和堆栈跟踪。
我应该在日志文件中包含哪些内容？记录一切都不会起作用。 我知道这很难说，因为答案可能需要对系统有深入的了解。所以我想我真的要求“最佳实践”。请举例说明。
是否还取决于桌面客户端应用程序，桌面服务器或网络服务器等应用程序类型？
答案 0 :(得分：7)
第一条规则是“不记录敏感信息！”。例如：社会安全号码，信用卡号码，密码等......您不知道谁可以获得查看权限，这可能会给您带来一些法律问题。
记录与第三方组件的通信（例如Web服务等）非常有用。如果出现问题，您将能够向第三方供应商或您提供有用的信息。
非常简单地跟踪用户所做的操作...转到特定页面......做某些事情是很有用的。因此，如果客户通过电话给您打电话并说您的产品有问题 - 您可以查看他现在正在做什么。
在我们公司，通常的做法是跟踪数据库查询需要完成多少。这是在某个时候识别瓶颈或识别系统（应用程序服务器或数据库服务器）的某些问题的方法。
您还可以跟踪一些破坏系统DOS攻击，暴力机器人等的尝试......等等。
希望有所帮助！
答案 1 :(得分：3)
我有两个独立的环境，其中日志记录要求完全不同。
在这里，我们记录异常，常见的事情，如登录，应用程序启动等，以及对象的编辑/删除/插入。足以检查事情发展时会发生什么。我们记录足够能够重现案件。在我们的案例中，允许日志无限增长，因此我们可以检查问题。
在这里，我们记录几乎所有东西和厨房水槽。这是需要全天候运行的软件，所以即使是一个简单的警告也可能是一场灾难。一个例子是我们有一些奇怪的超时，并没有考虑一些时间约束要求。最后，日志文件给了我们信息：保存几个100字节的文本文件有时需要超过5秒。通常问题出现在你根本没想到的事情上，所以你应该做的就是记录，记录，记录！几天后日志会自动清理。
我们还做的是实现最终用户可以设置的loglevel：如果设置为verbose，我们保存所有日志记录，如果设置为minimal，则只有错误发生。经过几周的稳定运行后，我们慢慢将对数水平降低到最小值，并停止我们是否合适。
所以我会说：这取决于你的申请。
答案 2 :(得分：2)
一般
关于敏感或详细的信息，正如其他人已经说过的那样，你必须要小心。这不仅仅是关于有权阅读生产日志的人获取的信息超过必要的信息，还要考虑系统的任何入侵者都可以获得过于冗长日志的有价值信息的情况（这就是为什么我不会记录集合的原因）用户权限与他没有特定的错误，是在另一个答案中建议的。
可能取决于您的环境或客户的敏感程度，但示例如下： - 错误消息中的实际用户输入。 - 用户权限集等 - SQL语句，尤其是实际参数 - XML请求/响应结构
找到要记录的信息的正确粒度总是在记录的信息量，不仅要编写的成本以及在代码中产生此信息以及该信息的敏感性所花费的性能之间进行权衡。这就是为什么任何严肃的测井系统都会运行“水平”或“类别”的原因。
您可以在“级别”或“类别”中记录潜在的敏感信息，这些信息可以在开发中打开但在生产中关闭。如果你真的想要过分，你可以在你的应用程序检测到这样的日志记录被启用时编写一个EventLog条目，因此它不会在生产中“滑倒”。
最后，考虑使用允许在运行时更改这些级别或类别的日志框架。这样，您可以在需要时以受控方式启用更多信息，而不会中断应用程序的工作或重置您想要检查的情况，因为首先需要重新启动应用程序。
答案 3 :(得分：1)
查看nLog之类的文档。它会给你一些关于你应该记录什么以及如何控制它的想法。
答案 4 :(得分：1)
记录引发异常的方法的名称及其使用的任何参数（即状态）。记录用户的ID和权限。在Web方案中，记录IP地址和标头。
答案 5 :(得分：1)
日志记录使代码更长，更不清晰。所以要懒惰，在你需要之前不要记录任何东西。
将未处理的异常电子邮件直接发送给开发人员并且根本不记录任何内容可能是个好主意。
答案 6 :(得分：0)
当涉及“生活中的所有地狱破裂”的情况时，伐木是你的救星。正如你所说，它确实需要更多的应用程序知识，但你应该考虑几件事情。