Die 4 goldenen Signale (L.E.T.S.): Monitoring-Goldstandard statt -Ratespiele

Software-Monitoring – wie geht das? 

„Tools haben wir jede Menge angeschafft, wissen aber nicht so recht etwas mit ihnen anzufangen? Aus den tonnenweise Diagrammen werden wir einfach nicht schlau …“

Euch kommen solche oder ähnliche Aussagen rund um Software-Monitoring bekannt vor? Gut, bei den ganzen Zahlen und Statistiken, die dabei auf einen hereinbrechen, gerät das Ganze tatsächlich leicht zur Suche nach der Nadel im Heuhaufen. Selbst bei kuratierten Dashboards ist nicht immer direkt klar, was nun eigentlich relevant ist. Einen ersten Ansatzpunkt hierfür liefet euch "L.E.T.S." bzw. die 4 „goldenen Signale“ : Latenz (Latency), Fehler (Error), Traffic und Sättigung (Saturation). Damit habt ihr gewissermaßen ein universelles Framework an der Hand, das euch Aufschluss über eure Software und Infrastruktur gibt.

Anwendbar ist es nämlich auch weit über Szenarien im Software-Kontext hinaus. Klingt spannend? Sehen wir's uns an!

Vier goldene Signale für (fast) alle Lebenslagen

Gut veranschaulichen lässt sich das Potenzial der goldenen Signale am Beispiel eines fiktiven Restaurants, dessen Inhaber ihr seid: Das Geschäft scheint gut zu laufen, aber ob ihr hier und da nicht etwas verbessern oder etwa auch ein paar Kosten sparen könntet, darüber habt ihr nicht so recht den Überblick. Und leider auch keine handfesten Zahlen. Deshalb überlegt ihr, wo ihr dazu ansetzen solltet. Mit den 4 goldenen Signalen L.E.T.S. wird direkt klar, was dabei wichtig ist:

• Latenz (Latency): Wie lange müssen Gäste warten, bis ihre Bestellung an den Tisch kommt?
• Fehler (Error): Wie oft können wir ein bestimmtes Gericht nicht mehr servieren oder bekommen Reklamationen von Gästen?
• Traffic: Wie viele Gäste kommen zahlenmäßig zu uns (und zu welchen Zeiten)?
• Sättigung (Saturation): Wie viele Bestellungen kann unser Team parallel bearbeiten und an den Tisch bringen?

Diese Kennzahlen können euch allesamt eine fundierte Entscheidungsgrundlage zur Skalierung eures Geschäfts und dazu liefern, mit welchen Auswirkungen bei Anpassungen zu rechnen ist.

Die Latenzwerte etwa verraten euch, ob ihr in Küche und Service mehr Personal oder vielleicht auch eine bessere Ausstattung benötigt.

Über die Fehlerrate lassen sich dabei die (hoffentlich positiven) Effekte von Ausbildungsmaßnahmen, Personalaufstockungen und Investitionen in bessere Ausstattung beurteilen.

Der Traffic wiederum gibt euch Aufschluss darüber, mit wie viel Personal ihr die Zahl eurer Gäste bewältigen könnt, zu welchen Zeiten ihr dabei großzügiger planen müsst und wann ihr auch mit weniger auskommt. So könnt ihr außerdem auch feststellen, ob ihr bereit zum Expandieren seid.

Und anhand der Sättigung lassen sich potenziell bestehende Unzulänglichkeiten bei der Planung und parallelen Zubereitung etwa der besonders beliebten Gerichte sowie weitere Effizienzlücken aufdecken, die ihr bislang vielleicht noch gar nicht erkannt hattet.

Bis zu einem gewissen Grad könnt ihr diese Aspekte als Restaurantinhaber womöglich auch abschätzen. Sicher fahren werdet ihr aber nur, wenn ihr die harten Zahlen erfasst.

Ganz grundsätzlich bilden diese Konzepte den Ausgangspunkt für ein klareres Verständnis komplexer Systeme wie unserem fiktiven Restaurant. Ihr wahres Potenzial zeigt sich aber tatsächlich erst, wenn wir sie auf das Monitoring komplexer Software-Architekturen anwenden.

In Zeiten von Microservices ist es kaum realistisch, dass jemand Fachexperte für ausnahmslos alle Elemente einer Software-Infrastruktur ist. Eben dies lässt sich mit den vier goldenen Signalen als Basis für die Identifikation und Behebung von Problemen in komplexen Systemen wie diesen kompensieren.

Denn über die Metriken Latenz, Fehler, Traffic und Sättigung können auch IT-Analysten ohne tiefergehende Expertise zu einzelnen Services Problemstellungen innerhalb vernetzter Systeme direkt erfassen. Nehmen wir etwa die Folgenden:

• „Eine unserer Datenbanken fällt durch ungewöhnlich hohe Latenz auf. Betreiben wir diese On-Premise oder in der Cloud?“
• „Seit dem letzten Deployment geht die Fehlerrate durch die Decke. Besser, wir nehmen hier einen Rollback vor.“
• „Am Load Balancer ist der Traffic komplett eingebrochen. Ist womöglich unser Zertifikat abgelaufen?“
• „Ungewöhnlich, dass die Sättigung so schnell zunimmt. Wenn das so weitergeht, stößt unsere Speicherkapazität wohl bald an ihre Grenzen.“

