Teil 6: Qualität messen können

Was die Qualität von Websystemen ausmacht: Prüfbarkeit

Daniel Takai

© Shutterstock.com/LuckyN

Software besteht aus dem reinsten Werkstoff: unseren Gedanken. Aus diesem Grund ist sie unsichtbar, und wir müssen Anstrengungen unternehmen, um sie fassbar zu machen. In der Architektur gibt es hierfür zwei Qualitätsmerkmale: die Analysierbarkeit und die Prüfbarkeit. Die Analyse wird für die Entwicklung und Dokumentation des Systems benötigt. Die Prüfbarkeit hingegen findet zur Laufzeit statt. In diesem Artikel wird die Prüfbarkeit beschrieben, nachdem sich der letzte Artikel bereits mit der Analysierbarkeit beschäftigte.

Die Prüfbarkeit beschreibt den Grad an Immanenz, den ein System zur Laufzeit aufweist. Je besser die Prüfbarkeit, desto leichter ist es, Daten über ein System zu sammeln und auszuwerten. Die systematische Beobachtung von Komponenten nennt man Monitoring. Monitoring ist schwierig und kann nur mit speziellen Monitoringsystemen durchgeführt werden. Die Implementierung und der Betrieb dieser Systeme kosten, und Ausgaben in dieser Richtung haben bei den meisten Stakeholdern, insbesondere den Sponsoren zu Beginn eines Projekts, nur selten hohe Priorität. Dabei ist Monitoring aus verschiedenen Gründen wichtig:

  • Ausfälle eines Systems sollen im Betrieb frühzeitig, falls möglich bereits vor dem Ausfall (proaktiv), erkannt werden können, zum Beispiel bevor die Festplatte vollläuft.
  • Erkenntnisse über das Systemverhalten sollen gesammelt werden, damit notwendige Änderungen an der Architektur erkannt werden können. Vor allem Performance und Kapazität können so dem tatsächlichen Bedarf angepasst werden.
  • Die Geschäftszielerreichung eines Systems soll messbar gemacht werden, beispielsweise um den Nutzen einer Investition nachzuweisen.
  • Die Erfüllung von Service Level Agreements (SLAs) kann bewiesen werden.
  • Intrusion-Detection-Systeme können für den Zugriffsschutz eingesetzt werden.

Monitoring besteht aus der Messung der Zustandsänderungen und Datenflüsse in einem System. Zustandsänderungen können direkt gemessen werden. Datenflüsse zwischen Komponenten werden per Logeintrag gemessen [1]. Ein Monitoringsystem weist die gleichen Qualitätsmerkmale auf wie jedes andere System. Monitoringsysteme für Websysteme sind selbst auch Websysteme.

Terminologie

Im Monitoring wird eine spezielle Terminologie verwendet, die wir klären möchten. Eine Messung ist ein einzelnes Datum, in der Regel ein numerischer Wert. In Kombination mit einer Messgröße (oder Messeinheit) entsteht eine Metrik. Eine oder mehrere Metriken bilden einen Indikator. Die Messfrequenz gibt an, wie häufig etwas gemessen wird. Die Perspektive beschreibt, von wo aus gemessen wird. Es ist besonders bei Latenzmessungen von Websystemen ein großer Unterschied, ob ich auf dem Server selbst oder von einem anderen Kontinent aus messe. Die Interpretation einer Metrik, die zu einer Erkenntnis führt, heißt Insight.

Die für ein System geschäftlichen relevanten Indikatoren heißen Key-Performance-Indikatoren (KPI). Für die Komponenten eines Systems lassen sich Service-Level-Indikatoren definieren (SLI) und mit etwas Erfahrung Service Level Targets (SLT), also gewünschtes Minimum und Maximum eines SLIs. Zu einem SLI gehört eine exakte Definition der Metriken, der Messfrequenz sowie der Perspektive. In einem Service Level Agreement (SLA) können SLIs und SLTs vertraglich festgelegt werden. Oft enthält ein SLA auch Strafen, falls die SLTs nicht eingehalten werden. Da während der Entwicklung eines Systems noch keine Daten über den Produktivbetrieb vorliegen, kann die vertragliche Verankerung von vernünftigen SLAs im Vorfeld schwierig sein. Deswegen sollten SLAs, die Strafen enthalten, auf der Grundlage von handfesten Daten geschlossen werden. Denken Sie auch daran, dass die Messungen und Zusammenstellung der Indikatoren für den Nachweis der Einhaltung aufwändig sein können.

