"Qlik on Steroids" für Admins - QIX & Audit Log

Mit dem November 2018 Release hat auch QlikView den QIX-Log bekommen. Bisher war das Verhalten der Qlik Engine eine ziemliche Blackbox. Warum und wodurch wieviel RAM benutzt wird, war sehr schwer zu sehen. Mit dem neuen QIX-Log plus einem aktiven Audit Log können Qlik-Administratoren jetzt tief eintauchen und genau sehen was auf ihren Servern so vor sich geht!

Jedes Objekt und Dokument das bestimmte CPU- oder Memory-Grenzen übersteigt wird im QIX Log protokolliert. Auf Basis dieser Daten kann ein Dashboard gebaut werden, welches die teuren Dashboards & Objekte der gesamten Umgebung aufzeigt, und durch welche Userinteraktionen viel Leistung verbraucht wird.

Heldendaten Analyse QIX und Audit Log
Analyse Applikation zum QIX Log

Der QIX Log wird über die settings.ini des QlikView Servers aktiviert. Eine genaue Beschreibung der Felder und Einstellungsmöglichkeiten finden sich in der QIX Perfomance Log Hilfe

In unserem Beispiel haben wir sehr niedrige Grenzen gewählt. Ein QIX Logeintrag entsteht, wenn:

- Warning wenn Object Process Time > 2 Sekunden
- Error wenn Object Process Time > 4 Sekunden
- Warning Peak Memory wenn mehr als ~500 MB
- Error Peak Memory wenn mehr als ~1GB

Diese Parameter müssen Sie entsprechend Ihrer Umgebung anpassen. Bei 2 Sekunden bekommen Sie wahrscheinlich zu viele Warnings.

QlikView Server settings


Im Beispiel sehen wir, dass das Chart CH454 bis zu 763MB für die Berechnung benötigt.

Heldendaten QIX Analyse
Problemobjekte pro Qlik Anwendung


Das allein ist eine interessante Information, die ohne QIX Log am Server bisher nicht ersichtlich war. Noch spannender wird es, wenn man in der QMC den AuditLog aufgedreht hat. Audit Log und QÍX Log lassen sich nämlich über das gemeinsame Feld "SessionId" verschneiden.


Qlik Audit Log
Audit Log in der QMC


Somit sieht man welcher User in welcher Session mit welchen Selektionen das "teure" Chart verursacht hat. Im "QIX Warnings und Errors" Diagramm am Screenshot unterhalb sieht man, dass der User in der Session das Objekt dreimal aufgerufen hat, und es jedes Mal zu einem QIX-Error geführt hat.


Wählt man nun die betroffene SessionId, kann man sich den genauen Verlauf des Problems ansehen.
In unserem Fall sind die Einträge des QIX-Log rot, die Einträge des AuditLog blau.

Man sieht, dass der User  im Feld "Segment_Long_Name_Filter" "Austria" gewählt hat. Darauf hin rechnet das CH454 für 19 Sekunden und verbraucht 464MB RAM. Danach wählt der User im Feld "Month_Filter" den Wert "Jun", das Chart rechnet 34 Sekunden und verbraucht 763MB RAM.

QIX Audit Log Zeitverlauf einer Session
QIX und Audit Log im Zeitverlauf verschnitten

Im rechten Balkendiagramm sieht man auch, dass am Anfang der Session sehr viele Selektionen getroffen werden (Blaue Balken des Audit Logs). Dies sind wahrscheinlich viele initiale Selektionen die in der QlikView App definiert sind. Danach kommen viele QIX-Alarme (rote Balken). In der Applikation dürfte es also mehrere Objekte auf einem Dashboard geben, die viel Rechenleistung benötigen.

Das QlikView Dashboard finden Sie hier.



Für Qlik Sense existiert ein ähnliches Dashboard. Siehe Video unterhalb. Der Download findet sich auf Github.


QIX und Audit Log bilden eine neue Sicht auf die Performance des Qlik Servers. Mit der gewonnenen Information kann der Qlik Administrator gezieht auf die Entwickler des Dashboards zugehen und auf gewisse Objekte aufmerksam machen. Oft können durch einfache Anzeigebedingungen, oder Überarbeitung der Formeln die größten Performancefresser schnell beseitigt werden.
heldendaten GmbH,2017