什么样的日志记录对您的应用程序来说是好的日志记录？

Question

因此，我们已经讨论了在我的工作地点登录传递的问题，我想知道这里的一些人是否可以给我一些关于你们的方法的想法？

通常我们的场景是，根本没有日志记录，并且大多数是 .NET 应用程序、winforms/WPF 客户端通过 Web 服务进行通信或直接与数据库进行通信。

所以，真正的问题是，您将在哪里记录或记录什么？目前我们有用户报告错误消息 - 所以我假设日志启动/关闭、异常......

你用它来调用网络服务或数据库吗？页面加载？

您如何很好地了解用户当时想要做什么？

是最好一路记录多次尝试/几天的所有内容，还是只记录您需要的内容（考虑到硬盘很便宜）。

我想这是几个问题，但我想更多地了解大型商店的实际做法是什么！

Answer 1

日志记录的关键是良好的规划。我建议您查看企业库异常和日志记录应用程序块（http://msdn.microsoft.com/en-us/library/cc467894.aspx）。虽然有一点学习曲线，但效果很好。我目前赞成的方法是定义 4 个优先级。4=未处理的异常（事件日志中的错误），3=已处理的异常（事件日志中的警告），2=访问外部资源，例如 Web 服务、数据库或大型机系统（事件日志中的信息），1=详细/其他任何内容感兴趣的（事件日志中的信息）。

使用应用程序块可以很容易地调整您想要记录的优先级。因此，在开发中，您会记录所有内容，但是当您在生产中获得稳定的系统时，您可能只对未处理的异常和可能已处理的异常感兴趣。

更新: ：为了清楚起见，我建议您登录 winform/wpf 应用程序和网络服务。在 Web 场景中，我过去遇到过一些问题，很难将客户端上的错误连接回应用程序服务器。主要是因为通过 Web 服务的任何错误都会被包装为 SOAP 异常。我记不清了，但我认为如果您使用自定义异常处理程序（这是企业库的一部分），您可以将数据添加到异常中，例如来自应用程序服务器的异常的处理实例 ID。这使得使用 LogParser (http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en).

第二次更新: ：我还喜欢为每个不同的事件提供单独的事件 ID，并在源代码管理下的文本文件或电子表格中跟踪该事件。是的，这很痛苦，但如果您足够幸运，有一个 IT 团队在生产中照顾您的系统，我发现他们倾向于期望不同的事件具有不同的事件 ID。

Answer 2

作为一名管理员，我真的很欣赏那些记录到事件日志（最好是他们自己的，否则应用程序日志）的应用程序，以记录除跟踪日志之外的所有日志记录。通过记录到事件日志，您可以使管理人员更有可能在警告或错误成为主要问题之前发现并解决它们（如果这是他们可以解决的问题），或者允许他们联系与开发人员一起，他们可以使用跟踪日志来进一步解决问题。

我现在支持自定义 .NET 应用程序的最大痛点是同一供应商有 8 个不同的应用程序（一些控制台应用程序、一些 winform 和一些 Web）。它们都不记录到事件日志，它们都有自己的自定义日志文件。但对于所有 winforms 和控制台应用程序，它们在运行时保持文件打开，因此我无法监视它是否存在问题。此外，日志的编写方式都略有不同，因此我必须以不同的方式解析它们才能获取有用的信息。

这迫使我监视应用程序的外观（它是否在其活动的端口上响应，进程工作集是否变得太高，等等），而不是应用程序的实际状态。

请考虑在部署后维护您的应用程序并提供他们可以使用的日志记录的人员。谢谢！

Answer 3

这篇文章发表在 highscalability.com 上 为大规模分布式系统中的日志记录提供了良好的视角。（巧合的是，它首先提到了 JoelOnSoftware 上的一篇文章）。

Answer 4

是最好一路记录多次尝试/几天的所有内容，还是只记录您需要的内容（考虑到硬盘很便宜）。

硬盘驱动器很便宜这一事实确实不是详细记录所有可能的内容的好理由，原因有几个。其一，对于非常繁忙的应用程序，您确实不想放慢速度并占用光盘写入写入日志（硬盘驱动器非常慢）。第二点，也是更重要的一点 - 从 TB 级的日志中获得的收益实际上微乎其微。对于开发来说，它们可能很有用，但您不需要保留它们超过几分钟。

一些日志记录当然是有用的，具有不同的级别是唯一的方法 - 例如 debug() info() 仅在请求时才会记录（在配置或命令行标志中），然后可能是 warning() 和error() 被发送到日志文件

对于我编写的大多数内容（小脚本），我通常只有一个 debug() 函数，它检查 --verbose 是否设置，并打印消息。这样我就可以推送 debug("一些值：%s" % (avar)) 在需要时，不必担心返回并删除任何地方的调试 print() 语句。

对于 Web 应用程序，我通常只使用 Web 服务器日志进行统计，以及错误日志。我在需要时使用 mod_rewrite 的日志之类的东西，但是在开发之外启用此功能将是愚蠢的（因为它在每个页面请求上创建许多行）

我想这取决于应用程序本身，但通常，对于大型应用程序来说，使用可以在需要时激活的多个级别的日志。对于较小的事情，对于 Web 应用程序、日志错误和（在某种程度上）日志命中，可以使用 --verbose 标志或等效标志。

基本上，在“生产”日志中仅记录您可以使用的信息，在开发日志中记录您可能需要解决问题的所有信息。

Answer 5

对于典型的桌面应用程序，我会存储当前会话中的所有内容，并且可能存储过去 n 个会话或最多 x 大小的信息消息。

我假设您的消息是有组织的。我们使用 4 个类别；错误、警告、信息和跟踪。我们仍在弄清楚什么会发生在哪个级别。当我习惯解析日志文件时，我通常会说“记录更多”。不要担心可读性，您可能需要先处理一下日志文件，然后才能使用它。

最后，找到一个好的日志记录框架，允许您控制 spool 使用的生命周期和存储空间，以及一个适当的 api，最大限度地减少对代码的影响。理想情况下你只需输入 info("waaah") 或者 warning("waah") API 会为您完成所有精美的标记。

Answer 6

作为一个快速回答，我会说提出一系列类别并具有可切换的日志记录级别，例如信息、警告、错误、严重等。

然后可以轻松设置日志记录级别以调整您需要的详细程度。通常，在配置文件中设置日志记录级别并停止并重新启动应用程序。

我还会向开发人员宣传每个级别的含义。

编辑：我还会建立一个系统来定期（也许每晚）轮换、压缩和归档日志文件。

Answer 7

谢谢大家，很多好信息，但马丁给了我更多关于如何继续的细节。我会给他答案，因为看起来现在我们已经离开了前面几页的答案将会消失。