Klassifikation

Nach dem Standard ISO/IEC 25010 ist die Prüfbarkeit (engl. Inspectability) ein Teil der Analysierbarkeit. Im Standard werden Prüfbarkeit und Analysierbarkeit zusammengefasst. Die in diesem Artikel rund um die Prüfbarkeit diskutierten Konzepte zeigt Abbildung 1. Stefan Toth hat in seinem Buch [2] die Qualitätsszenarien nach Akzeptanzkriterien, Qualitätsgeschichten und allgemeinen Merkern klassifiziert. Die Prüfbarkeit generiert in erster Linie einen allgemeinen Merker, dass Prüfbarkeit hergestellt werden muss oder nicht. Falls dies der Fall ist, erzeugen Diskussion um Prüfbarkeit im Weiteren dann konkrete Akzeptanzkriterien, und zwar hauptsächlich im Betrieb und im Marketing. Siehe hierzu die Beispiele für Qualitätsszenarien am Ende des Artikels.

Abb. 1: Konzepte rund um die Prüfbarkeit

Abb. 1: Konzepte rund um die Prüfbarkeit

Architektur für Prüfbarkeit

In unserer Architektur gibt es das System, das geprüft wird, sowie das Monitoringsystem, das das System prüft (Abb. 2). Betrachten wir nun zuerst das System, das beobachtet wird. Wenn sich das System nicht beobachten lässt, dann hat das System einen permanenten Katzenzustand, aber glücklicherweise lässt sich jedes System beobachten, sonst könnten wir es nicht entwickeln. Bei Websystemen ist die Beobachtung besonders einfach, da sie stets HTTP unterstützen. Der Abruf einer Seite per HTTP lässt bereits rudimentäre Aussagen über das System zu (Antwort hat die richtige Payload, Antwort ist schnell oder langsam), es kann jedoch keine Aussage darüber gemacht werden, warum beispielsweise die falsche Payload ausgeliefert wird oder warum das System nur langsam antwortet. Hierfür muss der interne Zustand des Systems per Introspektion gemessen werden. Die Schnittstelle, die das leistet, nennt man im Allgemeinen „Health Check“. Manchmal heißt sie auch „Software Probes“. Die Anfrage des Monitoringsystems, ob noch alles in Ordnung ist, heißt „Health Check Query“. Die häufigste Anwendung stammt hier vom Loadbalancer, der alle 5 Sekunden eine solche Query absetzt, und bei negativem Bescheid den entsprechenden Knoten aus der Lastverteilung rausnimmt. Eine eingehende Diskussion von Lastverteilung und Skalierbarkeit wird es in einem späteren Artikel geben.

Somit ist klar, dass solch ein Health Check nicht viele Ressourcen verbrauchen darf, aber gleichzeitig die wichtigen Parameter der Anwendung kommunizieren muss. Für das Design dieser Schnittstelle zu Gunsten der Prüfbarkeit ist also Zeit zu reservieren.

Abb. 2: Architektur für Prüfbarkeit und Monitoring

Abb. 2: Architektur für Prüfbarkeit und Monitoring

