C# Creating a log system

Question

Hello,

I was reading the following article: http://odetocode.com/articles/294.aspx

This article raised me a lot of question regarding logs. (I don’t know if I should have made this in separated questions… but I don’t want to spam stackoverflow.com with questions of mine)

The 1st one is if I should store it in a .txt, or .xml file… or even in a table inside the database. Probably saving in the .txt will be better regarding performance. But when someone needs to find something the .txt file, it may become a pain in the... neck. So… which one should I use, and why?

The second one, is there any specific class to deal with “log” thing? I have read several threads about this subject, and I didn’t find the answers to my questions.

Thanks in advance.

Answer 1

Regarding file vs database, it's up to you to choose.

File logs give greater performance but with pain of access.

If the logs are there just to rarely provide information (e.g. the app crashes and you need to know why), you're better off storing the logs in a file.

If you want to give access to those logs, analyze them, etc, you should store them in a database.

.net is really not my zone, but there are lots of reasons why you should use the framework's logging classes.

Answer 2

The easiest approach I've taken in the past is using log4net. That way you can configure the logging in the config file. If you need it to go to a database, set it up as such. If you want to be notified when a major error occurs, set it up that way.

As far as sorting through the logs, it really depends on the approach you want to take, and how much you plan on logging. Normally I log to a flat text file as I don't enable a lot of logging in my applications. So parsing through them isn't a big deal.

Answer 3

Unless you want to write a system for education purposes, I honestly think that you'd be best off sticking with log4net or nlog.

And further, you would probably be better off studying the code to those systems instead of writing your own.

As to your question, I would stick to a text file and buffer the messages before spitting them to disk.

Answer 4

Why bother inventing wheel? you can check MS enterprise library Logging Block.

Answer 5

definitely not xml.

with xml, you will need to read it all, parse it, add whatever, then generate the whole xml again, and write it back to hard disk. every single time you log something.

unless of course you append the nodes to the xml file manually, in which way you loose most of xml advantages.

warnings to fatal errors - whatever will help you to debug the application if it crashes - those logs i would store in a txt file. append a new line for every entry.

this way you can also ask from your user to check it out (if you assist him via the phone).

if it's not a meta log, such as mentioned above, in other words, if it's anything related to the program itself you may need to analyze - keep on the db.

Answer 6

For my apps I have chosen to write to db. Its easier (for me) to read the logs this way. However I do not go log crazy as some people do, I only log what I need to log and nothing else.

I gave log4net a shot not to long ago and did not like it at all. It was a whole lot of junk to just write to a db and send an email. I ended up writing a custom logging class and it was a whole ~200 lines and took just a few hours. It works great, I don't have another dependency, and it can be easily changed.

Answer 7

NLog and log4net both provide a rich logging API but neither addresses the challanges you face managing and analyzing all the data in your log files.

If you're willing to consider a commerical tool, take a look at GIBRLATAR - it works with NLog and log4net and also collects useful performance metrics. Most importantly, GIBRALTAR provides great tools for managing and analyzing logs.

Answer 8

If you're dealing with ASP.NET, ELMAH is another good logging tool. It's apparently what Microsoft's Scott Hanselman uses.

It does need some additional code to get it to work with ASP.NET MVC's HandleError attribute, though.