Über unsMediaKontaktImpressum
Martin Gutenbrunner 19. Juli 2016

Monitoring: Das mächtigste Werkzeug für Cloud, Microservices UND Business

Monitoring weckt wohl kaum Frühlingsgefühle bei einem Techniker. Zu lange gibt es das Thema schon und sehr oft wird dabei übersehen, welche Entwicklungen in den letzten Jahren stattgefunden haben.

Für Einsteiger bietet dieser Artikel deshalb einen kurzen Überblick über Vergangenheit, Gegenwart und Zukunft. Für die Erfahreneren gibt es Nostalgie pur und wir blicken etwas über den Tellerrand – z. B. was denn Monitoring für Nicht-Techniker zu bieten hat.

Bei Monitoring geht man oft davon aus, dass die vermeintlichen Neuerungen aktueller Lösungen gar nicht so besonders sind und der versprochene, zusätzliche Wert tatsächlich nicht vorhanden ist. Ich hole an dieser Stelle etwas aus und umreiße kurz das klassische Monitoring, um dann direkt auf die bahnbrechenden Neuerungen der aktuellen Monitoring-Generation einzugehen.

Spoiler: Die aktuelle Generation ist natürlich viel mehr als nur "Monitoring", heißt auch gar nicht mehr "Monitoring", wird aber noch von allen so genannt und ist eigentlich auch immer noch "Monitoring" – aber eben noch viel mehr.

The L in Monitoring stands for Value.

Beim Monitoring – also dem Messen, Beobachten und/oder Überwachen – geht es darum, den aktuellen Zustand von Systemen zu kennen, um auf Probleme so schnell wie möglich reagieren zu können. In der simpelsten Form ist das die Überwachung der Systemmetriken, wie Prozessorlast, Speichernutzung, Netzwerkverkehr, etc. Ganz früher war für jede Aufgabe ein eigener Server vorgesehen. Ein Datenbankserver, ein Anwendungsserver, ein Fileserver, etc. Auf einem Dashboard, das in vielen Iterationen immer wieder verfeinert wurde, wurden die wichtigsten Metriken schließlich noch in ansehnlichen Charts dargestellt.

Ist ein Problem aufgetreten, wurde für jede Überschreitung eine entsprechende E-Mail versandt. Probleme wurden üblicherweise durch vorher fix definierte Warn- und Fehlergrenzen definiert. Der unerfahrene Ops-Kollege ("der für den Betrieb verantwortlich ist") begann dann, sich durch Logs zu graben, der Erfahrene konnte schon anhand der Austastlücke des Röhrenmonitors oder zumindest an den entsprechenden Charts am Dashboard erkennen, wo das Problem lag. Im Normalfall verpackte man alle gesammelten Informationen z. B. in eine E-Mail oder legte ein Ticket an und gab so die Information an das entsprechende Team weiter.

Monitoring war also in erster Linie ein Tool für Ops, das in Kombination mit den richtigen Logfiles den ersten Schritt der Problemanalyse darstellte. Logging ist somit auch schon die perfekte Überleitung vom Ops zum Dev (Software-Engineer/ Entwickler/ Programmierer). Der Entwickler öffnete das Ticket oder die E-Mail, löschte vielleicht noch einige Alarm-Emails, die er zur Sicherheit parallel zum Ops ebenfalls bekam, und machte sich dann (sofort) daran, das Problem in seiner Umgebung nachzustellen. Da wurde dann debugged und herumprobiert, bis das Problem augenscheinlich gelöst war und der Fix zumindest eingecheckt und getestet werden konnte. Von Deployment war damals in diesem Stadium noch keine Rede.

Erfahrene Entwickler sind oft gebrannte Kinder (von da haben sie ja die Erfahrung). Deswegen werden Fehler gern zum Anlass genommen, von nun an eine handvoll neue Log-Einträge zu schreiben. Diese machen dem Ops-Kollegen die Fehlersuche künftig einfacher. Und dem selbstlosen Entwickler erspart es hoffentlich beim nächsten Mal den Weckruf um 3 Uhr morgens.

Die Unterschiede zwischen Entwicklung und Betrieb

Der aufmerksame Leser erkennt an dieser Stelle das Logging als logisches Verbindungsstück zwischen Dev und Ops. Der Entwickler ergreift aktiv Maßnahmen, um ihm eigenes Wissen über Zustände an den Betrieb weiterzugeben und somit beiden das Leben zu erleichtern. Außerdem stellen wir fest, dass die Kollegen vom Ops kein Debugging betreiben.

Die "Einfachkeit" des Loggings

