相关疑难解决方法(0)

我想了解人们如何处理跟踪和登录实际应用程序的故事.以下是一些可能有助于解释您的答案的问题.

构架

你使用什么框架？

• log4net的
• System.Diagnostics.Trace
• System.Diagnostics.TraceSource
• 记录应用程序块
• 其他？

如果使用跟踪,是否使用Trace.Correlation.StartLogicalOperation？

您是手动编写此代码,还是使用某种形式的面向方面编程来执行此操作？小心共享代码片段？

您是否在跟踪源上提供任何形式的粒度？例如,WPF TraceSources允许您在不同级别配置它们:

• System.Windows - 所有WPF的设置
• System.Windows.Animation - 专门为动画覆盖.

听众

你使用什么日志输出？

• 文本文件
• XML文件
• 事件簿
• 其他？

如果使用文件,您使用滚动日志还是仅使用单个文件？如何使日志可供人们使用？

查看

您可以使用哪些工具查看日志？

• 记事本
• 尾巴
• 事件查看器
• Systems Center Operations Manager/Microsoft Operations Manger
• WCF服务跟踪查看器
• 其他？

如果要构建ASP.NET解决方案,是否还使用ASP.NET运行状况监视？您是否在运行状况监视器事件中包含跟踪输出？那么Trace.axd呢？

自定义性能计数器怎么样？

根据NLog的文档:

大多数应用程序将为每个类使用一个记录器,其中记录器的名称与类的名称相同.

这与log4net的运行方式相同.为什么这是一个好习惯？

有许多不同的日志库可供选择,每个都有自己的一套怪癖和优点.(.Net示例:log4net,System.Diagnostics.TraceSource,nLog等)

自然的倾向是抽象出那些怪癖并使用伐木立面.(示例:Castle.Services.Logging,Common.Logging,Simple Logging Facade)这样,如果您使用的给定日志框架变得陈旧,或者另一个日常框架变得流行,您可以换掉实现并离开代码没有动过.

但是有多个伐木外墙可供选择.鉴于许多不同的日志记录实现的答案是抽象,为什么不使用日志门面？如果这听起来很荒谬,是什么让它比原始的伐木门面更荒谬？是什么让一个额外的抽象层在日志框架之上成为神奇的数字？