-
Notifications
You must be signed in to change notification settings - Fork 0
Logging
Logging in Rebus can be key to understand what is going on and to diagnose problems. Therefore, it is probably a good idea to have some kind of strategy around this, ensuring that logs are properly monitored.
##Configuring it
As mentioned in the description of the Configuration API, logging must be configured as the first thing. This is to ensure that logging is properly set up for the other configurers in case they feel like logging.
A couple of logging options are included in the box, including logging to the console and via System.Diagnostics.Trace. They can be configured like so:
Configure.With(...)
.Logging(l => l.Console())
// etc
in order to set up plain and unsexy console output logging, or
Configure.With(...)
.Logging(l => l.ColoredConsole())
// etc
to add some colors to the console logging. System.Diagnostics.Trace logging can be set up with
Configure.With(...)
.Logging(l => l.Trace())
// etc
whereas logging can be disabled alltogether with
Configure.With(...)
.Logging(l => l.None())
// etc
As default, logging will be colored console logging.
Rebus can use Log4net as well if you include the Rebus.Log4Net package. Then, you can go ahead and do your usual Log4Net configuration, and then you can Rebus-enable it by doing it like this:
Configure.With(...)
.Logging(l => l.Log4Net())
// etc
Because logging is such a vital part of most applications, and logging should be available to all classes if they want it, it's implemented in a special way with Rebus. The way it's implemented allows for all classes, no matter how deep they're located architecturally, to get a hold of a Rebus.Logging.ILog instance by doing this funny thing:
using Rebus.Logging;
class MyClass
{
static ILog log;
static MyClass()
{
RebusLoggerFactory.Changed += f => log = f.GetCurrentClassLogger();
}
}
This thing may look pretty weird at first, but it has several nice properties:
- Allows for logger instances to be specific for each class - the
GetCurrentClassLogger()method may inspect the stack frame and create a logger instance that contains the name of the class. - Allows for the logger instance to be static and shared among class instances, allow for the expensive stack frame inspection to happen only once.
- Allows for all classes to easily log stuff the right way.
This is also how all of Rebus' classes do their logging.
Rebus logs a lot of things, mostly Debug information that is most likely uninteresting in the general case. It can be nice to be able to turn on Debug logging when running on a developer machine though.
Rebus Info logging is more interesting, because it will tell you information on when the bus starts up and shuts down etc. Therefore, e.g. to know that the system shuts down properly, it can be nice to leave Info logging on in your environments.
Warn and Error level logging should always be turned on, because these log levels are reserved for the interesting messages!
One thing should be noted: When your code throws during the handling of messages, it is NOT treated as an error until the message is moved to the service's error queue. I.e., during retries, multiple warnings may be logged, intil the final retry that results in an Error log, whereafter the message is moved out of the way.
Therefore, if you haven't set up monitoring of your error queues, it is probably a good idea to configure your favorite logging library to send a mail to an administrator when there's Error level logs.