Logfiles sind für Entwickler herrlich einfach zu schreiben. Und das war eigentlich immer schon so. Wahrscheinlich ist die Einfachheit des Loggings der Grund dafür, dass es sich so bald durchgesetzt hat und bis heute nicht verschwunden ist. Ähnlich wie Passwörter. Logging macht aber auch Probleme, vor allem beim Betrieb; also nicht dort, wo sie geschrieben werden. Logfiles sind gemein, da es unheimlich leicht ist, unstrukturierte Daten dort abzulegen.

Der philantrope Entwickler achtet darauf, immer den relevanten Kontext zu liefern, ganz leicht ist der Weg dorthin leider nicht. Das zweite Problem von Logfiles ist der Plural. Sind mehrere Systeme oder Komponenten in ein Problem verwickelt, sind auch die Informationen über mehrere Logfiles verstreut. Gemeinheiten wie unterschiedliche Zeitzonen zwischen den Logfiles ("Einmal UTC und einmal GMT+1, bitte!") erläutere ich nicht näher. Diese zwei Probleme der Logfiles bringen uns nun zur ersten großen Neuerung im Monitoring-Umfeld: Logging-Server.

Ein Elch fürs Logging?

Ein Log-Server speichert Log-Einträge in einer Datenbank und ermöglicht das relativ einfache Filtern, Gruppieren und Abfragen von Einträgen aller Art. Ein sauberer Logging-Kontext ermöglicht es, Informationen in entsprechenden Zeiträumen und von entsprechenden Requests, etc. abzufragen.

Da Dashboards und Charts wundervolle Stilmittel der Visualisierung sind, dauerte es auch nicht lange, bis diese Einzug ins Logging gefunden haben. Wie man Log-Zeilen visualisieren will? Nun, der erste Ansatz war wohl, einfach die Anzahl unterschiedlicher Einträge pro Log-Level darzustellen. Bei einem Webserver bietet sich auch die Anzahl von Response-Codes an.

Der bekannteste Vertreter der Log-Server ist derzeit der sogenannte ELK-Stack, bestehend aus den namensgebenden Komponenten Elasticsearch, Logstash und Kibana. Der ELK-Stack ist – vergleichbar mit anderen Stacks – eine Sammlung von Tools, die gut aufeinander abgestimmt sind. Hier sind das:

  • Logstash stellt die Schnittstelle dar, die Log-Statements entgegennimmt. Für den Entwickler ändert sich im Idealfall gar nichts, weil das Logging-Framework selber die Logs direkt nach Logstash schicken kann, anstatt sie in ein File zu schreiben.
  • Elasticsearch ist die Falle, in der alle Daten abgelegt werden. Im Vergleich zu herkömmlichen, relationalen Datenbanken ist Elasticsearch extrem gut darin, textuelle Daten zu verarbeiten, z. B. mittels Volltextsuche, etc. Darunter fällt auch das Arbeiten mit Log-Einträgen.
  • Kibana ist schließlich das dritte Tool im Bunde und stellt das User Interface und die Visualisierung dar.

Dashboard - Charting allerlei

Mit Kibana als Dashboard liegt der Wunsch nahe, mehr als nur technische Metriken anzuzeigen. Besonders dann, wenn die Techniker den Geschäftsleuten begeistert die Charts zeigen. Was spricht dagegen, auch Umsätze etc. auf Dashboards darzustellen?

Zugegeben, es ist etwas klischeehaft, sich sprichwörtlich im Minutentakt zeigen zu lassen, wie viel Kohle gerade zum Fenster reinkommt. Tatsächlich ist aber die Gegenüberstellung von monetären Größen und technischen Kennzahlen durchaus sinnvoll.

Der Geschäftsführer hat am Log-Server nichts verloren

Ich erteile hier dem Auswerten von Umsätzen, etc. über den Log-Server eine beschränkte Abfuhr. Nicht, weil ich den Dagobert Ducks ihre Charts nicht vergönne, sondern weil der Log-Server (noch?) der falsche Ansatz dafür ist.

Warum? Charts vom Log-Server zeigen normalerweise einen relativ kurzen Zeitraum wie z. B. die letzten 15 Minuten für hochaufgelöste Informationen oder die letzten paar Stunden, wenn es nicht ganz so genau sein muss. Selten fällt mir jedoch ein Fall ein, wo man einen längeren Zeitraum als einen Arbeitstag abdecken muss; zumindest was Live-Daten betrifft.

Geschäftszahlen sind aber speziell dann spannend, wenn sie pro Monat, Quartal oder während eines speziellen Ereignisses wie Weihnachten, Black Friday etc. erhoben werden. Und wenn sie mit Vorperioden verglichen werden. All das sind dann Szenarios, die mit klassischen, relationalen Datenbanken oder Business Intelligence-Tools besser abgegolten werden. Und Kibana sowie andere gute Dashboards sind ja durchaus in der Lage, Daten aus mehreren Quellen anzuzeigen. Was können wir also für die Kollegen tun, die nicht an technischen Metriken interessiert sind?

