This release both adds some nice new features as well as enhancing existing ones and fixing some bugs. Let’s take a look at the highlights.
Track in detail whatapps are loaded into each Sense server.
Regular apps and session apps are handled separately, making app metrics easier to understand and more relevant
Sample dashboards are now built using the brand new, shiny and all together awesome Grafana 7. Did I mention that Grafana 7 is awesome? Awesome.
Ever wondered how long Butler SOS has been running or how much memory it uses? The new uptime messages have you covered.
You are properly impressed with the uptime messages – good. Why not store them to Influxdb, so you can also visualize Butler SOS’ own memory use? It’s just a couple of changes in the config file away.
Better control over what features are enabled. Don’t need Docker health checks? Now you can turn that (and other) feature off.
Ah, you are a serious Sense user and have separate DEV and PROD environments? Good – now Butler SOS supports multiple instances running on a single server.
Who will monitor the monitor? Butler SOS can now send heartbeats to customisable URLs at desired intervals. Perfect if you want to monitor Butler SOS using for example healthchecks.io. Very, very cool actually.
Bugs, bugs and bugs. The known ones have been fixed. Keep reporting new ones!
Update all dependencies to latest versions, to ensure security concerns are adressed.
Curious what it looks like in practice? Seeing is believing:
Usually, yes. Still, things do happen and it certainly would be nice to get an push alert when a server hasn’t checked in according to schedule.
The most common monitoring – for Windows/Linux/…. servers, databases, Qlik Sense etc is based on the tool keeping an eye on some measurement and then alert when the measurement goes beyond some threshold. This is fine, and this is a very important monitoring use case. But in cases where a server just hangs the last measurement received might be fine, and no alerts are sent.
Black box monitoring kind of reverses the roles:
The monitored system has to prove that it’s doing fine. Failing to do so within some predefined schedule will trigger an alarm, with an optional alert being sent.
The previous article showed how this concept can be used to ensure that some Qlik Sense app has reloaded as intended, before a specific time each day. A concrete, common use case would be that yesterday’s data should be processed and loaded into Sense before 7 am next day. Alert if not)
Now, let’s use the same tool and concept to monitor also the Windows servers that Qlik Sense Enterprise on Windows (QSEoW) runs on.
I value this quite high. Being part of the 2016 Luminary program too, I know how much value it brought both in terms of great networking opportunities with fellow Luminaries (and others), as well as more and closer contacts with Qlik themselves.
The one thing that makes Sense stand out (IMHO) is the fact that it is a very solid platform, on top of which you can build all kinds of interesting apps.
Qlik’s own user-facing standard Sense client is great, but there are for sure times when you want something else. The APIs very nicely enable that kind of development.
On the other hand, with so much great work happening in the open source field (around back-end technologies, visualisations etc), it is also extremely promising to see Qlik open sourcing some of their tech.
2017 has indeed started in an interesting way for Sense, can’t wait what’s in store for the rest of the year.