.Net下几种日志管理方法

2008-02-22 09:37:56来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

.Net下几种日志管理方法

日志是应用程序中不可缺少的一部份,不仅可以记录应用程序的运行状态,还可以记录一些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进程可以直接读取。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:支持正则表达式的UrlMapping(ASP.NET2.0)

下一篇:ASP.NET中为DataGrid添加单选框