Für alle, die mehr aus dem Monitoring-System Checkmk herausholen wollen

E2E Application Monitoring oder: die Quadratur des Kreises

Über die Notwendigkeit, beim Thema Monitoring sprichwörtlich "zu Ende" zu denken.
(Und über das beste Restaurant der Stadt.)

Es passiert.

Nicht oft, aber es passiert immer wieder: Eine unternehmenskritische Applikation (z.B. das SAP-System, CRM-System etc.) funktioniert plötzlich nicht oder nicht richtig. Das sagen zumindest die User.
Oder, auch gern genommen: plötzlich melden sich immer mehr Anwender, dass "schon seit Wochen" alles langsam läuft, heute aber sei es "besonders schlimm".

Du öffnest die Anwendung und stellst tatsächlich fest: damit kann man im Leben nicht arbeiten. Bevor Du Dich fragen kannst 'Wie konnte das nur passieren?' steht Dein Chef hinter Dir und fragt: "...haben wir für genau solche Fälle nicht ein Monitoring...?"

Aber es gibt doch ein Monitoring?

Ja, Ihr habt ein Monitoring. Und dort schaust Du nach. Aber unter Hunderten von Monitoring-Checks ist nicht einer dabei, der einen Hinweis liefern könnte, was da gerade schief läuft: alle sind OK und grün. Das Telefon steht jetzt nicht mehr still. Was zum Teufel geht da vor?

Liegt es etwa daran, dass Du immer noch zu wenige Monitoring-Checks hast? Wohl eher nicht.

Die "Heilige Kuh"

Ich möchte mit Dir jetzt eine "Heilige Kuh" schlachten.

Die "Heilige Kuh" der Annahme, dass "mehr, mehr, mehr Checks" am Ende so etwas wie "umfassendes" Monitoring ergeben.

Es ist eine Illusion, eine gefühlte Sicherheit.

Der Reihe nach. 

Bevor das Schlachtfest beginnt, lohnt es sich, dass wir uns kurz das sog. OSI-Schichtenmodell anhand eines einfachen Beispiels in Erinnerung rufen. Einer der rudimentärsten Monitoring-Checks ist der ICMP-Ping. Er prüft, ob ein Zielhost imstande ist, eine ICMP-Antwort zu senden. Die Aufforderung dazu verschickt der Monitoring-Server als ICMP-Paket von seiner IP-Adresse (Schicht 3) an die IP des Zielssystems (ebenfalls Schicht 3). Dieses verschickt ein dazu passendes Antwortpaket.

Man kann sagen: Absender und Empfänger haben sich auf einer Ebene, nämlich Schicht 3 unterhalten.

Alleine über das Wunderwerk, was mit dem Paket auf seiner Reise durch Schicht 2, 1, das Übertragungsmedium und dann wieder durch Schicht 1, 2 bis 3 des Zielsystems passiert, ließen sich viele Seiten schreiben. Es würde Dich aber langweilen - und Du bist damit übrigens in bester Gesellschaft: auch Checkmk ist es herzlich egal, was im Detail mit dem Paket passiert.

Ziehen wir lieber den Vergleich zu einem Kurierfahrer, um zu sehen, was mit dem Paket passiert: 

Schicht

Kuriersendung

ICMP-Ping

Vermittlung (3)

Ermittlung der schnellsten Route zwischen Start- und Zielanschrift

IP-Routing zwischen beiden Systemen

Cell

Auflösung beider Anschriften in Geokoordinaten

MAC-Adressen beider Systeme

Sicherung (2)

Kurierfirma schickt ggf. Ersatzfahrzeug bei Motorschaden, weil es die Zustellung zwischen zwei Koordinaten garantiert hat

erneute Übermittlung der Pakete zwischen den MAC-Adressen

Bitübertragung (1)

Der Kurierfahrer weiß, dass er statt des Autos ggf. ein Boot verwenden muss, wenn der Empfänger auf einer Insel wohnt

das Paket kann ggf. auch über WLAN zugestellt werden

Aus einem erfolgreichen ICMP-Ping auf Schicht 3 lassen sich jetzt genau drei Schlüsse ziehen:

Header

