Saturday, April 26, 2008

Not Dash Bored

I love dashboards. You probably got that from my previous post. If I had enough screens, I would be surrounded by dashboards of all kinds: work tasks lists, continuous integration server control panel, project metrics sites and server monitors.

Maybe this comes from the time when I was handling another kind of dashboard, from which my life was directly depending!

(Yes, I am a pre-glass cockpit flying dinosaur)

Dashboards are great because they present a synthetic view of a situation in a form that is visually expressive and does not require a lot of concentrated attention to capture relevant and crucial information.

The most recent dashboard I built exposes particular aspects of several instances of Mule ESB I have under my control. Through JMX, Mule exposes a wealth of statistics about the different components of a particular instance. Here is a small portion of the HTML console that displays this information:

This is too much information the brain, or at least my brain, can digest efficiently and quickly enough. Hence I created a simplified view that represents the variations of message routing statistics on a selection of components:

The components are simply selected by name: I decided to prefix the important ones with "process" and "dispatch" and derived from there a simple selection pattern. I use different colors to show different states:
  • Green: no activity,
  • Yellow: at least one message went through,
  • Orange: the backing event queue has been resized up,
  • Red: an error has been routed,
  • Gray: no delta available (first call of the dashboard),
  • Black: component statistics unavailable.
Extra symbols represent a non active state of a component, like paused or stopped. The dashboard itself is the aggregation (frames, yuck!) of the HTML output of a specific component deployed alongside the other ones.

Of course, this does not compare to the professional grade monitoring tools you can buy from MuleSource, but is already handy for deployments of limited scope and criticality.

I think the most interesting aspect of this dashboard is how quickly you can develop the ability to recognize a normal behavior pattern from a faulty one. It is pretty much like reading the matrix undecoded... Now how could you get bored from such a board!

UPDATE 03-MAY-2008: This dashboard is now available on MuleForge.


Perrine said...

Hello David,

If you have dashboards in html pages, then you may have some automatic monitoring scripts which get and scan these html pages for specific indicators and may trigger some warnings or alerts.
No need to watch every time so many dashboards ;-)
Don't apply this in your plane, too risky. :-))

David Dossot said...

The target audience for this particular dashboard is human beings, not monitoring software.

Monitoring should be done at JMX level, where a wealth of instantaneous information sources is available.

Ross Mason said...

Nice job David, this looks pretty useful and better than the bombardment of all the stats Mule gives you.

Ross Mason said...

Perrine, Mule has a Rich JMX interface that can be used for 'machine monitoring'. Also, Mule Enterprise has a rich monitoring product MuleHQ which gives users a rich cross-platform view of the runtime and allows alerts to be set.

John Vogel said...

Hi, David:

It looks interesting but I couldn't get this to work. When I tried the short version with no model I got an exception every time.

When I tried the long version where I specified a model I didn't get an exception but the contents of the web page were always "null".

I'm using Mule 1.4.3 (not embedded and not synchronous if that makes any difference).

Thanks for the interesting work though,

David Dossot said...

Hi John,

Thanks for your interest in this little tool.

Strangely enough, I am running the dashboard in similar conditions (non-synchronous, non-embedded Mule instances) and it works fine.

Do you get any error? Can you please file a JIRA with configuration files and stack trace? If no stack trace is showing then could you attach the server log file while running at debug level?


John Vogel said...

Oops, sorry, I'm using Mule 1.4.4


John Vogel said...

Wow, I need your new Mule book, David! :)

I'm a Mule newbie and confused.

Order seems to matter. When I put the Dashboard descriptor ~after~ the stock quote descriptor it finds the modelName just fine.

But now the link returns "Firefox can't establish a connection to the server at"

I've put print statements in the dashboard code to follow along and it appears that OnCall is never called even though the test cases do so just fine.

Oh well, it's a learning exercise primarily.

David Dossot said...

Strange again: order should not matter.

Have you tried using "localhost" instead of "" in Firefox?

Feel free to e-mail me your configuration if you need further help.

And yes, please, buy the book ;-)

Mahadev said...

Hello .. Please could guide me how do I start using this HTMLdashboard?

Thanks !

David Dossot said...

The dashboard is pretty old, it runs for Mule 1.4 and 2.2. It has not be tested with 3.x. What version of Mule are you using? MMC is a better option, especially if you use Mule EE.

Nikolay Guselnikov said...

David, Where can I see the source code of the extension? What internal Mule API you use? Thanks

David Dossot said...

Here is the source code: (for Mule 2).

It's using the statistics API.