Im Artikel über Testbarkeit wurde ein eigener Port zur Messung des internen Zustands für den Test Harness besprochen. Dieser lässt sich auch für die Beobachtung zur Laufzeit einsetzen. Es gibt hier aber vor allem Bedenken in Bezug auf die Sicherheit, da dieser Port zumeist generisch ausgelegt ist und den breiten Zugriff auch auf sensible Daten erlaubt. Wenn das System sensible Daten speichert, werden Probleme auftreten, den für das Testing bestimmten Port auch auf Produktion für das Monitoring einzusetzen. Der Vorteil eines solchen Ports ist aber seine Generizität, da man sich nicht zu Beginn auf die Metriken festlegen muss, die man messen möchte. Auf der anderen Seite möchte man eben diese Metriken genau definieren, um ein funktionierendes Monitoring planen und herstellen zu können. Wenn man hier agil vorgeht und Entwicklung und Betrieb die Evolution des Monitorings gemeinsam begleiten, kann man sich guten Ergebnissen schrittweise annähern. Für die Beobachtung von Zustandsänderungen eignen sich unter anderem die folgenden Technologien:

  • Für Anwendungen auf der JVM eignet sich JMX-Technologie [1], die flexibel für die Beobachtung beliebiger Metriken eingesetzt werden kann. Hierfür wird jedoch ein Monitoringsystem benötigt, das JMX spricht, z. B. Zabbix, eine quelloffene Monitoringlösung mit guter Visualisierung der beobachteten Metriken. Code muss hier für die Erzeugung von Metriken via MBeans geschrieben werden.
  • Für alle Anwendungen eignet sich zudem eine REST-Schnittstelle, die die jeweiligen Metriken exportiert. Es kann sich lohnen, hierfür ein eigenes Modul zu entwerfen, das sich harmonisch in die Authentifizierungsinfrastruktur einpasst, wenn viele Komponenten auf demselben Technologiestack funktionieren. Für das Monitoringsystem ist REST mitunter besser geeignet, da man dann für die Beobachtung flexibler und einfacher eigene Werkzeuge bauen kann, zum Beispiel mit Kibana oder Grafana.
  • Eine weitere Möglichkeit ist das Monitoring der JVM durch Instrumentierung des Java-Codes. Der Java-Agent von New Relic beispielsweise verwendet Bytecode-Instrumentierung auf Basis des ASM-BCI-Frameworks zur Laufzeit. Der Hersteller spricht von Performanceeinbußen von 5 Prozent beim Einsatz.
  • Für die Beobachtung von Datenflüssen werden Logs eingesetzt, d. h. unser System muss diese Logs selbst erzeugen und dem Monitoringsystem zukommen lassen. Es bietet sich an, dieses direkt zu tun. Splunk bietet beispielsweise für die Java-Entwicklung verschiedene Appender für die Nachrichtenübermittlung. Der ELK-Stack ist ein weiteres Beispiel.

Damit haben wir die technischen Rahmenbedingungen besprochen, sind aber bei der Architektur unseres Systems noch nicht weiter. Hierfür lassen sich die folgenden Erkenntnisse festhalten:

  • Je kleiner und einfacher der Service, desto besser ist seine Prüfbarkeit, da nur wenige und einfache Metriken exportiert werden müssen.
  • Eine SOA- oder Microservices-Architektur ist schwieriger prüfbar als ein Monolith, da Metriken aggregiert und im Kontext ausgewertet werden müssen.
  • Cloud-Elastizität senkt die Prüfbarkeit, da die dynamische Allokation von Ressourcen auch im Monitoring nachvollzogen werden muss.
  • Continuous Deployment senkt die Prüfbarkeit, da für die Dauer eines Deployments der Datenfluss vom System versiegt.

Eine Erkenntnis für die Entwicklung ist die Entwicklung von Richtlinien für das Logging. Zum einen sollte das Logformat über alle Komponenten hinweg möglichst konsistent sein, damit Nachrichten von einem Drittsystem besser verarbeitet werden können. Zum anderen sollten sinnvolle Dinge geloggt werden, und sinnvolle Dinge sind aussagekräftige und korrelierbare Nachrichten. Hierfür können Logevents typisiert werden. Im Artikel über konzeptionelle Integrität wurde der Einsatz eines Contentmodells besprochen. Sie können dieses Modell auch als Grundlage für Logevents nehmen, damit aussagekräftige Berichte erstellt werden können. Cockcroft nennt den Einsatz eines Modells als förderlich für die Erkennung von Abhängigkeiten.

Tatsächlich bietet es sich an, die Generierung von Events an die Use Cases des Systems zu koppeln, um aussagekräftige Indikatoren genieren zu können. Limoncelli [3] behauptet (nicht ganz im Ernst), dass es für E-Commerce-Websites nur eine einzige Metrik braucht, nämlich den Umsatz einer Maschine pro Zeiteinheit. Sobald der sinkt, ist etwas nicht in Ordnung, und die Maschine muss entsorgt werden.

