For years I have thought about ways to get data lineage info for all apps in a Qlik Sense Enterprise environment.
It would be super useful to know exactly what apps use a particular data source, as well as vice versa (what data sources are used by a specific app). I know there are commercial tools doing this and much more, but I wanted something easy to use, yet still effective and free.
Same thing for app load scripts: Extracting and storing them to disk in human readable format has more than once save days of work, when something has gone badly wrong in an app. Dumping load scripts to disk was possible in my original Butler tool, but then only one app at a time. So not quite what was needed in an enterprise context.
The latest version fo Butler SOS is out, taking the version number to 3.0. A lot of the code has been fine tuned to better meet the needs of enterprise grade Qlik Sense deployments.
Docker (or some compatible container platform) is now the preferred and recommended way of running Butler SOS. Butler SOS has been developed and tested on Linux and Mac OS, but should in theory run also other Docker enabled platforms.
Version 3 adds a few – but useful – features:
Per-server config option “serverGroup”. Use this to group or categorize servers, for example as being part of a production vs development Qlik Sense cluster. This enables the creation of Grafana dashboards that use Grafana variables to automatically show metrics for all PRODUCTION servers. This greatly simplifies using Butler SOS in large Qlik Sense environments, where servers are frequently added/removed. No need to manually update the Grafana dashboards any more.
Config option “queryPeriod” for controlling how far back querying for Sense log entries should be done. Used together with the logdb.pollingInterval setting, it is now possible to fine tune how often the Qlik Sense log database is queried for errors and warnings.
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:
I worked out the issue preventing me to add additional nodes to a Qlik Sense Enterprise suystem whose central node had been updated to June 2018.
The June 2018 version of Qlik Sense Enterprise relies on a database called “SenseServices” to be available in the Postgres db (as in earlier versions, Postgres can run on the central node or on some other server).
When running the June 2018 installer on a new server (which is to be added as a new node in a Sense Enterprise cluster), the installer verifies that the SenseServices database exists. If it does not, you get an error half-way through the installer:
Maybe there is info somewhere that you need to create a new “SenseServices” db in Postgress before installing additional Sense nodes… but I looked (a lot) without finding anything.
Qlik’s annual Qonnections conference in Orlando wrapped up yesterday.
Three days packed with the latest from both the Qlikosphere in general and Qlik in particular.
I had more session conflicts (where I wanted to attend several interesting sessions at the same time) than during any previous year, which is a sign of interesting topics, hopefully also of high quality sessions.