February 21, 2014

Using SCOM with Mule ESB

Integrating an ESB platform in your existing infrastructure is crucial to making sure everybody gets along and plays well together.

Mule MMC has some alerts you can configure. But sometimes this is not enough for a support team. I can’t imagine having a large enterprise with all systems emailing/alerting their own alerts. That would become unwieldy and a huge drain to work through all of that noise.

Many enterprises employ Microsoft System Center Operations Manager (SCOM) to help their support staff in monitoring, responding, and being proactive to problems across their entire infrastructure. Getting Mule to work in this playground is very valuable.

Most admins that are fluent with MSFT related technologies aren’t that well versed with Java related technologies (Tomcat, Mule, ActiveMQ and so forth). With these things in mind we feel it is best to leverage things that are already known and play well with others. To solve this problem we recommend using a Mule Custom Agent that will expose the different JMX metrics as JSON, then by using a Powershell script parse/read the JSON and create entries in Windows Event View. There are other avenues you could take to get these metrics in SCOM, but again trying to play well with others lends us to this workflow. Other that are more fluent with MSFT related technologies will feel at home with Powershell and the Event Viewer than most other items.

To expose the different JMS metrics as JSON, we have used Jolokia (see for directions) as a Mule Custom Agent. It has worked well for us in multiple environments with no hassle. Once you have this set up for your Mule standalone server, then the following URLs will help in discerning valuable information:

For the value to use for “<appName>” changes frequently due to snapshot versions and/or timestamps (we use Maven builds). The initial “list” URL is beneficial to parse out the value to use for this field. See the reference code listing for an example function we have used.

If this has value to you, and you use other systems as well, keep in mind that ActiveMQ uses Jolokia as well. This makes it easy to get out Queue and Topic sizes as well.

By Chad Gorshing Mule ESB Share:

4 thoughts on “Using SCOM with Mule ESB

  1. I think there were a few reasons we chose Jolokia.

    – It’s distributed with ActiveMQ these days. It seems like it might be a better holistic solution to monitor the entire integration stack
    – MX4J hasn’t been updated in 9 years now. Jolokia is actively maintained. Due to security implications, this seems like an important factor.
    – Jolokia appears to have a simpler, flexible security configuration in comparison with MX4J:

  2. David Dossot says:

    In my previous comment, the XML bit has been removed. It is:

    1. We actually have the management:jmx-mx4j-adaptor documented in our internal wiki, but I don’t recall why I choose not to use this. Powershell does also have a ConverFrom-XML, so this should work as well.


  3. David Dossot says:

    That’s very cool, great to see some language interrop in action like this :)

    Note that Mule’s has built-in agent that exposes the JMX tree over HTTP. You can use it like this:

    With this in place you can fetch the root of the tree as XML with over: http://localhost:9999?template=identity

    Then you can form URLs towards whatever MBean you want to fetch, always using template=identity to get the XML format. For example: http://localhost:9999/mbean?objectname=java.lang%3Atype%3DRuntime&template=identity

Leave a Reply

Your email address will not be published. Required fields are marked *