Qlik Sense is very much my go-to tool for many data related questions. It’s very powerful to be able to throw together a proof of concept or test a hypothesis in half an hour. Seeing is however believing, so those prototypes does need some polishing before they can be seen as production grade.
I have always pushed my peers in the Qlikosphere to become better at using icons for their Qlik Sense apps in general, and also for the sheets within those apps. Having an icon for a sheet within an app makes it way easier for the user to find a particular sheet – humans are visual by nature.
The basics are the same, i.e. one-click creation of Qlik Sense apps, using regular Sense apps as templates. Several new features however take the tool to a new level, making it easier to set up, manage and more enterprise grade. Good news thus!
Docker is one of those tools that have the potential to fundamentally transform how you develop and run software – once you have tried Docker it is hard to imagine going back to something else.
In previous posts we have seen how Butler, Butler SOS and Butler CW can be run as Docker containers.
But we can do even better – why not control all the Butler tools from a single docker-compose file? Maybe even specifying the dependencies on influxdb and mqtt in there too?
Setting this up is incredibly easy – a single docker-compose file tells Docker what containers to use, and some config files tells the Butler tools where to find things.
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.
Before the summer the Butler tool turned two years old – time flies!
Over those years I have installed, tweaked and upgraded a fair number of Butler instances… Not a problem per se, but maintaining a production grade Butler instance does assume a certain level of experience around Node.js, Linux, networking etc.
The most recent Butler version (v2.2) attempts to make it easier to deploy and operate Butler. This is achieved by deploying Butler as a Docker container instead of a regular Node.js app.
The Docker image (from which a container is created) contains exactly the same Node.js app that you can run right on your server or laptop – i.e. there is no functional difference what so ever between running the Node app natively, and running it as a Docker container.
There are some significant benefits of running Butler under Docker:
This one is long overdue, but finally here: Butler SOS v2.0
The new version is an almost complete re-write of v1.0. Changes are plentiful and include
All warnings and errors stored by Sense in its log database are now pulled into Butler SOS, from where it can be graphed and acted upon. This is a big deal, as it was previously not possible to get notifications or alerts when errors or warnings started to pile up in the logs.
Operational health metrics are still pulled from Qlik Sense, but this is now done directly from the QIX engine rather than via a hard-to-secure virtual proxy.
Using certificates for authentication with Sense removes potential security issues with v1.0.
Config file is now YAML instead of JSON. More human readable and with inline comments.
Config file now allows for more fine-grained control of Butler SOS.
Several bugs fixed, especially around sending metrics to MQTT.
The readme file on GitHub has all the details, here are some screen shots to get you started though:
When relying on various Node.js services (e.g. Butler SOS, Butler, App Duplicator etc), you quickly run into the challenge to ensure all services are always up and running.
A failing service might be fine, as long as it is quickly restarted in a predictable way.
A concrete example could be Qlik Sense or QlikView apps that send status messages to Slack during the execution of their reload scripts. Those messages will fail if Butler is for some reason not running.
This leads us to the conclusion that the services must automatically be
a) started when a server is rebooted, and
b) restarted if they for some reason terminate/die.
Enter process monitors.
At their core, process monitors ensure that the desired processes are always running, i.e. bullet b) above. Some process monitors also offer additional features such as zero-downtime restart of services, memory and performance profiling of the monitored services, being able to monitor different kinds of processes (not only Node.js ditto).
Adding to the pain is the fact that Sense and QlikView runs on Windows servers, meaning that all those great tools available on Linux cannot be used.
Looking at Node.js specifially, I have found two process monitors to work well on Windows: Forever and PM2.