转自：http://aabbc1122.blog.163.com/blog/static/57043257201161384217610/

日志是应用程序中不可缺少的一部份，不仅可以记录应用程序的运行状态，还可以记录一些BUG，便于应用程序的更新与修改。
在.Net有好几种方法可以对日志进行管理。
1、数据库日志。
2、文本日志。
3、系统事件日志。

首先，对于数据库日志而言，它的使用简单而且方便。这里就不做太多的讨论，相信写过与数据相关的项目的人都会用数据来记录一些日志。然而它唯一不好的就是：必须先保证你的数据库链接是正确无误的。
然而这一保证不是必然的，所以这里我再讨论一下其它的两种情况，文本日志及系统事件日志。

文本日志：
它使用简单，而且查看也方便。不好的就是不便于做大量的日志，而且日志内容的查看与分析都不方便。然而它还是可在在一些不适合数据库日志的地方使用。例如一些测试消息的输出，一些独立组件的少量日志等。
一般情况下，为了方便管理，以天为单位对日志文件进行分类。这样一来也可以简单的对文件进行管理。例如：你的文件名可以知道这个日志是什么时候的，然后可以简单的做一个类似数据库一样的查询，管理也还方便。毕竟文本对系统来说是如此的简单。
.Net有一个诊断类，可以把文本以监听的方式添加到Trace以及Debug上，这样一来，你的所有指向Trace和Degug的输出都会记录到文件里去。这是一个很不错的方法。

using System.Diagnostics;

Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString(“yyyyMMdd”)+”..log”));
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));

或者：
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString(“yyyyMMdd”)+”..log”));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));

这里的区别是：Trace在Release下可以使用，而Debug只在Debug下使用。
我觉得所有的文本日志中，上面的方法是最好用的。你只须要再做一个日志管理的类就行了。
当然，还要注意，就是监听在24小时后要更新一次，应该把当前的监听清理掉，然后重新添加一个。这也简单。
另一个方法就是自己写文本进行管理。这样的方法要略麻烦一点点，道也不难。

然而文本日志除了不便于做大量日志的工作以还，还有一个致命的问题：进程冲突！
因为文本日志要锁定正在写的文本文件，所以其它要写该文件的程序会出现错误。一般情况下，如果应该程序只有一个副本在运行，而且把日志做为一个全局的静态对象来处理，也不会有什么太大的问题。但程序的第二个副本会因为文件不能打开而启动失败。
这并不是一个无法解决的问题，只用保证程序有一个副本就行了。如果不保证的话，那么小有一点复杂，这里就不再讨论了，下次有机会再讨论这个问题。

对于上面的问题，我想暂时放弃文本日志，用系统的事件日志来处理。

系统事件日志：
.net下有一个EventLog类，它直接与系统的事件日志关联。
简单的一个：
EventLog.WriteEntry(“LogSource”,”This is a test log.”);
就可以往系统里写一个事件了。
然而把它用好也还有点点麻烦。首先是上面的方法会在系统的Application下写一个事件日志，而且为默认为Information类型。这样很不利于管理，大家可以在管理工具里看一下日志，就会发现大量的日志，自己写的一个小日志简直无法找到。
然而.Net为我们提供了几个方法来更好的管理日志。

1、添加一个新的LogSource。
什么是LogSource？其实简单的说，它就是日志的一个分类标记，例如你可以用程序一次取出所以LogSource为指定内容的日志。这样一来，只要你记得这个Source名，你就可以读取和分类管理日志了。
默认情况下，你在直接用EventLog的静态函数写日志的时候，要指定一个LogSource，如果LogSource不存在，那么它就自动在Application下建立一个，因此，创建LogSource就这么简单了。

2、添加一个新的Log.
什么是Log.这里的Log是指系统事件日志里的大日志分类，一般情况下，系统有Application，System和Sercuity三个日志，每个下面有不同的Soucce，这样就构成了日志系统。
你不能独立的创建一个Log，因为.NET里没有提供任何方法来创建一个Log,只能通过函数：CreateEventSource(string,string)
来创建一个Sourcce，此时如果你这样做：CreateEventSource(“MySource”,”MyLog”);
你就会在日志管理器里看到多了一个MyLog类，然而再这样写日志：
EventLog.WriteEntry(“MySource”,”This is a test log.”);
就可以写一条记录到MyLog分类下，这样就可以很好的管理自己的日志了。
需要说明的是：
如果Source已经存在，那么创建会失败。注意：不管Source的哪个Log下，只要Source的名字已经存在，那么你的创建都会失败。例如：如果有一个”Source1″的日志在Application里，那么你就不能再到其它Log里再创建一个名为”Source1″的日志了。另外：你用程序创建的日志不能在日志管理器里删除它（Messages可以删除，但日志分类不能删除）。方法是你还是用程序可以来删除，或者在注册表里来删除它。它的位置：[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\]
看一下注册表，或许你会明白一些。
最后就是用日志实例对象来写日志。你可以指定一个Log名和一个Source名来写日志，但要注意，必须是Log与Source匹配，否则也会出现错误。这比直接用静态方法来写日志要复杂一点点，但你有更多的自由空间。
系统事件日志不好的地方就是日志只保存三个月，而且不好管理。如果你可以直接管理服务器，或者就在本机上运行应该会好一些，否则你就不得不自己写些代码来管理日志了。当然，如果一些重要的日志，可以导出到其它文件中。
它的好处是很多的：
1、不必与数据库链接，效率会高一些，也不会有数据库访问失败的问题。
2、不会有进程冲突问题，它是系统的日志，不管是什么应用程序都可以写日志。
3、全局可用，不管在哪里都可以直接写日志，而且可读。因此可以把它当成一个消息通信平台。（当然，可能只有那些大脑有点问题的人会这样做。）然而我只是想说明：A进程写的日志，B进程可以直接读取。

好了，关于日志这次就总结这些。