Kuriersendung

ICMP-Ping

Hypothese (rot)

vielleicht ist der Empfänger auch per Telefon/E-Mail zu erreichen

vielleicht kann der Zielhost seine Aufgabe (z.B. als Webserver) ausführen

Metrik (grün)

Bis zur Zustellung vergingen X Stunden

Zeit bis zum Erhalt der ICMP-Antwort

Beweis (hellgrün)

Zum Empfänger führt ein Weg 

Der Host ist "online" 

Netzwerk-Kommunikation verläuft übrigens immer zwischen gleichen Schichten. 

Für ein zweites Beispiel klettern wir ein paar Stufen höher auf Schicht 7: wenn Checkmk einen Zielhost mit einem FTP-Check prüft, dann läuft das Paket von Schicht 7 (= dem FTP-Plugin) durch alle Schichten nach unten und beim Zielhost wieder durch alle Schichten nach oben zu Schicht 7, wo der FTP-Server (hoffentlich) arbeitet.

Die fehlerfreie Kommunikation auf Schicht 7 haben wir als Metrik, weshalb sie grün dargestellt ist. Hellgrün sind die Schichten darunter, deren Funktion immerhin bewiesen ist. Nicht im Bild zu sehen ist die Hypothese (rot): wir werden auf diesem Server vielleicht, vielleicht auch nicht, etwas uploaden können:

Auch Dein Monitoring hat ganz sicher Checks auf mehreren OSI-Schichten. Wichtig hierbei zu wissen: sie beginnen immer unten auf Schicht 3. Das ist quasi die "Bodenplatte" Deines Monitorings. Bodenplatte deshalb, weil Du die zu überwachenden Hosts ja mit einer Adresse auf Layer 3 (IP) anlegst und nicht etwa mit einer MAC-Adresse (Layer 2). Nach oben reichen "die Hände" Deines Monitorings noch bis zur Schicht 7 und prüfen z.B. Datenbankverbindungen, HTTP-Schnittstellen usw. 

Schicht im Schacht

in der Anwendungsschicht

Beim Namen der Schicht 7, der "Anwendungsschicht", könnte man jetzt leicht auf die Idee kommen, dass genau dort auch die Anwendungen liegen, mit denen die User arbeiten.

Das ist aber nicht der Fall

Schicht 7 ist lediglich die Ein- und Ausgabeschnittstelle zu den Anwendungen und diese setzen darauf auf. Das wird leider oft durcheinandergebracht. 

Angesichts der Tatsache, dass das erweiterte OSI-Modell auf Schicht 8 den Menschen bzw. Anwender definiert, müssen wir uns die Schicht der Anwendungen also denken ("Schicht S") und ihr die Farbe "dunkelrot" (Hypothese) geben. Wir kennen die Voraussetzungen für diese Schicht (alles bis Schicht 7) - aber nicht ihren Zustand selbst!

Auf Schicht 7 ist übrigens bei allen herkömmlichen (wenn man das so schreiben darf) Monitoringsystemen   - völlig wertfrei gemeint - sprichwörtlich "Schicht im Schacht".

Monitoring ist kein Selbstzweck

Um was geht es in Deinem Job? 

Sind Paketlaufzeiten oder Datenbank-Tablespaces wirklich das, woran Du gemessen wirst? Machst Du Deinen Job wirklich schon deshalb gut, weil Du für ausreichend Festplattenplatz sorgst und alle Server mit Updates versorgst?

Monitoring ist kein Selbstzweck. 

Wenn Deine IT Dienste und Applikationen für Anwender bereitstellt, dann ist Deine einzige Bestimmung ein zufriedener Anwender (Schicht 8 im OSI-Modell):

Vom Ziel einer optimalen "Enduser-Experience" mit Deiner erbrachten Dienstleistung leiten sich alle Deine Monitoring-Maßnahmen ab. An dieser Skala wird IT gemessen und Feedback darüber gegeben.

An dieser Skala wird Deine Arbeit beurteilt.

Innen hui, außen pfui

Stellen wir uns eine bereitgestellte Applikation als Kreis vor und die rote Fläche darin als das, was vom Monitoring nicht erfasst wird.

