Service Failure Alert Email in "QlikView April 2020"
Kein SCOM oder Nagios um den Status der QlikView Services zu überwachen? In QlikView 12.50 gibt es eine Alternative.
Bisher zeigte die QlikView Management Console den aktuellen Service-Status der anderen QlikView Services am Reiter "Service Status Overview" an. Mit QlikView 12.50 kann man sich diese Information aktiv als Email schicken lassen.
 |
| Erkennt das Management Service ein "disconnected" Qlik Service, schickt es ein Email. |
Die Doku dazu ist noch ausständig, aber folgende Informationen haben wir vom Qlik Support erhalten und lokal bei uns getestet:
Um diese Einstellung zu aktivieren, müssen Sie das QlikView Management Service stoppen. Unter C:\Program Files\QlikView\Management Service die QVManagementService.exe.config die folgenden XML-Tags ergänzen:
<add key="ServiceFailureAlertEmailAddresses" value="qlikviewadmins@heldendaten.net"/> <add key="ServiceFailureAlertEmailSubject" value="PROD QlikView Server: [SERVICE-NAME] on URL [SERVICE-URL] is down."/> <add key="ServiceFailureAlertEmailBody" value="PROD QlikView Server: [SERVICE-NAME] on [SERVICE-URL] is down. Go to http://yourserver:4780/QMC/ServiceStatusOverview.htm for details!"/>
Die Tags [SERVICE-NAME] und [SERVICE-URL] sind Platzhalter, und werden dynamisch für das betroffene QlikView Service in das Email eingesetzt.
Das QlikView Management Service nutzt den Mailserver, den Sie in der QMC unter "System/Mail Server" konfiguriert haben. Unter Umständen müssen Sie in der QVManagementService.exe.config auch noch das bestehende Setting von false auf true umstellen:
<add key="UseSSLForSMTP" value="true"/>
 |
| Zeile 5-7 ergänzen. UseSSLForSMTP müsste schon in der .config zu finden sein. |
Wenn Sie nun das QlikView Management Service starten, ist die Überwachung aktiv. Wenn man zum Test den QVS, QVWS, DSC, QDS oder Service Dispatcher Service über services.msc stoppt, sollten Sie folgende Service Failure Email bekommen.
 |
| Service Failure Email: Der QlikView Webserver (QVWS) ist down |
Leider bekommt man keine Email wenn das Service wieder "up" geht. Und natürlich bekommt man keine Fehlermeldung wenn das QlikView Management Service selbst betroffen ist. Deswegen ist eine Überwachung via SCOM, Nagios, SNMP, etc. noch immer zu bevorzugen bzw. zusätzlich zu aktivieren.
Den QlikView Server (und indirekt den QVWS) kann man auch weiterhin regelmäßig über einen http-Request auf diese URL prüfen: http://yourserver/Qvajaxzfc/QvsStatus.aspx. Der Status Up ist gut. Alles andere deutet darauf hin, dass der Server für die Endanwender nicht erreichbar ist (keine Lizenz, Service Down).
 |
| QvsStatus.aspx vom QVWS sagt "Up" wenn QVS gut läuft |
Häufigster Problem mit inresponsive Qlik-Services - gerade bei Single Machine Installationen - ist meist, dass die Datenmenge von QlikView Server (QVS) und Publisher (QDS) gemeinsam den Server ins "Paging" bringen. Es wird mehr Arbeitsspeicher allokiert als auf der Maschine verfügbar.
Der QlikView Server meldet RAM-Ressourcenknappheit für sich selbst (also nur die QVS.exe) in seinem Event-Log unter Severity "Warning" als "WorkingSet" Meldungen. QVS.exe versucht zwar den internen Result-Caches zu leeren, wenn aber weiter neue Applikationen von Endanwendern angefordert werden, geht der Memoryverbrauch sowohl über das definierte WorkingSet Limit Low (default 70) als auch WorkingSet Limit High (default 90).
 |
| QVS hat zuerst nur 1.8 GB WorkingSet Low. Aber auch 24 GB sind zu wenig RAM für seine .qvws. |
Hier listet Microsoft bei "Resource-Exhaustion" die Prozesse mit dem höchsten Memory-Consumption in Bytes. Das ist für gewöhnlich der QVS.exe, oder bei großen Reload-Tasks, die entsprechende qvb.exe des Publishers.
Das Schöne ist, dass man die ProcessID des Events 2004 auch in den TaskLog.txt unter C:\ProgramData\QlikTech\DistributionService\1\Log findet kann. Damit lässt sich das Problemskript des Publishers leicht identifizieren.
 |
| Die ProcessID 7332 ist der Task "RT_Wawi_DatenmodellVertrieb" und belegt knapp 60GB RAM |
Unter Qlik Sense gibt es keine qvb.exe mehr, sondern die Engine.exe übernimmt Endanwender-Anfragen als auch die Reload-Tasks. Entsprechend ist dort die Unterscheidung woher der Ressourcenbedarf kommt schwieriger. Das spricht dafür, dass man auch in Qlik Sense einen eigenen "Scheduling" Server aufsetzt, der die Beladungen übernimmt.
 |
| Engine.exe in Qlik Sense ist QVS.exe und QVB.exe in einem gemeinsamen Prozess. |