Architektur für Monitoring

Unser System wird sich nicht selbst beobachten können, sodass ein weiteres System für die Beobachtung zum Einsatz kommen muss. Hierfür gibt es eine breite Palette an vorhandenen Werkzeugen. Unter Umständen ist es sogar nötig, ein Monitoringsystem selbst herzustellen. Adrian Cockroft hat hierfür sechs Regeln aufgestellt, die das Monitoring und die Architektur des Monitoringsystems beeinflussen:

  • Verbringe mehr Zeit mit dem Schreiben von Code für die Analyse der Bedeutung von Metriken, als mit Code, der Metriken sammelt, speichert oder anzeigt.
  • Reduziere die Messfrequenz von Latenzen auf weniger als die menschliche Aufmerksamkeitsspanne von 10 s.
  • Achte darauf, dass dein Messsystem ausreichend akkurat und präzise ist. Sammle Histogramme der Antwortzeiten.
  • Monitoringsysteme müssen eine höhere Verfügbarkeit und Skalierbarkeit als das System aufweisen, das beobachtet wird.
  • Optimiere für die Beobachtung von verteilten, flüchtigen, Cloud-basierten, containerisierten Microservices.
  • Passe die Metriken in Modelle ein, um Abhängigkeiten zu erkennen.

Limoncelli skizziert eine Schichtenarchitektur eines Monitoringsystems, die in Abbildung 3 dargestellt ist. Für jede Schicht gibt es heute Open-Source-Bibliotheken, aus denen sich auch selbst ein System konstruieren lässt, wenn man über die entsprechenden Mittel verfügt.

Abb. 3: Bausteine eines Monitoringsystems

Abb. 3: Bausteine eines Monitoringsystems

Wesentlich für ein Monitoringsystem ist die Sammlung von Logs, da hier große Mengen von Daten anfallen können. Werkzeuge wie Splunk, das durch ausgezeichnete Visualisierungsmöglichkeiten verfügt, werden beispielsweise nach verarbeiteten Lognachrichten lizenziert. Das Logmanagement sollte wohlüberlegt sein, denn es fallen bisweilen sehr große Datenmengen an. Leicht kommt es zu Konflikten zwischen geforderter Aufbewahrungszeit (Retention) und vorhandenem Speicherplatz. Datenaggregation ist möglich, führt aber zum Verlust der Originaldaten, sodass sich viele Dinge später nicht mehr auswerten lassen. Besser man stellt sich die Frage, ob die Fehlermeldungen aus dem letzten Quartal überhaupt relevant sind. Die Monitoringziele sind schnell erreicht, und wenn dies der Fall ist, dann kann man die Daten entsorgen.

Standardmetriken und Verfahren

Die gängigen Metriken fallen für Websysteme in zwei Kategorien. So gibt es zum einen maschinennahe Metriken, die per Default von den gängigen Monitoringlösungen gesammelt und ausgewertet werden. Beispiele für maschinennahe Metriken sind:

  • CPU: Rechenlast
  • Memory: Speicherauslastung
  • Network: Netzwerklast
  • IOPS: Datenträgerlast
  • Anzahl Prozesse

Die andere Gruppe von Metriken sind solche, die die Webanwendung selbst beobachten. Die Grenze zu Web Analytics ist hier fließend (siehe unten). Im Folgenden ein paar Beispiele für Metriken, die per Browser gemessen werden können:

  • Start rendering: Wie lange dauert es, bis der Browser anfängt zu rendern? Dies wird beispielsweise durch das Laden von JavaScript beeinflusst.
  • Document complete: Wie lange dauert es, bis das Dokument vollständig angezeigt wird?
  • Above the fold: Wie lange dauert es, bis der für den Benutzer sichtbare Bereich fertig gerendert ist?
  • Synthetic monitoring: Aus entfernter Perspektive wird Benutzerverhalten simuliert und die Antwortzeiten gemessen. Oft werden hier ganze Anwendungsfälle durchgespielt, um gleichzeitig eine Funktionsprüfung durchzuführen.
  • RUM: Beim Real User Monitoring (RUM) wird auf dem Browser des Benutzers selbst gemessen und die Ergebnisse zurückgespielt. Dies verschlechtert die Performance auf dem Client, aber nicht unbedingt in einem Bereich, der bemerkbar wäre. Die ermittelten Daten können sehr wertvoll sein, da präzise und genau gemessen werden kann.

