Introduction

I was getting close to deploying a new ASP.NET web application, and needed a good, solid logger. I had written my own simple logger when I started the project, but it just wasn't very clean, easy to manage, or configurable. I'd seen many references to log4net scattered about, and decided to check it out. And, I'm glad I did. In a few hours, I was up and running. It was a bit difficult at first as there are so many different ways to use it and a lot of documentation (a good thing). Finding the correct configuration took a little effort, but was well worth it.

After setting up a few basic file and email loggers, I started looking at all the other loggers (a.k.a. Appenders) that log4net offered. I thought it would be great to have a real time console showing me what was happening after the application was deployed. The UDP logger seemed interesting, but I didn't know enough about log4net to imagine how I could use it. So, I searched around a bit to see if anyone had any example uses. I came across the Log4NetViewer. It's a simple WinForm app that receives log4net messages sent from the UdpAppender. Pretty neat, eh? Now, I could remotely monitor my web applications. So, I set it up and used it for a while in my dev environment. It worked well, but I really didn't like the way it displayed the log messages. It uses a grid to display the log. A new row is appended to the grid when a new log message is received. The problem though, is that long messages, like exceptions, are hard to read. You either had to scroll through the cell, or copy/paste the message. Even worse, no source code! Anyway, I let the subject rest, and moved on to more important tasks.

A while later, while making some configuration changes to my log4net setup, I came across the ConsoleAppender and, the even better, ColoredConsoleAppender. Who doesn't love color? Maybe I could monitor my web app's log messages in a log4net console window? The messages would be easy to read, and could even be color coded. I started digging around for some samples and realized that the console loggers cannot directly work with ASP.NET applications. There really is no console in log4net. No console will magically pop-up when you add the ConsoleAppender to your log4net configuration. A console would need to run in the same process or context as the ASP application. It cannot, but does it really need to?

No. Of course, not...

Ah ha! I recalled the UdpAppender. I could create a .NET console application and use the System.Net.Sockets.UdpClient to listen for UDP log messages sent from my ASP.NET application. Just like the Log4NetViewer. Then, use the ColoredConsoleAppender to write them to the console window. A couple hours later... Presto.

Lastly, in your ASP.NET application, configure a source UdpAppender to send UDP log messages to your console. Add the following to your log4net config file (see sample application for full config). There a several ways to configure log4net. If you're using a different method, you'll only need the <appender...> section below, and a <appender-refref="UdpAppender"> in your root. Remember to match the RemotePort with the UdpClient port in your console app. Also, note that you can format the pattern layout however you like, and even add delimiters and place holders that can be parsed by the client. Below, the {%level} value is replaced in the main loop before being written to the screen. Additional information on the PatternLayout syntax can be found in the log4net SDKPatternLayout class. Note that the layout conversionPattern above (in the console's App.config) has no pattern formatting. The formatting should be set at the source UdpAppender pattern layout config. I'm sure you can use other layout types as well. There are quite a few.

Points of interest

The UdpAppender gives great flexibility in bridging remote log viewers and writers. Like the Log4NetViewer, WinForms clients can be created as well as Console clients, as seen here. Even remote file loggers. You simply need a UDP client and log4net to broadcast, capture, and rewrite log messages. Also, the source UdpAppender can be configured to broadcast log messages to the entire subnet. This allows you to setup multiple client loggers in multiple locations, doing multiple things.

On the flip side, the UDP protocol is meant only to broadcast, there is no validation between the sender and the receiver. So, there is no guarantee that messages will be received or even received in the same order as sent. But that's okay with me, the RollingFileAppender doesn't miss anything.

I hope you enjoyed this article. This is my first article post, so I thought I would keep the topic simple... I think.

Hey joebeam. Thanks for the love. When it comes to spoofing, anything is possible. If security is a concern, which it should be, then yes, you should restrict the Udp sender () as well as the receiver. In my case, the server has two NIC cards and my loggers only broadcast on the internal card. Though I do point them at a specific client IP.

Although, If you wanted to know if anyone was spoofing, you could setup another, untrusted, client with no security restrictions. It's always nice to know when someone's spoof'n you.