I've made a simple active alarm table that is supposed to hold important system faults, see ( http://jira.jboss.com/jira/browse/JBAS-2220) so you can go to a single mbean and find out important facts for a server.

The table is fed by either simple JMX notifications, or special AlarmNotifications that include also the notion of severity and state (see http://jira.jboss.com/jira/browse/JBAS-2219)

Now, I'm trying to feed the table with information.

There is a simple MemoryMonitor service that produces stateful alarm notifications, and has configurable warning and critical levels.

There is also a generic scripting facility (see http://jira.jboss.com/jira/browse/JBAS-2221) that can react to notifications or poll mbean attributes and emit alarms or do whatever. I imagine this is something you may want to do add-hoc to an existing system, i.e. quickly throw a script to diagnose a problem or guard for an error condition and take some measures.

However, a major source of errors is the loggging subsystem itself, so I wrote a simple log4j Appender that emits logging events as JMX notifications that can be fed into the table. By configuring the Appender to level WARN and above we can catch a lot of important system errors.

A potential problem with this is a subsystem maybe generating too many of them, so this have to be filtered in the log4j config, and the table itself has a configurable max size limit, but this needs to be seen in practise.

Is it reasonable to include an example config of the table and the log4j appender with 4.0.x, as functionality commented out?

(conf/log4j.xml and deploy/monitoring-service.xml)

Any other comments/suggestions?