Mit diesen Grundstock an Informationen können wir also bereits bekannte Fehlerpunkte ins Auge fassen, noch bevor wir überhaupt tiefer in die Materie eintauchen. Vorausgesetzt, wir ermitteln die passenden Zahlen hierür. Wie das funktioniert, sehen wir uns im Folgenden an.

^{Abbildung 1-1. Ansicht in Splunk APM zu den vier goldenen Signalen im Prozessschritt von der Kasse zur Zahlung am Beispiel eines Online-Shops. Bedenklich hier: 15 % Fehlerrate – ein klarer Anlass für nähere Untersuchungen.}

Vom Konzept zur Umsetzung

Die Eckdaten sind also klar: Wir wollen die vier besagten Metriken ermitteln. Doch wo bekommen wir die her? Unsere erste Station hierfür bildet Distributed Tracing. Denn im Kern geht es dabei um nicht mehr als darum, Latenz, Fehlerrate und Traffic von Anfragen auf ihrem Weg durch ein verteiltes System zu erfassen. Diese Tracing-Daten (auch APM-Daten genannt) müsst ihr nur noch in eine Lösung wie Splunk APM einspeisen, und schon habt ihr die zugehörigen Metriken. Keine große Sache also. Etwas anders verhält es sich mit der Sättigung.

• Führt eure Software besonders rechenintensive Operationen aus, für die konstant hohe CPU-Performance zur Verfügung stehen muss?
• Wie empfindlich reagiert die Software auf die Auslastung des Arbeitsspeichers? Würde sie etwa infolge eines OOM-Cleanup abstürzen und dadurch Ausfälle verursachen?
• Wie sieht es in puncto Storage aus? Besteht das Risiko, dass ein Netzlaufwerk oder womöglich auch eine lokale Festplatte nicht mehr für die Datenbank ausreicht?
• Habt ihr genügend Hosts (Container, VMs etc.), um den gesamten Traffic bewältigen zu können?

Sehr wahrscheinlich werden einige dieser Aspekte nicht unbedingt von besonderer Relevanz für die in eurer Umgebung jeweils ausgeführten Anwendungen sein. Die Einflussfaktoren für Ressourcenauslastung und Sättigung und mit ihnen potenzielle Ursachen für Ausfälle solltet ihr aber dennoch eruieren. Denn so könnt ihr Diagramme auf das Wesentliche reduzieren und Probleme schneller ausmachen und adressieren. Der Punkt ist hier, dass ihr die für eure Umgebung spezifischen „bekannten Bekannten“ kennt, euch also auch direkt auf diese konzentriert, statt euch unnötig an anderer Stelle aufzuhalten.

Eine Antwort: vier Signale

Die Antwort auf die Frage „Wo gilt es, in puncto Monitoring anzusetzen?“ ist also so einfach wie direkt: an den vier goldenen Signalen. Ermitteln sollte ihr Latenz, Fehler und Traffic zwischen Microservices und Rechenzentren, aber genauso auch zwischen einzelnen Software-Komponenten. Wendet ihr diese Methodik auf Microservices von gleichem Infrastruktur-Muster (z. B. JVMs auf EC2 mit DynamoDB, Python-basierte Cloud-Funktionen mit einem Cloud SQL-Datastore oder andere replizierbare Kombinationen) an, könnt ihr dabei auch eure Dashboards klarer strukturieren und zudem Alert-Schwemmen vorbeugen. Die Idee ist hier, dass ihr ein für jede dieser Kategorien separates Dashboard mit Diagrammen zu den ihnen jeweils zugehörigen goldenen Signalen einrichtet. Ergänzt ihr diese Metriken nun um eine Dimension wie den Namen eines Service, könnt ihr das Dashboard einfach nach diesem filtern und so direkt Aufschluss über ein ganzen Verbund an Microservices erhalten. Konzeptionell ganz ähnlich würdet ihr das Thema Alerting angehen, indem ihr die goldenen Signale auf Infrastruktur-Muster anwendet. Doch das wollen wir an dieser Stelle besser noch zurückstellen und später detaillierter beleuchten.

Nächste Schritte

Ganz gleich, ob ihr mit Splunk Observability bereits vertraut seid, die Lösung gerade testet oder euch noch ans Thema Monitoring herantastet: Mit diesen Grundprinzipien nehmt ihr den schnellsten Weg zu einer Observability-Methodik, mit der ihr eure Software und Infrastruktur klarer klarer ausleuchtet und besser versteht.

Ihr habt die Splunk Observability noch nicht in Aktion erlebt? Dann registriert euch am besten direkt hier für eine kostenlose Testversion.

Ganz gleich, ob ihr erfahrene Splunk Observability-Nutzer seid, gerade eure erste Testversion ausprobiert oder euch erst gedanklich mit Monitoring befasst: Wenn ihr diese Grundprinzipien beachtet, werdet ihr sehr schnell mehr Observability bei eurer Software und Infrastruktur erreichen!

Ihr könnt euch noch heute für eine kostenlose Testversion der Splunk Observability Cloud-Produktsuite registrieren!

^{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.}