views:

73

answers:

3

So, I was talking with a guy the other day about Enterprise Library Logging Application Block and log4net.

Something I noticed was that log4net claims: log4net is not reliable. It is a best-effort and fail-stop logging system.

Surprisingly, I was trying to find out if the Enterprise Library logging is "reliable". This is all I can find where the word "reliable" is explicitly used. (note that it is from the 2004 version)

So, this got me curious, what exactly is "reliable" logging? If anyone knows if Enterprise Library Logging application block is reliable (in the current version), can they please point me towards some documentation that says this explicitly?

Thanks.

A: 

I suppose "reliable" means that a message, once sent, is guaranteed to be delivered or physically written to an end device.

Knuckles
A: 

From the look of it, "reliable" means the message always gets logged. log4net apparently tries to do the logging, but if it can't, it will just fail and let the app keep going.

cHao
@cHao Yea, that is exactly what I was thinking. It is making me curious what kind of logging frameworks are truly "reliable." My assumption would be that in order for it to be truly reliable it couldn't just be a framework, it would have to be much larger.
Adam
+1  A: 

Most logging libraries, such as log4net and Enterprise Library, choose to swallow exceptions that might be thrown during the logging process, to prevent the application from stopping. Because of this those libraries cannot be called 'reliable' (according to the log4net documentation).

In my opinion, failing to log an event is a serious failure and should not be swept under the carpet. Missing log messages could be abused by hackers to hide their tracks or at least does it make it much harder to found the root cause of a problem.

For me this was one of the reasons to build a logging library called CuttingEdge.Logging. The logging providers in CuttingEdge.Logging will always throw an exception when an event could not be logged. By configuring a ‘fallback provider’ for a certain logger, users can prevent exceptions from bubbling up the call stack and let the fallback provider log the original message and the exception thrown by the failing logger. Fallback providers themselves can also have a fallback provider configured.This mechanism makes it very unlikely that exceptions won't get logged when using CuttingEdge.Logging.

Steven