NLog class library usage-detailed configuration and nlog class library Exploration
1. Configuration file locations)
By scanning common directories at startup, NLog will try to use the found configuration information for automatic self-configuration.
1.1 separate *. exe Client
For a separate client, NLog searches for configuration information in the following directory:
1.2 ASP. NET Program
The directories searched in the ASP. NET project include:
1.2 hardware equipment Library (. NET Compact Framework)
. NET Compact Framework does not support program configuration files (*. exe. config) and environment variables, so NLog will only scan these places:
Conclusion 1.4
From the above, no matter which configuration file we name it NLog. config and put it in the application directory, we can certainly scan it, haha.
2. Configuration file format 2.1 NLog supports two Configuration file formats
First, we are familiar with the general configuration, using configSections
<configuration> <configSections> <section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/> </configSections> <nlog> </nlog></configuration>
If the second type is a separate Xml file, you need to configure it as follows:
<nlog xmlns=http://www.nlog-project.org/schemas/NLog.xsd
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance ></nlog>
It should be noted that the root node is <nlong> </nlong> and the two namespaces are optional. But for intelligent sensing, write it down.
2.1 configure sub-elements
- <Targets/>-defines log targets/outputs: declare the target
- <Rules/>-defines log routing rules: declares a rule.
- <Extensions/>-loads NLog extensions from the *. dll file to load the dll extension (in fact, I don't understand it, I never used it)
- <Include/>-includes external configuration file contains an external configuration file
- <Variable/>-sets the value of a configuration variable assigns a value to the configuration variable.
It must be noted that the first two elements, targets and rules, must be configured. The remaining elements are optional and should be used for more complex configurations. I have never used them again.
3. Targets)
The first article has been introduced, should no longer explain, specific output to the detailed configuration of the target, see the document: https://github.com/nlog/NLog/wiki/Targets
4. Routing Rules (Rules)
<Rules/> the region defines the log routing rules. Each route table item is a <logger/> element. <Logger/> has the following attributes:
For example:
5. Layouts and layout renderers)
One of the most powerful NLog functions is to use layouts. Syntax: "$ {attribute}" is composed of text surrounded by tags. This tag is also called layout renderers. We can use it to insert context-related information into the log information. La s can be applied in many places. For example, they can be used to control the format of output to screen or write file information, or to control file names.
Assume that we want each information output to the console to contain the following information:
- Current date and time
- Name of the class and method that generates log information
- Log Level
- Log Content
Layout is easy to implement: As mentioned above:
<target name="c" xsi:type="Console" layout="${longdate} ${callsite} ${level} ${message}"/>
Use Layout to control the output file name:
<target name="f" xsi:type="File" fileName="${logger}.txt"/>
Use date to differentiate log files. If you use the layout generator $ {1_date:
<target name="f" xsi:type="File" fileName="${shortdate}.txt"/>
For more layout generators, refer to the official documentation:
Https://github.com/nlog/NLog/wiki/Layout%20Renderers
6 Include files)
We have such a requirement that we do not want to make the NLog. cofige file too large, too large, and too tired to read. We can split it. How can we split the config into several small ones? Using include is simple.
<nlog> ... <include file="${basedir}/${machinename}.config"/> ...</nlog>
Specify the location of the config file to be included.
7 Variables)
Variables can also be defined in the configuration file. The example above is very clear:
// Declaration syntax
<variable name="var" value="xxx" /><nlog> <variable name="logDirectory" value="${basedir}/logs/${shortdate}"/> <targets> <target name="file1" xsi:type="File" fileName="${logDirectory}/file1.txt"/> <target name="file2" xsi:type="File" fileName="${logDirectory}/file2.txt"/> </targets></nlog>
8. Automatic reconfiguration)
It sounds really hard to understand. But there is nothing. In other words, once the program is started, after the NLog. config file is read, the configuration file will no longer be read after the program is started. If we don't want to stop the program, for example, how can we say that the server stops. This configuration is used. The configuration function is that once you modify the configuration file, the program will re-read the configuration file, that is, automatically re-configure. Directly run the Code:
<nlog autoReload="true"> ...</nlog>
9. Troubleshooting logging)
The program is okay, but the log is faulty. What should I do? What is wrong? What should I do if the log itself exists in addition to bugs? This requires log troubleshooting. Write the error information of the log into the log.
- <Nlog throwExceptions = "true"/>
- <Nlog internalLogFile = "file.txt"/>-Setting the internalLogFile attribute allows NLog to write internal debugging and exception information to the specified file.
- <Nlog internalLogLevel = "Trace | Debug | Info | Warn | Error | Fatal"/>-determines the level of internal logs. The higher the level, the simpler the output log information.
- <Nlog internalLogToConsole = "false | true"/>-whether to output internal logs to the standard console.
- <Nlog internalLogToConsoleError = "false | true"/>-whether to output internal logs to the stderr console ).
Setting the throwExceptions attribute to "true" can prevent NLog from blocking such exceptions, but throw them to the caller. This can help us quickly locate problems during deployment. Once the application has been correctly configured, we recommend that you set the throwExceptions value to "false" so that the application will not crash due to log issues.
10. Asynchronous processing)
The principle is not to mention. directly add the Code to make it capable of asynchronous processing.
<nlog> <targets async="true"> <!-- all targets in this section will automatically be asynchronous --> </targets></nlog>
11 Default encapsulation (Default wrappers)
We want to use the same encapsulation to process all the targets, such as adding buffering and/or automatic retry functions.
For this reason, NLog provides a special Syntax: <default-wrapper/>. You only need to put this element in the <targets/> area, and then all the targets will automatically load the same encapsulated target. Note that <default-wrapper/> is only valid for the current <targets/> region, and you can use multiple <targets/> regions, in this way, you can group the target and process it with different encapsulation targets.
<nlog> <targets> <default-wrapper xsi:type="BufferingWrapper" bufferSize="100"/> <target name="f1" xsi:type="File" fileName="f1.txt"/> <target name="f2" xsi:type="File" fileName="f2.txt"/> </targets> <targets> <default-wrapper xsi:type="AsyncWrapper"> <wrapper-target xsi:type="RetryingWrapper"/> </default-wrapper> <target name="n1" xsi:type="Network" address="tcp://localhost:4001"/> <target name="n2" xsi:type="Network" address="tcp://localhost:4002"/> <target name="n3" xsi:type="Network" address="tcp://localhost:4003"/> </targets> </nlog>
In the above example, we define two buffer file targets and three asynchronous and automatic retry network targets.
12 Default target parameters)
In fact, the default is to unify the scattered definition in one region. It is just a syntactic sugar problem. The default parameter is to abstract the same parameters into one region for unified definition. The following code is equivalent.
<nlog> <targets> <target name="f1" xsi:type="File" fileName="f1.txt" keepFileOpen="false"/> <target name="f2" xsi:type="File" fileName="f2.txt" keepFileOpen="false"/> <target name="f3" xsi:type="File" fileName="f3.txt" keepFileOpen="false"/> </targets> </nlog>
<nlog> <targets> <default-target-parameters xsi:type="File" keepFileOpen="false"/> <target name="f1" xsi:type="File" fileName="f1.txt"/> <target name="f2" xsi:type="File" fileName="f2.txt"/> <target name="f3" xsi:type="File" fileName="f3.txt"/> </targets></nlog>
How does the class library work in java? For example, if Arrays sort is used for sorting, do you need to know its source code? Or you just need to use it.
// In fact, This sorting principle is a Bubble sorting. If it is a char type, it is sorted by the code table. In general, it will be used, and there is no need to study it in depth ....