1 - include stack trace without source file information
2 - include full stack trace
1 - include stack trace without source file information
2 - include full stack trace
If the url starts with
${aspnet-application:variable=myvariable} - produces "123"
${aspnet-application:variable=anothervariable} - produces "01/01/2006 00:00:00"
${aspnet-application:variable=anothervariable:culture=pl-PL} - produces "2006-01-01 00:00:00"
${aspnet-application:variable=myvariable:padding=5} - produces " 123"
${aspnet-application:variable=myvariable:padding=-5} - produces "123 "
${aspnet-application:variable=stringvariable:upperCase=true} - produces "AAA BBB"
1 - include stack trace without source file information
2 - include full stack trace
- en-US - English (United States)
- en-UK - English (United Kingdom)
- pl-PL - Polish
- ar-SA - Arabic (Saudi Arabia)
${aspnet-request:item=v}
${aspnet-request:querystring=v}
${aspnet-request:form=v}
${aspnet-request:cookie=v}
${aspnet-request:serverVariable=v}
${aspnet-session:variable=myvariable} - produces "123"
${aspnet-session:variable=anothervariable} - produces "01/01/2006 00:00:00"
${aspnet-session:variable=anothervariable:culture=pl-PL} - produces "2006-01-01 00:00:00"
${aspnet-session:variable=myvariable:padding=5} - produces " 123"
${aspnet-session:variable=myvariable:padding=-5} - produces "123 "
${aspnet-session:variable=stringvariable:upperCase=true} - produces "AAA BBB"
1 - include stack trace without source file information
2 - include full stack trace
- ApplicationData - roaming application data for current user.
- CommonApplicationData - application data for all users.
- MyDocuments - My Documents
- DesktopDirectory - Desktop directory
- LocalApplicationData - non roaming application data
- Personal - user profile directory
- System - System directory
1 - include stack trace without source file information
2 - include full stack trace
1 - include stack trace without source file information
2 - include full stack trace
1 - include stack trace without source file information
2 - include full stack trace
1 - include stack trace without source file information
2 - include full stack trace
1 - include stack trace without source file information
2 - include full stack trace
${longdate}|${level:uppercase=true}|${logger}|${message}
1 - include stack trace without source file information
2 - include full stack trace
This example causes the messages to be written to server1, and if it fails, messages go to server2.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example causes the messages to be written to either file1.txt or file2.txt chosen randomly on a per-message basis.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example causes the messages to be written to either file1.txt or file2.txt. Each odd message is written to file2.txt, each even message goes to file1.txt.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example causes the messages to be written to both file1.txt or file2.txt
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
Typically this target is used in cooperation with PostFilteringTargetWrapper to provide verbose logging for failing requests and normal or no logging for successful requests. We need to make the decision of the final filtering rule to apply after all logs for a page have been generated.
To use this target, you need to add an entry in the httpModules section of web.config:
]]>
To set up the ASP.NET Buffering target wrapper configuration file, put
the following in
This assumes just one target and a single rule. More configuration options are described here.
To configure the target programmatically, put the following
piece of code in your
Fully working C# project can be found in the
Asynchronous target wrapper allows the logger code to execute more quickly, by queueing messages and processing them in a separate thread. You should wrap targets that spend a non-trivial amount of time in their Write() method with asynchronous target to speed up logging.
Because asynchronous logging is quite a common scenario, NLog supports a shorthand notation for wrapping all targets with AsyncWrapper. Just add async="true" to the <targets/> element in the configuration file.
... your targets go here ...
]]>
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example causes the messages not contains the string '1' to be ignored.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example works like this. If there are no Warn,Error or Fatal messages in the buffer only Info messages are written to the file, but if there are any warnings or errors, the output includes detailed trace (levels >= Debug). You can plug in a different type of buffering wrapper (such as ASPNetBufferingWrapper) to achieve different functionality.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example causes each log message to be repeated 3 times.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
This example causes each write attempt to be repeated 3 times, sleeping 1 second between attempts if first one fails.
To set up the target in the configuration file, use the following syntax:
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
To set up the ASP.NET Trace target in the configuration file, put
the following in
This assumes just one target and a single rule. More configuration options are described here.
To configure the target programmatically, put the following
piece of code in your
Fully working C# project can be found in the
HTTP Request List:
HTTP Request Details:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
NOTE: If your receiver application is ever likely to be off-line, don't use TCP protocol or you'll get TCP timeouts and your application will crawl. Either switch to UDP transport or use AsyncWrapper target so that your application threads will not be blocked by the timing-out connection attempts.
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
NOTE: If your receiver application is ever likely to be off-line, don't use TCP protocol or you'll get TCP timeouts and your application will crawl. Either switch to UDP transport or use AsyncWrapper target so that your application threads will not be blocked by the timing-out connection attempts.
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To print the results, use any application that's able to receive messages over TCP or UDP. NetCat is a simple but very powerful command-line tool that can be used for that. This image demonstrates the NetCat tool receiving log messages from Network target.
NOTE: If your receiver application is ever likely to be off-line, don't use TCP protocol or you'll get TCP timeouts and your application will crawl. Either switch to UDP transport or use AsyncWrapper target so that your application threads will not be blocked by the timing-out connection attempts.
There are two specialized versions of the Network target: Chainsaw and NLogViewer which write to instances of Chainsaw log4j viewer or NLogViewer application respectively.
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
You can use a single target to write to multiple files. The following
example writes each log message to a file named after its log level, so
it will create:
The file names can be quite complex for the most demanding scenarios. This example shows a way to create separate files for each day, user and log level. As you can see, the possibilities are endless.
Depending on your usage scenario it may be useful to add an asynchronous target wrapper around the file target. This way all your log messages will be written in a separate thread so your main thread can finish your work more quickly. Asynchronous logging is recommended for multi-threaded server applications which run for a long time and is not recommended for quickly-finishing command line applications.
The above examples assume just one target and a single rule. See below for a programmatic configuration that's equivalent to the above config file:
More configuration options are described here.
To set up the log target programmatically use code like this:
File target can also do file archiving, meaning that the log file is automatically moved to another place based on its size and time. This example demonstrates file archiving based on size. Files after 10000 bytes are moved to a separate folder and renamed log.00000.txt, log.00001.txt and so on.
File archiving can also be done on date/time changes. For example, to create a new archive file every minute use this code:
You can combine both methods as demonstrated here:
Note that file archiving works even when you use a single target instance to write to multiple files, such as putting each log level in a separate place:
You can write texts using alternative layouts, such as CSV (comma-separated values). This example writes files which are properly CSV-quoted (can handle messages with line breaks and quotes)
${basedir}/${level}.log
All
Caution: Enabling this option can considerably slow down your file
logging in multi-process scenarios. If only one process is going to
be writing to the file, consider setting
a random value between 0 and 20 milliseconds - 2nd attempt
a random value between 0 and 40 milliseconds - 3rd attempt
a random value between 0 and 80 milliseconds - 4th attempt
... and so on.
To set up the target in the configuration file, use the following syntax:
The result is:
To set up the log target programmatically similar to above use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
Mail target works best when used with BufferingWrapper target which lets you send multiple logging messages in single mail
To set up the buffered mail target in the configuration file, use the following syntax:
To set up the buffered mail target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
The result is a message box:
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
The result is:
To set up the target with coloring rules in the configuration file, use the following syntax:
The result is:
To set up the log target programmatically similar to above use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
The example web service that works with this example is shown below
- HKLM\Key\Full\Name
- HKEY_LOCAL_MACHINE\Key\Full\Name
- HKCU\Key\Full\Name
- HKEY_CURRENT_USER\Key\Full\Name
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
The result is a colorful console, where each color represents a single log level.
In addition you can configure your own word highlighting rules so that particular words or regular expressions will be marked with a distinguished color:
Programmatic equivalent of the above configuration:
Here's the result:
Custom row highlighting lets you colorize the output by any condition. This example shows how to mark all entries containing the word "serious" with white color on red background and mark all entries coming from a particular logger with yellow on blue.
Programmatic equivalent of the above configuration:
Here's the result:
| Condition | Foreground Color | Background Color |
|---|---|---|
| level == LogLevel.Fatal | Red | NoChange |
| level == LogLevel.Error | Yellow | NoChange |
| level == LogLevel.Warn | Magenta | NoChange |
| level == LogLevel.Info | White | NoChange |
| level == LogLevel.Debug | Gray | NoChange |
| level == LogLevel.Trace | DarkGray | NoChange |
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
You can use a single target to write to multiple queues (similar to writing to multiple files with the File target).
The above examples assume just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
To set up the target in the configuration file, use the following syntax:
This assumes just one target and a single rule. More configuration options are described here.
To set up the log target programmatically use code like this:
whenEquals or whenContains)
The type of the new filter
whenEquals or whenNotEqual)
1 - include stack trace without source file information
2 - include full stack trace
XML, CSV or HTML)
The type of the new layout
message or aspnet-request)
logger, message or aspnet-request)
The type of the new layout renderer
message or aspnet-request)
Parameters to the layout renderer.
File or Console)
The type of the new target
File or Console)