Following up on previous posts (here and here) about the Butler family of tools being Dockerized, here is another one on the same topic:
Butler SOS can now be run in a Docker container.
This is good news as it makes it a lot easier to set up real-time monitoring of a Qlik Sense enterprise environment, compared to the previous (still working, btw) method of installing Node.js and then running Butler SOS on top of Node.
I recently upgraded our house alarm system to the latest model from Verisure.
Pretty nice actually, the new system comes with a good mobile app, remote querying of both alarm status and status of the various sensors (smoke, movement etc) that are included in the system. Oh, the new system actually cost less per month too, compared to the old one. Go figure.
Being the geek that I am, I immediately wondered if it was possible to get hold of the sensor readings (temperature and humidity) that were shown in the mobile app.
Turns out it is pretty simple. There is a REST API which can be queried, and from there you get back all kinds of status for the system. With that data nicely structured in a JSON it’s then a breeze to send the data to a MQTT pub-sub broker for later use by whatever system that might need it. Easy in theory.
Qlik has made available a video from Anthony Deighton’s (Qlik’s CTO) keynote session.
Very much worth looking through the entire video – it was very interesting indeed. His highlight of customer and partner project’s is found 12 min 36 sec into the video.
A few weeks back something cool happened.
During the big, main stage keynote session at Qlik‘s annual Qonnections conference, my Butler SOS project was highlighted as an example of a great application built on top of the Sense APIs.
I have to admit that it is pretty neat to get that kind of recognition from industry peers… a bit of ego boost :).
And it makes it easier and even more fun to work out coming, similar concepts and services. Lots more to be done around DevOps and Qlik Sense.
Speaking of which:
I started playing around with Qlik’s new Enigma.js library a week or so ago, to see if it could be used in coming projects.
Very nice indeed. Nothing wrong with good old Qsocks, but Enigma is a step in the right direction. Just like qsocks, Enigma is open source – but also fully supported by Qlik. That is a huge advantage!
I got somewhat distracted from the idea of breaking up the existing Butler software into smaller, stand-alone micro services.
Or rather, an idea came to mind. An idea too good not to explore…
The healthcheck API of Qlik Sense provides basic metrics for both the Qlik Sense engine itself, and the server it is running on. Things like CPU load, available RAM, number of connected users and what apps are loaded into the Sense engine.
The idea behind Butler SOS ( SOS = SenseOps Stats) is very simple:
Get the healthcheck metrics for all servers in a Sense cluster. Then send the information to MQTT for immediate, real-time use cases.
It is directly aimed at bringing better features to the monitoring step of SenseOps – please visit SenseOps.rocks for more info on SenseOps.
Butler SOS is nice and sending data via MQTT make the health metrics available in for example Node-RED. Node-RED has some basic graph options, but not anywhere near those offered by Grafana. Grafana is very, very cool… A live demo is available here – do check it out – it is very nice indeed.
Creating real-time dashboards in Grafana is greatly simplified if the data is stored in some kind of time series database. Influxdb is an obvious choice. It is open source, installation is very easy, and there are good Node.js libraries that make it trivial to insert data into a Influxdb database.
Thus – Butler SOS also sends the Sense health metrics to an Influx db of choice.
Only need Influxdb and not MQTT? Or the other way around?
No problem, the Butler SOS config file include options for independently turning on/off sending of data to MQTT and Influxdb.
Using Grafana we get dashboards and charts like these:
Showing CPU load, available RAM, active users, cache hit ratio and more.A 100% cache hit ratio (left y axis) means that no additional calculations were needed to serve the requested data to the client. The yellow dots are associated with the right y axis, which tells us how big the request in question was.
(smoke, movement etc) that are included in the system. Oh, the new system actually cost less per month too, compared to the old one. Go figure.
