Status Dashboard is an awesome node.js monitoring application developed by @obazoud. I recently sent some pull requests to Olivier to improve the IRC plugin and then I though that even if I am always connected to IRC, jabber or whatever, I also have a Terminal opened most of the time. So the question was: How can I get my services status pushed to my laptop in realtime? Socket.IO is the candidate: It does not provide only server and browser modules, there is also the socket.io-client module which can be used in your node runtime, on the client side in exactly the same way you use Socket.IO in your HTML pages. Since Socket.IO is already used in Status Dashboard to push status to the browser, we have the right solution.
I created a simple node.js client application called statusdashboard-client which connect to a status dashboard instance using Socket.IO. Once data is pushed by the server to the client, it is displayed with some basic code colors on the terminal:
It is totally fun to see what we can do without any node.js expertise. I just start looking at it but I already have many ideas, especially for platform monitoring.
I explained in the last articles how I tested the Play Framework, Web sockets and how I integrated all this nice stuff with a real example based on a Service Bus, Web services Notifications, etc…
This time, let’s go one step further. We have a Service Bus which is Web service notification enabled like last time. We can bind services to the bus, expose service endpoints as Web services, blahblahblah… But, this time, I am interested on having some real time monitoring of service invocations. It means that each time a message goes through the service bus (a service invocation in fact), I want to know (almmost) immediatly the service response time.
Hopefuly, the PetalsLink Distributed Service Bus I develop and use provides many extension points. One is the capability to add modules to the routing engine ie the software module each message must be able to go through on service request and response. So adding some router module which catch all the messages, timestamp them and then send this monitoring data to someone is quite easy. At the implementation level, this monitoring router module publishes monitoring reports to the service bus notification engine topic dedicated to monitoring stuff.
The high level architecture of the system can be defined as
Oh, I forgot to say something: This took me 2 or 3 hours to create all this stuff… The code has been published on github in the dsbmanager-webapp project.
In one of my previous posts (Adding Registry Listener in PEtALS), I spoke about adding a registry listener in PEtALS ESB. In the current article, I want to introduce how I used this feature to implement a live monitoring Web application.
Here are the different modules which are used in this Live Monitoring Tool :
PEtALS ESB. The standard behaviour has been customized by adding a registry listener and a routing module (to be detailled below).
Monitoring layer. This layer is an independant process which embeds a WS-Notification engine.
A WS-notification subscriber. This is the module which will receive the notifications from the monitoring layer.
GWT based Web application used to display monitoring data.
PEtALS ESB Extensions
The role of the registry listener is to register a new monitoring endpoint into the monitoring layer when a new endpoint is available within PEtALS.
Since modules can be added dynamically inside the PEtALS message router, we have created a module which timestamp the messages. Once the message exchange is complete, a message exchange report is sent to the monitoring layer.
The monitoring is in charge of creating monitoring endpoints through a management API. Once a monitoring endpoint is created, it is also exposed as a Web service. This newly created Web service exposes a WS-notification subscribe operation.
Another role of the monitoring layer is to receive raw reports from the PEtALS ESB, to process the report in order to generate a WSDM payload which will be send to subscribers.
The subscriber subscribes, receives and stores notifications from the Monitoring layer. That’s all for that module ;o)
GWT Based Web application
The GWT Web application uses comet in order to display live service response time. The data used to display response time is the one received and stored into the database and of course the server part of the Web application have access to this database.
As a result, we have a really nice live Web application (live means that the chart gives real time result and is updated automatically when messages are exchanged within PEtALS Service Bus). Here are some screenshots :