Mit Monitoring-Checks bis Schicht 7 ist die Überwachung dieser Applikation ungefähr wie die Quadratur des Kreises; es gelingt nicht, die roten Flächen am Rand zu eliminieren:

Um es noch einmal hervorzuheben: Deine Anwender...

  • ...benutzen keine TCP-Ports
  • ...bearbeiten Daten sicher nicht mit SQL-Queries
  • ...sprechen nicht mit REST-APIs

Das einzige, womit Anwender in Berührung kommen, ist der hartnäckig rot bleibende Randbereich, die "Schicht S". Diese Schicht wird immer unter - nein, besser: über Deinem Monitoring-Radar fliegen, solange Du keine Checks hast, die über Schicht 7 hinausgehen:

Mit Monitoring bis Schicht 7 bleiben also nach wie vor unentdeckt:

  • Dienstgüte/Performance extern gehosteter Anwendungen
  • allmähliche Verschlechterungen von Start- und Ladezeiten
  • scheinbar zufällige Programmabstürze
  • Anzeigefehler
  • Probleme in Prozessketten
  • veraltete Daten
  • usw.

Wie belastbar ist die Hypothese, dass Software funktioniert, wenn man sie nicht direkt überwacht?

Exkurs:
das beste Restaurant der Stadt

Eine kleine Analogie dazu: stell Dir vor, Du besitzt ein Restaurant.

Was würdest Du unternehmen, damit Die Gäste Dein Lokal weiterempfehlen?

Ganz klar ist: Du musst regelmäßig nachzählen, wie viele Eier noch im Kühlschrank sind. Du musst Stabkerzen nachbestellen, bevor sie zuneige gehen und immer genügend frische Tischtücher auf Vorrat haben, damit Du nach jedem Gast sofort neu eindecken kannst. Und natürlich musst Du kontrollieren, wie sich Dein Umsatz zum Reingewinn verhält und ob letzterer groß genug ist, um Dich weiter zu ernähren. All das sind messbare Größen.

Aber... hast Du nicht etwas wichtiges vergessen, damit Gäste Dein Lokal auch wirklich weiterempfehlen?

  • Hast Du denn mitbekommen, dass seit Einstellung des neuen Koches die Gäste viel länger auf Ihren Hauptgang warten? Es dauert von Abend zu Abend länger.
  • Ist Dir bekannt, dass die neu bestellten Stabkerzen nach nur fünf Minuten anfangen, zu tropfen?
  • Weißt Du davon, dass seit letzter Woche das Fenster an Tisch 1 defekt ist und es dort zieht wie im Hasenstall?
  • Ist Dir klar, dass Dein Kellner gestern das Steak versehentlich im Suppentopf serviert und dazu in bester Absicht auch noch einen "Bernhardiner" statt "Burgunder" empfohlen hat?

Das genau ist der Grund, warum es Restauranttester gibt.

Restauranttester beurteilen das Lokal nicht aus Deiner Sicht als Besitzer, der des Kochs oder des Kellners. Sondern aus der des kritischen Gastes, der Dein Lokal nur dann weiterempfielt, wenn dutzende, wenn nicht hunderte Komponenten perfekt zusammengespielt haben.

Du hast nicht die Zeit und schon gar nicht die Objektivität, um Gast in Deinem eigenen Lokal zu sein. Deshalb stellst Du jemanden als Tester an, der Dein Lokal auch noch beim X-ten Besuch zuverlässig, unvoreingenommen und objektiv bewerten kann. Aus der immer wiederkehrenden Bewertung entsteht eine Meßreihe, welche die Qualität, oder in anderen Worten, die "End-User-Experience" Deines Lokals über die Zeit abbildet.

An dieser Meßreihe kannst Du als Restaurantbesitzer ablesen, ob Du in oberster Liga spielst und ob Deine Gäste einen perfekten Abend haben, mit allem, was dazugehört.

End2End-Tests

End2End-Tests...

