跟踪与日志logging以及log4net如何适应?

我想知道什么是logging和跟踪之间的区别。

跟踪是不是更详细的日志,给开发人员一个工具来在运行时debugging应用程序的基本差异?

我一直在做log4net的testing。 现在我想知道是否应该跟踪,如果我可以/应该使用log4net的目的。 我应该跟踪log4net和log4netlogging器有一些跟踪级别? 我应该使用不同的日志级别进行debugging和追踪吗?还是可以使用相同的方法? 你能给我一个简单的例子,我将如何做一个简单的方法日志logging和追踪?

编辑:尽pipe下面几个有用的答案,我仍然不确定我应该如何跟踪与日志logging。

我在我的业务层有以下方法,我想添加日志/追踪到它。 我想知道如何有效地做到这一点。 在logging/追踪方面是否可接受以下方法? 日志消息应该是types信息而不是debugging? 我正在logging的debugging消息是否考虑跟踪? 你将如何改变它?

IEnumerable<Car> GetCars() { try { logger.Debug("Getting cars"); IEnumerable<Car> cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter); logger.Debug("Got total of " + cars.Count + " cars"); } catch (Exception e) { logger.Error("Error when getting cars", e); throw new Exception("Unexpected error when getting cars"); } } 

7 Solutions collect form web for “跟踪与日志logging以及log4net如何适应?”

日志logging是logging信息的通用术语 – 跟踪是用于debugging的日志logging的特定forms。

在.NET中,System.Diagnostics.Trace和System.Diagnostics.Debug对象允许简单地logging到许多可以在app.config中configuration的“事件侦听器”。 您也可以使用TraceSwitches进行configuration和过滤(例如在错误和信息级别之间)。

 private void TestMethod(string x) { if(x.Length> 10) { Trace.Write("String was " + x.Length); throw new ArgumentException("String too long"); } } 

在ASP.NET中,Trace(System.Web.TraceContext)的特殊版本将写入ASP页面或Trace.axd的底部。 在ASP.NET 2+中,还有一个更健壮的日志logging框架称为健康监视。

Log4Net是比内置Trace,甚至ASP健康监测更为丰富和灵活的跟踪或日志logging方式。 像Diagnostics.Trace你configuration事件监听器(“appender”)。 对于简单的跟踪,使用像内置跟踪一样简单。 使用Log4Net的决定是你是否有更复杂的要求。

 private void TestMethod(string x) { Log.Info("String length is " + x.Length); if(x.Length> 10) { Log.Error("String was " + x.Length); throw new ArgumentException("String too long"); } } 

IMO …

日志logging不应该被devise用于开发debugging(但它不可避免地被这样使用)
测井应该devise用于运行监测和故障排除 – 这是其存在的理由。

跟踪应devise用于开发debugging和性能调优。 如果在现场可用,则可用于真正的低级操作故障排除,但这不是其主要目的

鉴于此,过去我所见过(并devise/实施)的最成功的方法并不能将两者结合在一起。 最好把这两个工具分开,每个工作尽可能做好。

log4net非常适合这两个。 我们通过使用DEBUG日志logging级别来区分用于发布后诊断的日志logging和用于开发目的的“跟踪”。 具体来说,开发人员使用Debug()来logging他们的跟踪输出(开发过程中唯一感兴趣的东西Debug() 。 我们的开发configuration将级别设置为DEBUG:

 <root> <level value="DEBUG" /> ... </root> 

产品发布之前,级别变为“INFO”:

 <level value="INFO" /> 

这将从版本日志中删除所有的DEBUG输出,但是保持INFO / WARN / ERROR。

还有其他的log4net工具,比如filter,层次结构(通过命名空间)logging,多个目标等,我们发现上面这个简单的方法相当有效。

logging不是跟踪 。 这两个应该是不同的性能特点的库。 实际上,我自己写了一个跟踪库 ,它具有独特的属性,当启用了跟踪的方法留下一个exception时,它可以自动跟踪exception。 除此之外,还可以以优雅的方式解决触发代码中特定位置exception的问题。

我会说是的。 logging是确定过去发生的唯一方法 – 如果客户打电话来说没有发生预期的事情,没有日志,你只能耸耸肩,试着重现错误。 有时这是不可能的(取决于软件的复杂性和对客户数据的依赖)。

还有一个日志logging审核的问题,可以编写一个日志文件,其中包含关于用户正在做什么的信息 – 所以您可以使用它来缩小debugging问题的可能性,甚至可以validation用户的声明(如果您得到一个报告,说系统坏了,xyz没有发生,你可以查看日志找出操作失败的启动过程,或者没有点击正确的选项使其工作)

然后是logging报告,这是大多数人认为logging是为了。

如果您可以定制日志输出,则将所有内容放入日志中,并减less或增加写入的数据量。 如果你可以dynamic地改变输出水平,那就完美了。

您可以使用任何方式编写日志,但要注意性能问题。 我发现追加到一个文本文件是最好的,最便携的,最容易查看,和(非常重要的)最容易检索,当你需要它。

logging!=debugging

有时保留日志文件是解决客户端问题的必要条件,他们certificate了服务器端发生的事情。

另外,请考虑logging或追踪哪些信息。 对于感性信息尤其如此。

例如,虽然通常可以logging一个错误说明

“用户X”试图访问但由于密码错误而被拒绝“,

logging一个错误说明是不正确的

“用户'X'试图访问,但被拒绝,因为密码”秘密“是不正确的。

将这些敏感信息写入跟踪文件是可以接受的(并且在要求他启用跟踪以扩展生产故障排除之前,通过“某种方式”警告客户/用户这一事实)。 但是对于日志logging,我总是把它作为一个政策,这样的感性信息是永远不会被写入的(即log4net中的INFO及以上的级别)。

当然,这必须通过代码审查来执行和检查。

  • 如何追踪log4net的问题
  • 你可以在代码中configurationlog4net而不是使用configuration文件?
  • 间歇log4net RollingFileAppenderlocking的文件问题
  • 使log4net使用应用程序configuration文件作为configuration数据
  • 如何以编程方式更改文件位置?
  • Log4Net将两个不同级别的日志logging到同一个logging器的两个不同的appender
  • log4net与Nlog
  • 一个类库的app.config
  • 在使用包装器的时候,如何保存Log4Net的类和方法名来logging?
  • Log4Net Wrapper类是什么样的?
  • Log4net在文件名中使用date滚动每日文件名