Several log management methods under .Net
Log is an indispensable part of the application. It can not only record the running status of the application, but also record some BUGs to facilitate the update and modification of the application.
There are several ways to manage logs in .Net.
1. Database log.
2. Text log.
3. System event log.
First of all, it is simple and convenient to use for database logs. I won’t discuss too much here. I believe that anyone who has written data-related projects will use data to record some logs. However, the only disadvantage is that you must first ensure that your database link is correct.
However, this guarantee is not inevitable, so here I will discuss the other two situations, text logs and system event logs.
Text log:
It's simple to use and easy to view. The disadvantage is that it is not convenient to make a large number of logs, and it is not convenient to view and analyze the log content. However, it can still be used in some places where database logging is not suitable. For example, the output of some test messages, a small amount of logs of some independent components, etc.
Under normal circumstances, in order to facilitate management, log files are classified in units of days. In this way, files can be easily managed. For example: You can know when this log is by your file name, and then you can simply make a query similar to a database, and management is also convenient. After all, text is so simple to the system.
.Net has a diagnostic class that can add text to Trace and Debug in the form of listening. In this way, all your output directed to Trace and Degug will be recorded in the file. This is a very good method.
using System.Diagnostics;
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
or:
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
The difference here is: Trace can be used under Release, while Debug can only be used under Debug.
I think among all text logs, the above method is the most useful. You only need to make another log management class.
Of course, you should also note that the monitor needs to be updated after 24 hours. You should clean up the current monitor and add a new one. It's also simple.
Another method is to write the text yourself for management. This method is a little more troublesome, but it's not difficult.
However, in addition to being inconvenient for doing a lot of logging work, text logs also have a fatal problem: process conflicts!
Because text logging locks the text file being written, other programs that want to write to the file will encounter errors. Under normal circumstances, if there is only one copy of the program running and the log is processed as a global static object, there will not be any big problem. But the second copy of the program will fail to start because the file cannot be opened.
This is not an unsolvable problem, just make sure you have a copy of the program. If it is not guaranteed, then it is a little complicated, so we will not discuss it here anymore. We will discuss this issue next time when we have the opportunity.
For the above problem, I want to temporarily abandon the text log and use the system event log to deal with it.
System event log:
There is an EventLog class under .net, which is directly associated with the system's event log.
Simple one:
EventLog.WriteEntry("LogSource","This is a test log.");
You can write an event into the system.
However, using it well can be a bit tricky. First, the above method will write an event log under the system's Application, and the default is Information type. This is not conducive to management. You can look at the logs in the management tool and you will find a large number of logs. It is impossible to find a small log written by yourself.
However, .Net provides us with several methods to better manage logs.
1. Add a new LogSource.
What is LogSource? In fact, to put it simply, it is a classification mark of logs. For example, you can use a program to retrieve logs whose LogSource is the specified content at one time. In this way, as long as you remember the Source name, you can read and categorize the logs.
By default, when you write logs directly using the static function of EventLog, you need to specify a LogSource. If the LogSource does not exist, it will automatically create one under the Application. Therefore, creating a LogSource is as simple as that.
2. Add a new Log.
What is Log? The Log here refers to the large log classification in the system event log. Generally, the system has three logs: Application, System and Service, each with a different Soucce, thus forming a log system.
You cannot create a Log independently, because .NET does not provide any method to create a Log, you can only use the function: CreateEventSource(string, string)
To create a Source, if you do this: CreateEventSource("MySource", "MyLog");
You will see an additional MyLog class in the log manager, and then write the log like this:
EventLog.WriteEntry("MySource","This is a test log.");
You can write a record under the MyLog category, so that you can manage your own logs well.
What needs to be explained is:
If the Source already exists, the creation will fail. Note: No matter which Log of Source, as long as the name of Source already exists, your creation will fail. For example: If there is a log of "Source1" in Application, then you cannot create a log named "Source1" in other Logs. In addition: the logs you create using the program cannot be deleted in the log manager (Messages can be deleted, but log categories cannot be deleted). The method is that you can still use a program to delete it, or delete it in the registry. Its location: [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog]
Take a look at the registry, maybe you will understand something.
The last step is to use the log instance object to write the log. You can specify a Log name and a Source name to write logs, but be aware that the Log and Source must match, otherwise an error will occur. This is a little more complicated than logging directly using static methods, but you have more freedom.
The disadvantage of the system event log is that the log is only saved for three months and is difficult to manage. It would be better if you could manage the server directly, or run it locally, otherwise you would have to write some code to manage the logs yourself. Of course, if some important logs can be exported to other files.
Its benefits are many:
1. There is no need to connect to the database, the efficiency will be higher, and there will be no problem of database access failure.
2. There will be no process conflicts. It is a system log. No matter what application it is, it can write logs.
3. Globally available, logs can be written directly no matter where they are and are readable. Therefore it can be regarded as a messaging communication platform. (Of course, maybe only those with some brain problems will do this.) However, I just want to explain: the log written by process A can be read directly by process B.
Okay, that’s all about the log this time.
http://www.cnblogs.com/WuCountry/archive/2006/08/22/483090.html