What is an appropriate way to separate lifecycle events in the logging system?

I have an application with many different parts, it runs on OSGi, so there's the bundle lifecycles, there's a number of message processors and plugin components that all can die, can be started and stopped, have their setup changed etc.

I want a way to get a good picture of the current system status, what components are up, which have problems, how long they have been running for etc. I think that logging, especially in combination with custom appenders (I'm using log4j), is a good part of the solution and does help ad-hoc analysis as well as live monitoring.

Normally, I would classify lifecycle events as INFO level, but what I really want is to have them separate from what else is going on in INFO. I could create my own level, LIFECYCLE.

The lifecycle events happen in various different areas and on various levels in the application hierarchy, also they happen in the same areas as other events that I want to separate them from. I could introduce some common lifecycle management and use that to distinguish the events from others. For instance, all components t开发者_StackOverflowhat have a lifecycle could implement a particular interface and I log by its name.

Are there good examples of how this is done elsewhere? What are considerations?

Have you though about using separate loggers for these events ?

This is the typical way of handling this kind of issue, I think.

This doesn't sound like a log level to me. It is more of a seperate logger hirachy.

The typical logger hierarchy everybody uses is based on the package names. But I recommend to use separate hierarchies, using prefixes. If you prefix class and package name with LIFECYCLE, you can turn these messages on, off or route them to a special place with the standard configuration options of log4j or slf4j or pretty much every reasonable logging framework.

log4 uses the concept of ThreadContext.Stacks["NDC"] (formerly just NDC http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/NDC.html). At each lifecycle event, you push the current context onto the stack, and at the conclusion of that event you pop it off the stack again. Done with care, it can give you a pretty handy trace of where you are in the call sequence with each log entry.

Logging is not the best solution for this. The fact you are talking about custom log levels is a definite design 'smell'.

If you want current status then you need monitoring and on Java this means JMX. Now the fact you're also doing OSGi makes this a bit more complex, though people have been working on this: http://code.google.com/p/maexo/