... sind die Antwort auf die Frage nach dem "Restauranttester" in der Informatik. Ein Testframework führt dabei automatisiert immer wieder die gleichen praxisbezogenen Testschritte in einer Applikation aus, z.B.

  • Öffne Browser
  • Login
  • Klicke Button für "Auftragsmanagement"
  • Prüfe Datum der letzten Aktualisierung
  • Öffne Übersicht Stammdaten
  • Logout

End2End-Monitoring

ist die konsequent weitergedachte Überwachung der

letzten und wichtigsten Ebene

zwischen Mensch und Maschine. 

End2End-Monitoring...

  • ... ist die ideale Ergänzung zur leistungsfähigen Monitoringlösung Checkmk.
  • ... überwacht das reibungslose Ineinandergreifen von Technologien und Funktionsketten
  • ... schafft durch standortübergreifende Tests und Auswertungen (z.B. SLA-Reports) klare Diskussions- und Entscheidungsgrundlagen.
  • ... ist ein Frühwarnsystem für den Applikationsbetrieb. Proaktives Beseitigen aufkommender Probleme erhöht die Verfügbarkeit und sichert das Image und Vertrauen in die IT.

Chris.

Chris H. überwacht heute die Performance seiner wichtigsten Business-Applikationen (Microsoft Dynamics/SAP-GUI/Online-Shop) mit Robot Framework und Checkmk.
Dank E2E-Tests erfährt er heute aus erster Hand, wenn es Fehlfunktionen oder Performance-Engpässe im Software-Stack gibt:

Er hatte sich auf dieser Seite (die Du eben liest) einen der Termine für ein kostenloses Erstgespräch mit mir geholt. Anhand seiner Angaben im Anmeldeformular wusste ich bereits im Vorfeld, dass sein Hauptproblem die scheinbar schwankende Performance der zentral gehosteten Anwendungen an den bundesweit verteilten Standorten war. Er hatte den Beschwerden der Anwender darüber jedoch nie etwas stichhaltiges entgegnen können, denn die relevanten Checks von Bandbreite, Serverlast etc. waren immer im grünen Bereich geblieben.

Das Gespräch brachte ihm Gewissheit, dass End2End-Tests in diesem Fall das richtige Mittel sind, um die Problemlage richtig einschätzen zu können. Schon am nächsten Tag skizzierten wir gemeinsam die Anforderungen für einen POC. (In einem solchen "Proof of Concept" liegt der Fokus darauf, die technische Machbarkeit einer Aufgabe zu beweisen; alle zum Beweis unnötigen Details werden dabei ausgelassen.)

Der POC brachte Chris zwei wichtige Erkenntnisse, nämlich dass

  • mit RobotFramework die Enduser-Experience "da draußen" an allen Standorten messbar und belegbar sein wird
  • mit dem Checkmk-Modul RobotMK die Planung und Konfiguration solcher Robot-Tests leicht und auch für seine Kollegen nachvollziehbar von der Hand geht.

Meine Best-Practice-Tipps zu Checkmk, RobotMK und Robot Framework halfen Chris, typische Anfängerfehler zu vermeiden.

Er entwickelt und pflegt heute alle Robot-Tests selbständig.

Von einem

kostenlosen Erstgespräch

profitierst auch Du.

Über den Button hast Du die Möglichkeit, direkt einen Termin zu buchen, in dem wir gemeinsam über "End2End-Monitoring mit Robot Framework und Checkmk" sprechen werden:

Details zu Deinem kostenlosen Erstgespräch

Du profitierst gleich mehrfach:

  • Ich kann Deine Situation beurteilen und Dir sagen, ob und wie E2E-Tests mit Robot in Deinem Fall helfen, die Lücke im Applikations-Monitoring optimal zu schließen. 
  • Greif zurück auf meine Erfahrung in den Bereichen Monitoring (>15 Jahre) und Testautomatisierung (7 Jahre).
  • Ich bin der Autor des Checkmk-Moduls "RobotMK", welches das Bindeglied zwischen Robot Framework und Checkmk darstellt.
    Die Besonderheit dieses Moduls ist, dass es nicht nur die Testergebnisse komplett und nahtlos in Checkmk integriert, sondern auch eine granulare Ausführungs-Planung hierüber erlaubt.
    RobotMK ist für Checkmk die bislang einzige, im Open-Source-Bereich allgemein mit Sicherheit die fortschrittlichste Integration eines Testframeworks in ein Monitoringsystem.

