日志记录的关键是做好计划。我建议您查看企业库异常和日志记录应用程序块（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-95b1b2-f8d975cf8c07&；displaylang=en）。

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

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

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

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

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

这篇关于highscalability.com的文章为在大规模分布式系统中进行日志记录提供了一个很好的视角。（巧合的是，它一开始提到了JoelOnSoftware上的一篇文章）。

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

硬盘驱动器很便宜，这并不是一个冗长地记录所有可能的事情的好理由，原因有几个。。首先，对于一个非常繁忙的应用程序，你真的不想让它慢下来，也不想占用写日志的光盘（硬盘驱动器很慢）。第二点，也是更重要的一点——从价值TB的日志中获益甚微。。对于开发来说，它们可能很有用，但您不需要保留超过几分钟的时间。。

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

对于我写的大多数东西（小脚本），我通常只有一个debug（）函数，它检查是否设置了--verbose，并打印消息。。这样，我就可以在需要时推送调试（“some value:%s”%（avar）），而不必担心返回并删除调试print（）语句。

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

我想这取决于应用程序本身，但通常情况下，对于大型应用程序，使用多个级别的日志，这些日志可以在需要时激活。对于较小的东西，一个--verbose标志或等效标志，对于web应用程序，记录错误和（在一定程度上）日志命中。

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

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

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

最后，找到一个好的日志记录框架，允许您控制spool在使用寿命和存储空间上的使用，以及一个适当的api，最大限度地减少对代码的影响。理想情况下，您只需键入info（“waaah”）或warning（“waah”），API就会为您做所有花哨的标记。

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

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

我也会向开发者宣传每个级别的意义。

编辑：我还会建立一个系统，定期轮换、压缩和归档日志文件，可能是晚上。

谢谢大家，有很多好消息，但Martin给了我更多关于如何继续的细节。我会给他答案，因为现在我们似乎已经离开了头版，答案会下降。