因此，我们在我的工作地点讨论了登录通行证，我想知道这里的某些人是否可以给我一些有关方法的想法？

通常，我们的方案是，根本没有日志记录，主要是.NET应用程序，Winforms / WPF客户端通过Web服务进行对话或者直接发送到db。

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

我们是否将其用于调用Web服务或者数据库？页面加载？

我们如何了解用户当时想做什么？

一路走好，跨多次尝试/天记录所有内容，还是只记录我们需要的内容(考虑到硬盘便宜)，这是更好的选择吗？

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

解决方案

回答

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

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

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

编辑：我还将设置一个系统，以定期(也许每晚)轮转，压缩和存档日志文件。

回答

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

我假设邮件是有条理的。我们使用4个类别；错误，警告，信息和跟踪。我们仍在弄清楚什么级别。当我习惯于解析日志文件时，我通常会说"更多日志"。请保持可读性，我们可能需要稍微处理一下日志文件，然后才能使用它。

最后，找到一个良好的日志记录框架，该框架可让我们控制生命周期和存储空间上的假脱机使用情况，以及一个适当的api，以最大程度地减少对代码的影响。理想情况下，我们只需键入info(" waaah")或者warning(" waah")，API就会为我们完成所有精美的标记。

回答

记录的关键是良好的计划。我建议我们调查企业库异常和日志记录应用程序块(http://msdn.microsoft.com/zh-cn/library/cc467894.aspx)。学习曲线有些微不足道，但效果确实很好。我目前支持的方法是定义4个优先级。 4 =未处理的异常(事件日志中的错误)，3 =处理的异常(事件日志中的警告)，2 =访问外部资源，例如Web服务，数据库或者大型机系统(事件日志中的信息)，1 =详细信息/其他感兴趣(事件日志中的信息)。

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

更新：为了清楚起见，我建议我们同时登录winform / wpf应用程序和Web服务。在Web场景中，过去遇到过很多问题，可能很难将客户端上的错误重新绑定到应用程序服务器。主要是因为通过Web服务进行的任何错误都被包装为SOAP异常。我想不起来，但我想如果我们使用自定义异常处理程序(这是企业库的一部分)，则可以将数据添加到异常中，例如来自应用服务器的异常的handlinginstance id。使用LogParser，可以更轻松地将客户端上的异常绑定回应用程序框(http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en) 。

第二次更新：我也想给每个不同的事件一个单独的事件ID，并在源代码控制下在文本文件或者电子表格中对其进行跟踪。是的，这很痛苦，但是如果我们足够幸运地有一个IT团队来照顾生产系统，我发现他们倾向于期望不同的事件具有不同的事件ID。

回答

Is it better to go all the way and log everything across multiple attempts/days, or log only what you need to (given hdd is cheap).

事实上，硬盘驱动器很便宜，并不是出于所有原因而冗长地记录所有可能的记录的好理由。.其中之一，对于一个非常繁忙的应用程序，我们真的不想放慢它的速度并束缚光盘写入。日志(硬盘驱动器非常慢)。第二点，更重要的一点是，价值TB级的日志几乎没有什么好处。.对于开发来说，它们很有用，但我们不必保留几分钟。

某些日志记录当然有用，具有不同级别是唯一的解决方法，例如debug()info()仅在被请求(在配置或者命令行标志中)时才被记录，然后是warning()和错误()被发送到日志文件

对于我编写的大多数内容(较小的脚本)，我通常只有一个debug()函数，该函数检查是否设置了--verbose并打印消息。这样，我就可以推除debug(" some value：％ s"％(avar))，而不必担心返回并在任何地方删除调试print()语句。

对于Web应用程序，我通常只使用Web服务器日志进行统计，并使用错误日志。我在需要时使用诸如mod_rewrite的日志之类的东西，但是将其保留为开发之外是愚蠢的(因为它在每个页面请求上创建许多行)

我想这取决于应用程序本身，但是通常，对于大型应用程序，使用多个级别的日志，这些日志可以在需要时激活。对于较小的东西，对于Web应用程序，则使用--verbose标志或者等效标志，以记录日志错误和(有时)日志命中。

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

回答

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

回答

作为管理员，我非常感谢能够将所有日志(但跟踪日志)记录到事件日志(最好是自己的日志，否则是应用程序日志)的应用程序。通过记录到事件日志，我们更有可能在管理员成为主要问题(如果他们可以解决的问题)之前，让管理员发现并解决警告或者错误，或者允许他们进行联系与开发人员一起使用，他们可以使用跟踪日志来进一步解决问题。

现在支持自定义.NET应用程序的最大痛苦是，同一供应商提供了8种不同的应用程序(某些控制台应用程序，某些winforms和某些Web)。它们都没有记录到事件日志，它们都有自己的自定义日志文件。但是对于所有winforms和控制台应用程序，它们在运行时都保持文件打开状态，因此我无法对其进行监视。另外，日志的编写方式也略有不同，因此我必须对日志进行一些不同的解析才能获得有用的信息。

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

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

回答

谢谢大家，提供了很多很好的信息，但马丁给了我更多有关如何进行的详细信息。我会给他答案，因为现在看来我们不在最前面的几页中，答案也会消失。