Aktives vs. passives Monitoring

Noch bevor es Log-Server gab, hat man sich schon Gedanken darüber gemacht, wie man definierte Werte aus der Anwendung am besten festhalten kann. Ähnlich den Metriken für CPU, Memory, etc. sind ja auch Antwortzeiten pro Service oder URL interessant, die oben schon erwähnte Anzahl von HTTP-Response-Codes oder aber auch Metriken für bestimmte Abläufe.

JMX – alt, aber gut

Wer sich im Java-Umfeld schon mal Gedanken darüber gemacht hat, wird bald über JMX stolpern (Java Management Extension). Es ermöglicht genau das, was wir hier benötigen: das Exportieren von Werten. "Abgeholt" werden die Daten dann über einen TCP-Port vom Monitoring-Tool, dort werden sie auch gespeichert und visualisiert.

Gängige Anwendungen und Bibliotheken liefern von Haus aus JMX-Metriken. Die JVM selber liefert z. B. Infos über Garbage Collection, Speichernutzung, etc. Der Tomcat liefert Anzahl von Requests, Antwortzeiten, etc. Will der Programmierer aber individuelle Daten, wie z. B. Anzahl getätigter Bestellungen monitoren, muss er aktiv in den Code eingreifen, wie beim Logging auch.

JMX ist offiziell leider eine rein Java-spezifische Schnittstelle. Somit bleiben andere Technologien außen vor, was speziell mit serviceorientierten Umgebungen und Microservices ein gravierender Nachteil sein könnte. Als Alternative dazu erwähne ich deshalb immer statsd. Statsd ist für alle gängigen Programmiersprachen verfügbar und wird als Bibliothek – den statsd-Client – in die eigene Anwendung eingebunden. Dort wird dann an den entsprechenden Stellen ein entsprechender Aufruf gemacht.

Listing: statsd-Clients sind für alle gängigen Sprachen verfügbar und sehr intuitiv

var StatsD = require('node-statsd'),
client = new StatsD();

// Timing: sends a timing command with the specified milliseconds
client.timing('response_time', 42);

// Increment_ Increments a stat by a value (default is 1)
client.increment('my_counter');

// Decrement: Decrements a stat by a value (default is 1)
client.decrement('my_counter');

// Histogram: send data for histogram stat
client.histogram('my_histogram', 42);

// Gauge: Gauge a stat by a specified amount
client.gauge('my_gauge'; 123.45);

// Set: Counts unique occurrences of a stat (alias of unique)
client.set('my_unique', 'foobar');
client.unique('my_unique', 'foobarbaz');

statsd verlangt außerdem, dass auf jedem Host, wo unsere Services laufen, ein statsd daemon läuft. Die Clients senden die Informationen dann per UDP an die daemons, welche diese wiederum an ein zentrales Backend weiterleiten. Dort werden die Daten gespeichert und stehen für die Visualisierung zur Verfügung.

Ähnlich wie beim ELK-Stack ist auch statsd eine Konglomerat aus unterschiedlichen, eigentlich unabhängigen Komponenten. Das Backend und die Visualisierung können frei gewählt werden. Sehr oft wird z. B. Grafana zur Visualisierung eingesetzt.

"Amazon verliert x-tausende von Dollars pro Zehntelsekunde zusätzlicher Antwortzeit? Furchtbar! Wie viel ist das denn bei uns?" - Dein Geschäftsführer

Und das ist die Stelle, wo auch die Wünsche eines Geschäftsführers oder eines Abteilungsleiters ihre Berechtigung haben. Anzahl von Bestellungen und Umsätze sind vorher fix definierbare Metriken, wo keine große Flexibilität benötigt wird. Diese Metriken sollte man so einfach und simpel aus der Anwendung ausgeben, wie möglich. Um nun die Amazon-Problematik, dass Response-Zeit gleich verlorenem Umsatz ist, für sich selber verifizieren zu können, muss man nur noch die jeweiligen Metriken in einem Chart seiner Wahl kombinieren. Und so ist es dann ein leichtes, dem Techniker klar zu machen, warum die Behebung eines speziellen Problems nicht länger warten kann. Im Gegenzug könnte es natürlich auch vorkommen, das manches nicht ganz so dringend ist, wie man meinen könnte. So oder so, es kann nur gut sein, spekulative Annahmen durch konkrete Zahlen zu ersetzen.

Das Ende vom klassischen Monitoring

