记录良好/经过验证的实践 - EntLib

Question

我目前正在为我们的企业应用程序进行日志记录。我们（团队）同意使用企业库。我需要做一些关于这个主题的文档，但我很新手，这很难。如果你能指出一些要点，我会需要。什么是最佳实践。到目前为止我所发现的只是具体文章如何在代码中执行，这不是我想要的，我需要谈论什么日志，如何记录什么等等。 它是用.Net编写的MVC应用程序

Answer 1

我有关于仪器的一般理论。它以“思想实验”开始。想象一下，应用程序中根本没有任何工具，它可以部署到Production中。究竟会发生什么让我们希望我们已经为应用程序提供了工具？

我的回答是，一般来说，应用程序会知道一组我们希望它会告诉我们的事情。这就是我们应该采取的一系列措施。

1. 我们可能想知道特定事件发生的频率（例如，因为会话已过期，用户被注销的次数）。
2. 可能我们想知道任何未处理的异常（几乎可以免费使用ASP.NET Health Monitoring，但仍然如此）。
3. 可能我们希望我们知道来自某些代码的调用网站的五条信息只是引发了异常。

第一个案例建议我们添加一个性能计数器。第二个建议我们开启健康监测。第三个建议我们在异常时记录一些额外的信息（然后使用throw;让异常传播）。

在我看来，没有一个案例表明花时间记录每个函数入口和出口以及所有参数是个好主意，也不应该记住每个异常并在重新抛出它之前记录它（或忽略它）。 / p>

这些事情等于让程序给我们“太多信息”。

Answer 2

考虑您的受众群体。在这些场景中弹出记录

用于错误记录。观众是维护开发人员，他真的想知道真正的错误和相关的代码部分。

用于调试/跟踪。与错误记录类似，但即使没有出错也会写入。在错误发生之前，很难说哪些跟踪最有价值，因此您在怀疑有错误的区域或在事后的区域中记录很多，您可能想知道哪些方法运行。 EntLib针对此类日志记录进行了优化。对于我在这里列出的其他日志记录目标，EntLib并不是最好的。

进行性能调优，在这种情况下，您确实希望记录到临时或只是捕获性能低下的事件。

为安全起见，您正在尝试检测“不良行为”事件。受众可能是人力资源部门或执法部门。

用于商业驱动的东西。在这种情况下，观众是客户。

Answer 3

以下是有关登录生产系统的一些最佳做法：

• 仅记录有用或高于特定日志记录级别的内容。不要将日志记录级别设置得太低，否则会导致记录很多内容。如果记录太多，则应用程序性能将受到影响，因为日志记录涉及文件I / O.

• 同时记录线程名称和类名称，如果代码由多个线程执行，则有助于调试。

Answer 4

作为一般规则，您应该考虑您的要求（如果没有业务要求，那么技术要求）并尝试解决它们。

就记录的数量而言，我倾向于更多的仪器而不是更少（如果水平可以上下调整）。当你遇到一个没有任何意义的奇怪的生产问题时，你会感激不尽。

以下是一些注意事项：

• 能够启用不同的日志记录级别
• 能够为不同的程序集/类启用日志记录
• 能够启用不同功能区域的日志记录
• 能够记录方法条目/退出/时间
• 能够在运行时更改日志记录级别而无需更改代码
• 日志在哪里？中央存储库或各种分布式日志？
• 什么是日志记录格式（例如XML）？标准化信息还是ad-hoc？
• 您需要独特的EventID吗？
• 日志记录会触发警报/通知（例如Tivoli）吗？如果是这样，有什么要求？
• 是否有必要报告/查询日志

另外，请考虑使用策略注入/ AOP来解决交叉日志问题。

我建议不要使用优先级，除非你有充分的理由这样做（类别和严重程度应该足够灵活）。

Answer 5

在考虑您的日志记录策略时，考虑以后如何使用或处理日志条目至关重要。由于事件在记录时变得平坦，所以有价值的上下文信息往往会丢失;从而使日志对故障排除不太有用。

语义记录允许您保留离散有效负载的语义值。它还将工作放在正确的位置，使您的应用程序代码更清晰。我将在post进一步讨论这个问题。