Eines meiner wertvollsten Learnings ist: "Geh, so weit Du schauen kannst. Von dort siehst Du weiter."

Das ist mein Motto und Manifest, mit dem ich meinen Kunden dazu verhelfe, schneller andere Standpunkte einzunehmen, von wo aus sie selbst wieder neue eigene Entscheidungen treffen können. 

So kann es (nicht) weitergehen.

Dass Du diese Seite nun fast bis zum Ende gelesen hast, freut mich. :-)

Denn es zeigt mir, dass Dir der Content gefallen hat und Dir klar geworden ist, warum der Zustand der wichtigsten Schicht in Deiner IT nicht einer Hypothese überlassen werden darf, sondern aktiv überwacht werden muss. 

Die besten Monitoring-Tools dafür sind sogar noch Open-Source ! 

Damit ist die erste "Hausaufgabe" quasi schon abgehakt, denn nur an dieses Verständnis, wo (und vor allem: warum) diese Lücke genau klafft kann angeknüpft werden. Lass uns im Erstgespräch darüber unterhalten, wie Du mit Robot Framework und RobotMK das Beste aus Deinem Checkmk-Monitoring machen kannst.

Das Gespräch ist selbstverständlich unverbindlich; ob eine evtl. Zusammenarbeit Sinn macht, oder Du Deinen ganz eigenen Weg mit diesen Tools gehst, liegt bei Dir.  

Nach vorn uniform.

Sicher interessiert Dich, warum ich mich auf Robot Framework als Testwerkzeug spezialisiert habe (zumal ich in grauer Vorzeit selbst ein inzwischen längst abgekündigtes Testframework erschaffen habe, hüstel ). 

Applikationen kommen und gehen immer schneller - und mit ihnen auch die Technologien dafür. Wer hier zum Testen jeweils ein eigenes Pferd sattelt, hat am Ende mit einem Zoo an Formaten zu kämpfen, die alle auf ihre Weise ins Monitoring integriert werden müssen.

So etwas kostet dann richtig Zeit und Geld und macht keinen Spaß.

Das agnostische Testwerkzeug Robot Framework ist wie eine Hülle um verschiedenste, quelloffene Testbibliotheken, die von einer äußerst aktiven, weltweit präsenten Community gepflegt und erweitert werden. Nach vorne (in der Auswertung) zeigt sich Robot trotzdem stets uniform.
Pferdestärken inclusive.

Die Termine in meinem Kalender werden je nach meiner sonstigen Verfügbarkeit angezeigt und sind deshalb von Woche zu Woche verschieden. Auch für Dich ist vielleicht noch ein passender dabei - schau bitte nach und sichere Dir einen Slot.

Und wenn Du zu denen gehörst, denen es nicht schnell genug gehen kann: zwischen dem Erstgespräch und einer evtl. Implemtierung eines POCs vergehen i.d.R. nicht mehr als ein paar Werktage.

Es liegt nun an Dir, ob Du den blinden Fleck der Software-Schicht" weiter nur mit Monitoring-Checks einkreist - oder das volle Potential aus Checkmk herausholen und Monitoring "zu Ende" denken willst.

Wäre es nicht schön, irgendwann hier zu sein?

Erinnerst Du Dich an mein Zitat von eben? 
        "...von dort aus siehst Du weiter."

Wir hören uns - bis bald,

P.S.: Als aufmerksamer Leser wirst Du Dich fragen, warum ich Schicht 8 zuletzt auch grün gefärbt habe, was ja eigentlich für die Garantie der unteren Schichten steht. Ja, wir können über die Zufriedenheit des Anwenders zwar nur eine Hypothese (rot) treffen.
Aber wir betrachten hier nur unseren Verantwortungs- und Einflussbereich und nicht auch den des Software Developers. Wir gehen also vom Idealzustand einer gut programmierten Anwendung aus. Wenn diese in guter Infrastruktur läuft, muss und wird das zufriedene User zur Folge haben.

Copyright 2020, Impressum - Datenschutzerklärung

>