Je weiter wir in die Tiefen des Monitoring vordringen, desto weiter entfernen wir uns auch von dem, was als klassisches Monitoring bekannt ist. Mit dem Einzug von Microservices ist die Performance isolierter Komponenten zum Beispiel in den Hintergrund getreten, denn selbst kleinste Anwendungen sind nun verteilte Systeme aus vielen kleinen Komponenten. Die Zusammenarbeit dieser ist nun mindestens so wichtig. Neben der Anwendung selber ist außerdem die Orchestrierung in den Vordergrund gerückt. Das heißt, auch die Infrastruktur selbst muss nun überwacht werden. Themen wie Call-Tracing sind zur Notwendigkeit geworden, um die Zusammenhänge noch sinnvoll darstellen und nachvollziehen zu können. Vielleicht ist auch das ein Grund dafür, dass DevOps – das Zusammenwachsen von Entwicklung und Betrieb – immer mehr Einzug hält in die Entwickler- und Betreiberstuben.

Management ist das Neue Monitoring

Für das Monitoring der neuen Generation hat sich die Industrie den Begriff "Application Performance Management" (APM) ausgedacht. Der Begriff "Monitoring" kommt darin gar nicht mehr vor, obwohl es landläufig von denen, die APM nutzen, wohl immer noch so genannt wird.

Application Performance Management hat sich zum Ziel gesetzt, zusätzlich zum klassischen Monitoring auch die neuen Use-Cases abzudecken und vor allem Metriken aus Sicht der Anwendung oder sogar des End-Users zu erfassen. Der Betriebssystem-Layer tritt in den Hintergrund, da es immer unwichtiger wird, auf welchem Host welche Instanz eines Services läuft.

Container-Technologien könnten den klassischen VMs den Rang ablaufen und wieder direkt auf der Hardware laufen. Platform-as-a-Service wird in den Clouds immer beliebter, zumindest um Frontends zu betreiben. Und in naher Zukunft wird selbst mancher Microservice durch sogenannte serverlose Apps in AWS Lambda, Azure Functions oder Google Cloud Functions abgelöst.

Was Großvater noch nicht wusste

Hier nun einige Features, die das klassische Monitoring von APM unterscheiden. Die Anbieter mit der meisten Erfahrung und dem größten Funktionsumfang im APM-Bereich der aktuellen Generation sind Dynatrace, New Relic und AppDynamics. Wer sich ernsthaft und professionell mit diesem Thema auseinandersetzen will, kommt an diesen Anbietern nicht vorbei. Alle diese Lösungen unterscheiden sich voneinander, in vielerlei Hinsicht.

Muss es die kommerzielle Variante sein?

Für viele der angeführten Use-Cases gibt es Open Source-Projekte, die diese Felder ebenfalls sehr gut bedienen. Speziell im Bereich Call-Tracing und Visualisierung von Microservices sprudelt GitHub nur so über vor möglichen Lösungen. Häufig sind diese aber nur auf einzelne Technologien oder sogar einzelne Frameworks beschränkt.

Der geneigte Leser sollte sich trotzdem Finagle [1] oder Spring Cloud [2] ansehen. Bei Node.js reicht es eigentlich, nach "node.js call tracing" oder ähnlichen Begriffen zu suchen.

Und meist ist mit dem Ende des Codes auch das Ende des Tracing verbunden. Die drei genannten kommerziellen Anbieter gehen da etwas weiter und binden im Idealfall auch die Datenbank mit ein.

Wo bei Node.js und auch dem Spring-Framework für Java die Open Source Calltracing-Lösungen noch relativ weit verbreitet sind, wird es sogar bei C# oder aber auch bei PHP schon schwieriger.

Treffen sich ein Ops, ein Dev und ein Executive am Dashboard…

… und freuen sich, das alle was davon haben. Der Ops sieht Metriken zur Verfügbarkeit, der Dev kann Performance-Einbrüche sofort wahrnehmen und vielleicht auch nachvollziehen und der monetär veranlagte Kollege kann die Korrelation zwischen technischen und monetären Tatbeständen herstellen. Im Idealfall ist es ein einziges, gemeinsames Tool, welches das ganze Unternehmen an einen gemeinsamen Tisch bringt.

Sauberes Monitoring und/oder Application Performance Management ist also tatsächlich sehr viel mehr, als man meinen möchte. Eines ist es jedoch defintiv nicht: ein seichter Witz.

Autor

Martin Gutenbrunner

Martin Gutenbrunner hat 10 Jahre lang programmiert und Software-Architektur gemacht. Heute ist er Tech Lead im Innovation Lab bei Dynatrace.
>> Weiterlesen
botMessage_toctoc_comments_9210