Tritt eine Störung ein, so löst das Monitoringsystem einen Alert (oder Alarm) aus. Ein Alert wird ausgelöst, wenn entweder eine Metrik oder ein Indikator einen bestimmten Schwellwert über- oder unterschreitet. Ein Alert muss dann im Monitoringsystem manuell abgeschaltet werden. Geschieht dies nicht innerhalb einer bestimmten Zeitspanne, so wird der Alert eskaliert. Gute Monitoringsysteme haben ein Escalation-Feature, das in einem solchen Fall den Fallback auf den nächsten definierten Mitarbeiter zulässt.

Monitorig am Beispiel

Abbildung 4 zeigt ein Beispiel für ein Monitoringsystem, das die gängigen Techniken illustriert. Das zu prüfende System ist in blau dargestellt und wird von Nagios (bewährte und teilweise quelloffene Lösung für das Infrastrukturmonitoring) und New Relic (proprietärer Monitoring-SaaS mit zielgruppenspezifischen Schwerpunkten von Kapazitätsplanung bis Geschäftsanalyse) beobachtet. Nagios wertet dabei die Metriken der Infrastruktur aus und New Relic die Performance und Kapazität. New Relic wird eingesetzt, da per JVM-Instrumentierung problematische Requests bequem auf dem Stack Trace durchgeklickt werden können.

Interessant ist nun, was passiert, wenn ein Alarm anschlägt. Dies kann entweder bei Nagios oder New Relic der Fall sein. Beide Systeme erzeugen dann ein Ticket im JIRA-System, das niemandem zugeordnet wird. Die Erzeugung des Tickets löst jedoch eine Nachricht an PagerDuty aus, eine SaaS-Lösung für das Incident-Management. Im PagerDuty wird ein Pikett-Plan gepflegt, sodass das System weiß, wem es nun eine SMS schicken muss. Leider ist das Mobile des Kollegen aus dem Service aber nicht in Betrieb, sodass kein manuelles Acknowledgement innerhalb von 10 Minuten im PagerDuty stattfindet. In diesem Fall greift die konfigurierte Eskalation, und PagerDuty schickt an die nächste Person eine SMS. Diese ist sogar vor Ort und bearbeitet den Case zügig.

Abb. 4: Beispiel für Monitoring

Abb. 4: Beispiel für Monitoring

Klassischerweise testen Unit Tests nur eine einzige Klasse oder Prozedur. In der Integrationsentwicklung macht das nur begrenzt Sinn, da unsere Einheiten sehr eng miteinander verbunden sind und selbst wenig Logik enthalten. Da ServiceMix im Wesentlichen aus Camel [1] besteht, verstehen wir unter einem Unit Test hier, dass eine Route die richtige Antwort bei gegebener Eingabe liefert. Dabei wird die Fixture der Tests mittels Mocks, Stubs oder Fakes aufgesetzt, die wir per Spring konfigurieren [2]. Für unser Beispiel möchten wir eine einfache Route.

Web Analytics

In Abbildung 4 ist für die Webanalyse der Adobe Tag Manager integriert worden. Tag Manager sind in der Webanalyse der letzte Schrei, da sie eine dynamische Integration von Analysesystemen beinhalten. Hierfür muss man wissen, dass internationale Unternehmen gerne eine Vielzahl von Webanalysesystemen einsetzen, um die Bedürfnisse der Marketers organisatorisch besser handhaben zu können. In Südamerika sind nunmal andere Tools hip als in Asia Pacific. Der Tag Manager injiziert dabei zur Laufzeit JavaScript in die Website, das wiederum die für das vorliegende Tag relevanten Systeme mit Daten versorgt. Gut beraten ist, wer den Fertigungsprozess dieses JavaScripts mit Qualitätssicherung ausstattet.

