什么时候在代码中需要多个TraceSource? [英] When do I need more than one TraceSource in code?
问题描述
如果一个应用程序将其所有活动数据写入一个日志文件，那么使用多个TraceSource有什么用?我只是对用例中需要一个以上的TraceSource的情况感到好奇.
有关使用TraceSources的良好起点，请参阅以下其他问题的答案:
我想说的是，每当您拥有一个以上的类时，您可能(可能)考虑拥有多个TraceSource.
拥有多个TraceSource的一个优点是，它增加了您可以控制日志记录的粒度.例如，如果在每个类中使用不同的TraceSource，则可以控制记录到类级别.您可以打开一个(或多个)特定的类，然后关闭所有其他的类.
这是NLog和log4net用户的常见模式.使用这些日志记录平台进行的类的典型初始化如下所示:
public class A
{
//NLog example
private static Logger logger = LogManager.GetCurrentClassLogger();
public F()
{
logger.Info("Inside F");
}
}
在此示例中，类A的记录器以该类的完全限定名称命名(NLog在GetCurrentClassLogger()中进行了艰苦的工作).
要使用TraceSource进行类似的操作，您将执行以下操作:
public class A
{
private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();
public F()
{
ts.Information("Inside F");
}
}
如果您在每个班级都这样做，则可以轻松地按班级控制日志记录.
我不太确定此模式在TraceSource中是否像在log4net和NLog中一样普遍.我认为您可能更经常看到TraceSource的用户按功能区域获取他们的TraceSource.
因此，您可以将应用分为读取"，处理"和写入"功能(或任何对您有意义的功能).在这种情况下，您可以根据使用类的功能范围在类中获取适当的TraceSource:
public class FileReader
{
private static TraceSource ts = new TraceSource("Read");
public F()
{
ts.Information("Hello from FileReader.F");
}
}
public class NetworkReader
{
private static TraceSource ts = new TraceSource("Read");
public F()
{
ts.Information("Hello from NetworkReader.F");
}
}
以此类推.
现在，您可以为读取"打开日志记录，然后为所有其他功能区域关闭日志记录(或者为读取"打开详细日志记录，而为所有其他功能打开较少详细记录日志.)
此外，TraceListeners的选项之一是输出TraceSource名称.因此，在输出中将更容易理解日志记录，因为如果您选择这样做，则可以相对容易地找到从特定功能区域(或特定TraceSource)生成的所有日志记录消息.
如果您有一个好的命名空间命名约定，您甚至可以考虑基于命名空间层次结构中的某个节点甚至基于该类所在的程序集为每个类获取TraceSource.会为您检索该信息.
由于您正在查看TraceSources，所以我建议您在Codeplex上查看此项目:
http://ukadcdiagnostics.codeplex.com/
这是一个不错的项目(基于TraceSource)，允许您以类似于log4net和NLog的方式格式化日志输出.
我也鼓励您看一下这个围绕Castle的TraceSource构建的日志包装器.
https://github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs
他们所做的有趣的事情是为TraceSource名称提供层次结构.过去我已经实现了类似的方法.效果很好.
我在这个问题上的回答提供了一个有关TraceSource层次结构如何有益的想法:
祝你好运！
If one application is writing all its activity data in one log file, is there any use of having more than one TraceSource? I am just curious about the uses cases where one will need more than one TraceSource in the code.
See these answers to other questions for a good starting point on using TraceSources:
can't understand .net 2010 tracing and app.config
How to use TraceSource across classes
I would say that any time you have more than one class you might (might) consider having more than one TraceSource.
One advantage to having more than one TraceSource is that it increases the granularity at which you can control your logging. For example, if you use a different TraceSource in every class, then you could control the logging down to the class level. You could turn on one (or more) specific classes and turn off all others.
This is a common pattern for users of NLog and log4net. Typical initialization of classes using those logging platforms will look something like this:
public class A
{
//NLog example
private static Logger logger = LogManager.GetCurrentClassLogger();
public F()
{
logger.Info("Inside F");
}
}
In this example, the logger for class A is named for the fully qualified name of the class (NLog does the hard work in GetCurrentClassLogger()).
To do something similar with TraceSource, you would do something like this:
public class A
{
private static TraceSource ts = new TraceSource(System.Reflection.GetCurrentMethod().DeclaringType.ToString();
public F()
{
ts.Information("Inside F");
}
}
If you did this in every class, you could easily control you logging by class.
I'm not so sure that this pattern is as common with TraceSource as it is with log4net and NLog. I think that you might more often see users of TraceSource get their TraceSources by functional area.
So, you might divide your app up into "Read", "Process", and "Write" functionality (or whatever makes sense for you). In that case, you could get the appropriate TraceSource in your classes based on the functional area in which they are used:
public class FileReader
{
private static TraceSource ts = new TraceSource("Read");
public F()
{
ts.Information("Hello from FileReader.F");
}
}
public class NetworkReader
{
private static TraceSource ts = new TraceSource("Read");
public F()
{
ts.Information("Hello from NetworkReader.F");
}
}
And so on.
Now you could turn logging on for "Read", and off for all other functional areas (or turn on verbose logging for "Read" and less verbose logging for all others).
In addition, one of the options with TraceListeners is to output the TraceSource name. So, in your output it will easier to make sense of your logging because you could, if you choose to do so, relatively easily find all logging messages that are generated from a particular functional area (or by a particular TraceSource).
If you have a good namespace naming convention, you could even consider getting the TraceSource for each class based on some node in the namespace hierarchy or even based on the assembly that the class lives in. There are .NET calls for a Type that will retrieve that information for you.
Since you are looking at TraceSources, I would encourage you to look at this project at codeplex:
http://ukadcdiagnostics.codeplex.com/
It is a nice project (based on TraceSource) that allows you to format your logging output in a similar fashion to what you can do with log4net and NLog.
I would also encourage you to take a look at this logging wrapper built around TraceSource from Castle.
https://github.com/castleproject/Castle.Core/blob/master/src/Castle.Core/Core/Logging/TraceLogger.cs
The interesting thing that they have done is to provide a hierarchy to TraceSource names. I have implemented something similar in the past. It works out pretty well.
My answer in this question provides an idea for how a TraceSource hierarchy can be beneficial:
What's the best approach to logging?
Good luck!
这篇关于什么时候在代码中需要多个TraceSource?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
