Checkmk Conference #6: Besser Testen mit 2.0

Auf der Checkmk Konferenz #6 hat Marcel Schulte euch einige Best-Practice-Möglichkeiten für eure eigene Checkmk-Staging-Umgebung vorgestellt. Wir empfehlen euch mit dem Gold Standard und dem Silber Standard zwei Optionen, um neue Updates vor der Einführung in die Produktionsumgebung vorab auszuprobieren.

Der Gold Standard ist für das Testing zwar die präzisere Variante, hat jedoch den Nachteil, dass er sehr ressourcenintensiv ist. Diese Option erfordert es außerdem, dass der Anwender einen Klon seiner produktiven Umgebung erstellt. Das bedeutet, dass es für jede Checkmk-Site ein entsprechendes System in der Testumgebung gibt, das über die gleichen Performance-Daten verfügt. Diese Testmöglichkeit ist also nur realisierbar, wenn der Nutzer über die entsprechenden Hardwareressourcen verfügt. Darüber hinaus muss man beim Gold Standard beachten, dass Checkmk in diesem Fall sowohl die Hosts in der produktiven Umgebung als auch die Hosts in der Testumgebung monitort, sodass man für das doppelte Monitoring nochmal zusätzliche Ressourcen einplanen muss, wie Marcel in seinem Vortrag an dieser Stelle betonte.

Für Anwender, die nicht über ausreichend Ressourcen verfügen, eignet sich hingegen der Silver Standard. Dieser basiert nicht auf einer Kopie der Produktion dar, sondern auf einer Simulation der Daten. Diese Daten lassen sich von einem einzigen System aus abfragen. Dabei kann es sich laut Marcel sowohl um SNMP-basierte als auch um Agent-basierte Hosts handeln. Bei der SNMP-Variante ist es jedoch auch möglich, die simulierten Daten von einem Drittsystem erzeugen zu lassen. Durch die Simulation der Daten ist ein Performance-Test nicht möglich. Hierbei handelt es sich also lediglich um einen Funktionstest, etwa um eigene Entwicklungen auszuprobieren, wie Marcel weiter erklärte.

Die Teilnehmer freuten sich, dass Marcel außerdem eine komplette Anleitung für das Testen und Wechseln von Versionen vorstellte. Viele Fehler lassen sich dadurch vermeiden. Zudem zeigte Marcel, wie man mithilfe von Skripten viele Aufgaben automatisieren kann. Er empfiehlt es jedem Nutzer, sich vor allem mit Major-Releases zeitnah zu beschäftigen und diese einzuführen. Durch die dynamische Entwicklung von Checkmk und den stetig wachsenden Funktionsumfang kann es laut Marcel passieren, dass sich ein Update über mehrere Releases hinweg aufwändiger gestaltet als eine regelmäßige Aktualisierung von Checkmk.

Als Checkmk-Consultant möchte Marcel, dass die User so unabhängig wie möglich sind und am besten überhaupt keine Probleme bei der Nutzung von Checkmk haben. Leider ist die Welt der IT komplex und hält somit immer wieder Herausforderungen bereit, die man nur zusammen meistern kann. Unseren Kunden zu helfen ist seit Januar 2020 die Aufgabe von Walter Fisch als Head of Support. Er erläuterte in seinem anschließenden Vortrag, wie der Kunden-Support in Zukunft einfacher ablaufen soll.

Checkmk 2.0 kommt mit neuer Support-Diagnostik

Er möchte, dass die User im Fall der Fälle möglichst schnell Hilfe bekommen. Dazu gehört unter anderem die Standardisierung unseres Supports. Die Grundlagen hierfür haben wir bereits im letzten Jahr mit der Einführung des Jira Service Desks angestoßen.

Ebenso plant unser er die Einführung einer Knowledge Base, um gerade bei wiederkehrenden Problemen Zeit einzusparen. Die Knowdlege Base soll beispielsweise eine FAQ, How-to-Anleitungen sowie Troubleshooting-Dokumente enthalten. Darüber hinaus wollen wir aber auch existierende Informationen aus unseren Werks und dem Forum einbinden.

Ein besonders wichtiges Element für Walter ist jedoch unsere neue Support-Diagnostik, die wir mit Checkmk 2.0 einführen. Derzeit betreiben wir einen enormen Aufwand, um die Basisinformationen des Kunden, etwa installiertes Betriebssystem etc., zu einem Supportfall zu erhalten. Dies wollen wir künftig automatisiert über ein Standardformat einsammeln und auf diese Weise deutlich einfacher gestalten. Außerdem planen wir die Nachfragen nach zusätzlichen Daten deutlich reduzieren, um schneller mit der Problemlösung starten zu können. Auf der anderen Seite soll es für den Kunden einfacher sein, die Informationen zum Problem in einem Datenpaket zusammenzufügen und diese an das Support-Ticket anzuhängen.

Daten per WATO selektieren

Mit der neuen Support-Diagnostik ist es für den Anwender möglich, über WATO die benötigten Informationen zu generieren. Dazu nutzen wir den Automation Process von WATO, um das Datenpaket der ausgewählten Site als Backgroundjob zu erstellen. Alternativ besteht die Möglichkeit, die Informationen über die CLI zu erstellen. Ein Cleanup Job auf den Sites soll im Nachgang verhindern, dass das dortige File-System mit diesen Diagnosedaten überfüllt wird.

Die erstellten Daten (tar file) leitet Checkmk anschließend nicht automatisch an tribe29 weiter, betonte Walter. Das tar file muss der Kunde oder Partner über eine SSL-Verbindung immer manuell in unser Support-Portal oder bei größeren Datenmengen in unsere Cloud hochladen. Es ist aber auch möglich, dass ein Kunde das tar file an einen Support-Partner übermittelt. Die eingesendeten Diagnosedaten löschen wir wieder, sobald wir das Ticket abgeschlossen haben.

Wir haben uns natürlich für diesen Workflow auch Gedanken zur Sicherheit euer Daten gemacht und einige Sicherheitsaspekte berücksichtigt. So hat nur der Inhaber der Rolle des „cmkadmins“ die Berechtigung, Diagnosedaten zu erstellen und zu lesen. Auch bietet Checkmk eine volle Transparenz über die gesammelten Daten, die sich zudem nur per SSL manuell zu uns übermitteln lassen. Außerdem denken wir darüber nach, wie wir sensible Daten markieren und anschließend maskieren können. Auch eine Verschlüsselung des Datenpakets ziehen wir in Betracht, wie Walter abschließend erzählte.

Bei unserem nächsten Post handelt es sich schon um den letzten Beitrag zu unserer Checkmk Konferenz #6. Darin werdet ihr alles Wichtige über unsere weitere Checkmk-Roadmap erhalten.