ActiveMQ User Reference

I've been working with ActiveMQ now for over 1.5 years and as I learn more about this great open source product, I jot down what I have learned in this reference. I hope you find it useful and that it can help you successfully deploy ActiveMQ. Click here to download the pdf.

A Monitoring Framework For ActiveMQ

I am currently working on a monitoring framework for ActiveMQ that I call "AMon". It essentially allows you to define your Monitor components (I refer to them as Monlets) and inject them into the message broker. AMon is heavily dependent on Camel and the Java implementation of the UEL (JUEL) to make things easier for the Monlet developer. Also looking into designing a SNMP Agent and MIB for ActiveMQ and allow the Monlets to generate traps. I hope to have AMon ready by 2Q09. Here's a snippet from the user guide that I am working on.

AMon is a monitoring framework that is specifically designed for the ActiveMQ message broker. On its own, AMon does not do the actual monitoring of an ActiveMQ message broker. What AMon provides is a framework that facilitates the rapid development and deployment of one or more monitor components (Monlets). These Monlets, which are deployed directly onto an ActiveMQ message broker, do the actual monitoring of the message broker.

A Monlet is an end-user defined component that comprises one or more conditional statements and the actions that are invoked if and when those conditions test positive. In general, the conditions test the runtime or operational state of those objects that comprise the ActiveMQ message broker.

Unlike ActiveMQ’s advisory system, AMon gives the Monlets direct access to the message broker’s object hierarchies. The broker comprises many objects and properties; therefore, there are also many conditions that can be defined. Here are just a couple of examples of the types of Monlets and the objects that they can monitor.

1. Resource Monlet – one that tests whether a particular resource (memory, queue, etc) has reached a certain threshold and fires off an email or JMS message to another process if that threshold is reached.

2. Audit Monlet – one that tests whether a message that is being routed through the broker meets some sort of condition (e.g., includes some user-defined property that has been assigned a particular value) and if the condition is met the contents of the message can be dumped to an audit log.

AMon also allows Monlets to test conditions associated with the broker’s hosting Java Virtual Machine (JVM). For example, a Monlet can test whether the number of active threads within the JVM or its memory heap size has reached a certain threshold.

AMon maintains a clean separation between the Monlets and the broker objects that they are monitoring. This separation is provided by a combination of the following:

1. Event messages that are published by the AMon core component or engine
2. AMon’s default monitoring expression language (MEL)
3. The Apache Camel integration framework’s routing Domain Specific Language (DSL).

The above items combine to make developing Monlets relatively easy and allows the AMon system to be extensible and flexible.