Um den Umfang dieses Artikels nicht zu sprengen, verzichte ich auf die Diskussion weiterer Werkzeuge in diesem Bereich, möchte aber jedem Architekten eine genaue Betrachtung der gewünschten Webanalysewerkzeuge aus Gründen der Qualität ans Herz legen. Besonders empfehlenswert ist eine ROI-Diskussion, denn damit die Berichte wertvoll sein können, muss regelmäßig Zeit investiert werden. Die automatische Generierung von aussagekräftigen Dashboards ist hier aufgrund der volatilen Anforderungen oft nicht möglich, weswegen die Daten „von Hand“ ausgewertet werden. Dies ist günstiger, als Software zu schreiben, und zugleich wertvoller, da die Auswertung von einem Data Scientist gemacht werden kann, und nicht von jemandem der „nur“ gut JavaScript programmieren kann (siehe hierzu auch die erste Regel von Cockroft). Für die Auswertung bietet sich der Einsatz von R aus Gründen der Effizienz an.

Beispiele von Qualitätsszenarien

Die folgenden Qualitätsszenarien eignen sich für die Kommunikation zwischen Betrieb, Architekt und Fach:

  • Zur Laufzeit des Systems werden die einzelnen Schritte der implementierten Anwendungsfälle geloggt und vom Monitoringsystem ausgelesen.
  • Während der Laufzeit kann ein Systemingenieur die Messpunkte in der Dokumentation nachvollziehen und findet hier auch Angaben zu deren Konfiguration.
  • Während der Laufzeit kann ein Systemingenieur die kritischen Systemparameter zu I/O, CPU und Plattenplatz der eingesetzten Maschinen beobachten.
  • Zur Laufzeit alarmiert das Monitoringsystem den Systemingenieur proaktiv, falls CPU, I/O oder verwendeter Plattenplatz über 80 Prozent steigt.
  • Die vom Monitoringsystem erzeugten Alarme sind actionable, d. h.ein Systemingenieur kann für jeden Alarm, den das Monitoringsystem erzeugt, eine Dokumentation mit Handlungsanweisungen im Wiki finden.
  • Während der Entwicklung des Monitoringsystems werden minimale und maximale Schwellwerte, u. a. für Alarme definiert und dokumentiert.
  • Zur Laufzeit sammelt das Monitoringsystem an zentraler Stelle Logs.
  • Zur Laufzeit kann vom gesamten Team ein Health-Check-Monitor eingesehen werden, der den aktuellen Zustand des Systems transparent darstellt.
  • Während der Entwicklung unterliegen Quelltexte und Konfigurationen für das Monitoringsystem derselben Source Control wie die anderen Quellen des Projekts.
  • Während der Entwicklung werden für das Monitoringsystem automatische Tests entwickelt.
  • Wenn eine neue Version des Systems ausgespielt wird, dürfen die Alarme für die betroffenen Systeme nicht anschlagen.

Fazit

Aussagekräftige Berichte und Insights, die helfen, eine Website substanziell zu verbessern, sorgen für Begeisterung. Und wer ein geschäftskritisches System betreibt, der kommt um gutes Monitoring sowieso nicht herum. Über die Jahre ist aus der Beobachtung von Infrastrukturparametern ein komplexes Feedbackökosystem zur integrierten Echtzeitoptimierung von Websites geworden. Die Möglichkeiten, die SaaS-Lösungen wie New Relic heute bieten, waren vor wenigen Jahren nur internationalen Großkonzernen vorbehalten. Auf der anderen Seite lauern hier versteckte Kosten, da die Integration allfälliger Optimierungsschlaufen Aufwände nach sich zieht. Gehen Sie also besser nicht davon aus, dass es nur bei den Lizenzkosten bleibt, aber rechnen Sie damit, dass diese stetig steigen werden. Insgesamt ist der Markt für Monitoring- und Analytics-Lösungen stark in Bewegung, und die Zukunft gehört den SaaS-Lösungen. Verkompliziert wird das Ganze durch Aspekte des Datenschutzes. Ist die IP-Adresse ein persönliches Datum oder nicht? Gilt die Safe-Harbor-Bewertung der USA oder nicht? Das kann ich nicht beantworten, aber eines ist sicher: Der Markt dreht schneller als die Judikative.

Aufmacherbild: Pop Art illustration of girl with the speech bubble. von Shutterstock.com / Urheberrecht: LuckyN

Geschrieben von
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: