所以我们已经讨论过在我的工作地点登录，我想知道你们中的一些人是否可以给我一些关于你的方法的想法？
通常我们的场景是，根本没有日志记录，主要是 .NET 应用程序、winforms/WPF 客户端通过 Web 服务或直接连接到数据库。
所以，真正的问题是，你会在哪里或什么地方记录？目前我们有用户报告错误消息 - 所以我假设日志启动/关闭，异常......
您是否将其用于调用 Web 服务或数据库？页面加载？
您如何很好地了解用户当时试图做什么？
是一路走好并记录多次尝试/天的所有内容，还是只记录您需要的内容（假设硬盘很便宜）。
我想这是几个问题，但我想更多地了解大型商店的实际做法！
日志记录的关键是良好的计划。我建议您查看企业库异常和日志记录应用程序块 ( 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。
作为一名管理员，我真的很欣赏那些记录到事件日志（最好是他们自己的，否则是应用程序日志）的应用程序，以记录除跟踪日志之外的所有日志。通过记录到事件日志，您更有可能在警告或错误成为主要问题（如果这是他们可以解决的问题）之前由管理员找到并解决它们，或者允许他们取得联系与开发人员一起，他们可以使用跟踪日志来进一步解决问题。
我现在支持自定义 .NET 应用程序的最大痛点是来自同一供应商的 8 个不同的应用程序（一些控制台应用程序、一些 Winform 和一些 Web）。他们都没有记录到事件日志，他们都有自己的自定义日志文件。但是对于所有的 winforms 和控制台应用程序，它们在运行时会保持文件打开，所以我无法监控它的问题。此外，日志的编写方式都略有不同，因此我必须对它们进行一些不同的解析才能获得有用的信息。
这迫使我监视应用程序的外观（它是否响应它处于活动状态的端口，进程工作集是否变得太高等等），而不是应用程序的实际状态。
请考虑在部署后维护您的应用程序并提供他们可以使用的日志记录的人员。谢谢！
highscalability.com 上的这篇文章提供了一个很好的视角来记录大规模分布式系统。（巧合的是，它首先提到了 JoelOnSoftware 上的一篇文章）。
是一路走好并记录多次尝试/天的所有内容，还是只记录您需要的内容（假设硬盘很便宜）。
硬盘便宜的事实确实不是详细记录所有可能的好理由，原因有几个。第一，对于一个非常繁忙的应用程序，您真的不想放慢速度并占用磁盘写入写入日志（硬盘驱动器非常慢）。第二点，也是更重要的一点——从 TB 级的日志中获得的收益真的很少。对于开发来说，它们可能很有用，但你不需要保留超过几分钟的时间。
一些日志记录当然是有用的，具有不同级别是唯一的方法 - 例如 debug() info() 只有在请求时才被记录（在配置或命令行标志中），然后可能是 warning() 和error() 被发送到日志文件
对于我写的大部分东西（小脚本），我通常只有一个 debug() 函数，它检查是否设置了 --verbose 并打印消息。这样我就可以推 debug("some value: % s" % (avar)) 在需要时，不必担心返回并从任何地方删除调试 print() 语句。
对于 Web 应用程序，我通常只使用 Web 服务器日志进行统计，并使用错误日志。我在需要时使用 mod_rewrite 的日志之类的东西，但是在开发之外启用它是愚蠢的（因为它会在每个页面请求上创建很多行）
我想这取决于应用程序本身，但通常，对于大型应用程序，使用可以在需要时激活的多级日志。对于较小的事情，一个 --verbose 标志或等效的，对于 Web 应用程序，记录错误和（到一定程度）日志命中。
基本上，在“生产”日志中只有您可以使用的信息，在开发日志中您可能需要解决问题的所有信息。
作为一个快速的答案，我会说提出一系列类别并具有可切换的日志记录级别，例如信息、警告、错误、关键等。
然后轻松设置日志记录级别以调整所需的详细程度。通常，在配置文件中设置日志记录级别并停止并重新启动应用程序。
我还会向开发人员宣传每个级别的含义。
编辑：我还会建立一个系统来定期轮换、压缩和归档日志文件，也许是每晚。
对于一个典型的桌面应用程序，我会将所有内容存储在当前会话中，并且可能存储过去 n 个会话的信息消息，或者最多存储 x 个大小。
我假设您的消息是有组织的。我们使用 4 个类别；错误、警告、信息和跟踪。我们仍在弄清楚在哪个级别上会发生什么。当我习惯于解析日志文件时，我通常会说“记录更多”。不要担心可读性，您可能需要先处理一下日志文件才能使用它。
最后，找到一个好的日志框架，让你可以控制你的假脱机在生命周期和存储空间上的使用，以及一个合适的 api 来最大限度地减少对你的代码的影响。理想情况下，您只需键入info("waaah")或warning("waah")，API 会为您完成所有花哨的标记。
谢谢大家，很多很好的信息，但马丁给了我更多关于如何继续的细节。我会给他答案，因为现在我们似乎离开了前几页，答案会掉下来。