. Several log management methods under Net

. Several log management methods under Net

Logs are an integral part of an application, not only to record the running state of an application, but also to record bugs that facilitate application updates and modifications.
There are several ways to manage logs in. Net.
1, database log.
2, text log.
3, System event log.

First, it's easy and easy to use for database logs. There is no much discussion here, and people who write about the data will use the data to record some logs. But the only downside is that you have to make sure that your database links are correct.
However, this guarantee is not inevitable, so here I will discuss the other two cases, the text log and the system event log.

Text log:
It's easy to use and easy to view. Bad is not easy to do a lot of log, and the log content of the view and analysis are not convenient. However, it can be used in some places that are not suitable for database logs. For example, some test message output, some independent components of a small number of logs.
In general, in order to facilitate management, the log files are categorized in days. This can also be a simple management of the file. For example: Your file name can know when this log is, then you can simply do a similar database query, management is also convenient. After all, the text is so simple for the system.
. NET has a diagnostic class that can be added to trace and debug by listening to the text, so that all of your output 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 that trace is available under release and debug is only used under Debug.
I think the above method is best used in all the text logs. You just need to do a log management class on the line.
Of course, it should also be noted that monitoring in 24 hours after the update, should be the current listening to clean up, and then add a new one. This is also simple.
Another method is to write your own text to manage. This kind of method is a little bit troublesome and the Tao is not difficult.

However, the text log is not easy to do a lot of log work to return, there is a fatal problem: process conflict!
Because the text log locks the text file that is being written, there are errors in other programs that will write the file. Under normal circumstances, if you should have only one copy of the program running, and the log as a global static object to deal with, there is no big problem. However, a second copy of the program fails to start because the file cannot be opened.
This is not an unresolved issue, just use the guarantee program to have a copy of the line. If there is no guarantee, then the small is a little more complex, here is no longer discussed, the next opportunity to discuss this issue.

For the above question, I would like to temporarily discard the text log, with the system's event log to deal with.

System Event Log:
There is a EventLog class under. NET that is directly associated with the system's event log.
The simple one:
EventLog.WriteEntry ("Logsource", "This is a test log.");
You can write an event to the system.
But it's also a bit of a hassle to use it well. First, the above method writes an event log under the application of the system and defaults to the information type. This is not conducive to management, you can look at the management tools in the log, you will find a large number of logs, write a small log can not find.
However. NET provides us with several ways to better manage the log.

1, add a new logsource.
What is Logsource? In fact, it is simply that the log is a category tag, for example, you can use the program to take out the Logsource for the specified content of the log. This way, as long as you remember the source name, you can read and classify the admin log.
By default, when you write logs directly with eventlog static functions, you specify a logsource, and if Logsource does not exist, it automatically creates one under application, so creating Logsource is so simple.

2, add a new log.
What is log. Log here refers to the system event log in the large log classification, in general, the system has Application,system and sercuity three logs, each below has a different soucce, this constitutes a log system.
You can't create a log independently, because. NET does not provide any method to create a log, only through functions: CreateEventSource (string,string)
To create a sourcce, at this point if you do: CreateEventSource ("MySource", "mylog");
You'll see one more MyLog class in the Log manager, and then write the log again:
EventLog.WriteEntry ("MySource", "This is a test log.");
You can write a record to the MyLog category, so that you can manage your own log well.
What needs to be stated is:
If source already exists, then the creation fails. Note: Regardless of which log of source, if the name of source already exists, then your creation will fail. For example, if you have a "Source1" log in application, then you can't create a log called "Source1" in the other log. In addition: the log you created with the program cannot be deleted in the Log manager (messages can be deleted, but the log category cannot be deleted). The method is that you can either remove it by using a program or delete it in the registry. Its location: [hkey_local_machine\system\currentcontrolset\services\eventlog\]
Look at the registry, perhaps you will understand some.
Finally, the log instance object is used to write the log. You can specify a log name and a source name to write logs, but be aware that the log must match the source, or there will be an error. This is a little more complicated than writing a log directly with static methods, but you have more free space.
The bad thing about the system event log is that the log is only kept for three months and is not manageable. If you can directly manage the server, or on the local run should be better, otherwise you will have to write some code to manage the log. Of course, if some important logs can be exported to other files.
It's a lot of benefits:
1, do not have to link with the database, the efficiency will be higher, there will be no database access failure problems.
2, there will be no process conflict problem, it is the system log, no matter what application can write log.
3, global availability, no matter where you can write directly to the log, but also readable. So you can think of it as a message communication platform. (Of course, only those who have a problem with the brain will do so.) However, I just want to explain: a process write log, b process can be read directly.

All right, here's the summary of the log.