Das Monitorng-Stack setzt sich aus den folgenden Elementen zusammen: 

• Eine Time-Series-Datenbank für das Speichern von Metriken (z. B. Prometheus). Diese Komponente sammelt üblicherweise die Metriken der einzelnen Applikationen. 
• Ein Logs- und Traces-Collector: Dieser kann entweder eine einzelne Komponente sein (wie OpenTelemetry Collector) oder auch zwei oder mehrere getrennte Komponenten. Der Collector sammelt Traces und Logs von den einzelnen Systemen und leitet diese weiter:
  • Logs werden zu einem Log-Storage geleitet (z. B. Loki)
  • Traces werden zu einem Trace-Storage (z. B. Tempo) weitergeleitet 

Schließlich werden Metriken, Traces und Logeinträge über eine Weboberfläche, wie zum Beispiel Grafana, zugänglich gemacht. 

Schritt für Schritt-Anleitung für den Aufbau von Monitoring und Tracing für ein Legacy-System

Grob zusammengefasst, umfasst der Aufbau von Monitoring und Tracing folgende vier Schritte: 

1. Priorisierung: Zunächst wird festgelegt, welche Systeme bzw. welche Teile von einem System am Meisten vom Monitoring profitieren würden, bzw. für welches System ein PoC sich am einfachsten priorisieren lässt.  

PoC bedeutet generell „Proof-Of-Concept” – eine Machbarkeitsstudie, die die grundsätzliche Umsetzbarkeit einer Idee oder eines Vorhabens nachweist. Er dient dazu, Risiken zu minimieren und Ressourcen zu sparen, bevor ein Projekt oder Produkt in vollem Umfang umgesetzt wird. Im Scope von Monitoring bedeutet das, dass es zuerst ein kleines isoliertes Teil des Legacysystems auswählt, wofür in einer Testumgebung Monitoring implementiert wird. Die Ergebnisse werden den OPS und Entwicklern präsentiert, die prinzipielle Machbarkeit und Nutzen aufgezeigt, um die Richtung für die weitere Entwicklung zu setzen. 

2. Aufbau eines Monitoring-Stacks: Im nächsten Schritt wird der Monitoring-Stack aufgebaut. Dabei muss frühzeitig überlegt werden, wie dieser gestaltet sein soll. Folgende Aspekte sind dabei zu berücksichtigen:  

a) Handelt es sich um ein Legacy-System On-Premise oder in der Cloud? Falls es sich um ein On-Premise System handelt, ist eine Entscheidung über das Deployment des Stacks zu treffen (z. B. Verwendung von Kubernetes).  

b) Handelt es sich um ein Cloudsystem, soll entschieden werden, wie wahrscheinlich ist es, dass das System entweder zu einem anderen Anbieter oder zu einem On-Premise-System migriert wird. Wenn die Migration eher unwahrscheinlich ist, kommen die Cloudanbieter-Spezifische Monitoring- und Tracingsysteme in Betracht (wie z. B. AWS CloudWatch oder AWS X-Ray). Ist die Migration aber nicht auszuschließen, soll auf Cloudanbieterunabhängige Systeme angesetzt werden. Anderenfalls muss das gesamte Monitoring bei der Migration ein zweites Mal von Anfang an aufgebaut werden. 

c) Wie sieht die vorhandene Infrastruktur aus, zum Beispiel:

• • Netzwerktopologie (vorhandene Firewalls, Netzwerkaufteilung).
  • Wie viel Logs werden produziert.
  • Vorhandene Datenbanken und Webserver, die überwacht werden sollen.

d) Auswahl geeigneter Komponenten für jedes Monitoring-Element (z. B. Dashboard-Tool, Log-Aggregator) 

e) Festlegung von Software Development Kits (SDK)/Frameworks für die Integration des Monitorings in die Anwendung 

3. Integration von Metriken und Traces für ein PoC in einen Teil des Systems 

4. Testen des aufgebauten PoCs, Einführung der Entwickler und des Operations-Teams in das Monitoring 

5. Schrittweise Erweiterung des Monitorings für den Rest des Systems 

Welches Monitoring, Tracing und Logging Systeme stehen auf dem Markt zur Verfügung?

Nach Abschluss der Planung für den Aufbau eines Monitoring-Systems ist es nun an der Zeit, mit der Implementierung zu beginnen. Es sollte geprüft werden, welche technischen Alternativen zur Verfügung stehen und welche Frameworks sowie Tools für das Projekt von Bedeutung sind. Im Folgenden finden Sie eine kurze Liste als Orientierungshilfe: 

Monitoring-Dashboards für die Visualisierung von Informationen

Ein Monitoring-Dashboard ist eine grafische Benutzeroberfläche, die Informationen über die Leistung und den Zustand von IT-Systemen und -Infrastrukturen visualisiert. Im Projekt stehen folgende Alternativen zur Verfügung: 

• Grafana: Grafana ist das wohl am Meisten verbreitete Monitoring-Dashboard. Es eignet sich sowohl für kleine als auch für große Projekte, ist OpenSource, und unterstützt durch Plugins viele unterschiedliche Backend-Systeme. Grafana kann nicht nur Metriken, sondern auch Logs und Traces präsentieren, so dass man bequem ein Dashboard für alle Informationen benutzen kann. 
• DataDog: DataDog ist ein kommerzielles Dashboard, das wie Grafana Logs, Traces und Metriken visualisieren kann. Es eignet sich eher für größere Projekte. 
• AWS CloudWatch: AWS CloudWatch ist ein natives Dashboard für Logs und Metriken in der AWS-Umgebung. Die Funktionalität ist im Vergleich zu anderen Tools eher rudimentär, jedoch lohnt sich das Tool, wenn eine schnelle Einrichtung des Monitorings innerhalb von AWS erforderlich ist. 

Metriken: Collector/TimeSeries-DBs und Frameworks

 Im Bereich Metriken ist es wichtig, zwischen dem Collector/TimeSeries-DB, der Metriken von verschiedenen Systemen sammelt und sie dem Dashboard zur Verfügung stellt, sowie den Frameworks, die in die jeweilige Applikation integriert werden, um Metriken an den Collector zu senden, zu unterscheiden. 

Collector/TimeSeries-DBs: 

• Prometheus: Prometheus ist eine weit verbreitete TimeSeries-DB für das Monitoring.
  • Es basiert auf einem Pull-Modell, d. h. es fragt Metriken von seinen Zielen in regelmäßigen Abständen ab. Dies unterscheidet sich von Push-basierten Monitoring-Systemen, bei denen Ziele Metriken an einen zentralen Server senden.
    
  • Das Pull-Modell ist für große Umgebungen effizienter, da es die Belastung der Ziele verringert.
  • Prometheus bietet eine leistungsstarke Abfragesprache namens PromQL, die zur Extraktion von Erkenntnissen aus den gesammelten Metriken verwendet werden kann.
    
  • PromQL ist ausdrucksstark und intuitiv und kann zur Erstellung von ad-hoc-Grafiken, Tabellen und Warnmeldungen verwendet werden.
    
  • Prometheus speichert Metriken in einer Zeitreihendatenbank, die eine effiziente Abfrage und Zusammenfassung historischer Daten ermöglicht.
    
  • Die Zeitreihendatenbank ist auch so konzipiert, dass sie horizontal skaliert werden kann, um dem Wachstum der Überwachungsdaten gerecht zu werden.

• InfluxDB: InfluxDB ist eine Open-Source-Zeitreihendatenbank, die auch für Monitoring-Zwecke verwendet werden kann. Sie bietet eine ähnliche Funktionalität wie Prometheus, einschließlich eines Pull-Modells, einer leistungsstarken Abfragesprache und einer großen Community.
  
  InfluxDB bietet eine leistungsstarke Abfragesprache namens Flux, die ähnlich wie PromQL zur Extraktion von Erkenntnissen aus den gespeicherten Daten verwendet werden kann. 

Um die Metriken der Applikation für die Collectors verfügbar zu machen, muss ein Metriken-Framework in die zu überwachende Applikation integriert werden. Hierfür gibt es verschiedene Alternativen: 

• Micrometer (für Java): eine Open-Source-Bibliothek, die für die Sammlung und Bereitstellung von Metriken aus Java-Anwendungen verwendet wird. Sie bietet eine einfache und einheitliche API für die Messung einer Vielzahl von Aspekten einer Anwendung, darunter:
  • Anwendungsleistung: CPU-Auslastung, Speichernutzung, Netzwerkbandbreite, Reaktionszeiten
    
  • Anwendungsverhalten: Fehlerraten, Abbruchraten, HTTP-Statuscodes
    
  • Anwendungskontext: Benutzer, Sitzungen, Datenbanken 

• Prometheus MySQL Exporter: Ein Open-Source-Tool, das Prometheus-kompatible Metriken für MySQL-Server sammelt. Es kann verwendet werden, um die Leistung, Verfügbarkeit und Nutzung von MySQL-Servern zu überwachen
  • Der Exporter kann auf einem beliebigen Betriebssystem ausgeführt werden, das Python 3 unterstützt. Er kann entweder als Docker-Container oder als native Anwendung installiert werden.
    
  • Der Exporter sammelt eine Vielzahl von Metriken, darunter:
    
    • Serverstatus, z. B. die Anzahl der laufenden Verbindungen, die CPU-Auslastung und die Speichernutzung
    • Tabellenstatus, z. B. die Anzahl der Tabellen, die Anzahl der Zeilen und die Größe der Tabellen
      
    • Abfragestatus, z. B. die Anzahl der ausgeführten Abfragen, die Dauer der Abfragen und die Anzahl der zurückgegebenen Zeilen 
  • Die gesammelten Metriken können dann mit Prometheus-Servern oder anderen Monitoring-Tools analysiert werden.
    

• Nginx Prometheus Exporter: Ein OpenSource-Tool für das Exportieren von Metriken aus Nginx.
  
  • Der Nginx Prometheus Exporter liest Metriken aus dem Nginx-Stub-Status-Endpunkt. Dieser Endpunkt enthält Informationen über die Leistung Ihres Nginx-Servers, wie z. B. die Anzahl der Verbindungen, die Anzahl der Anfragen pro Sekunde und die Anzahl der Fehler.
  • Der Nginx Prometheus Exporter exportiert die Metriken in einem Format, das von Prometheus verstanden wird. Dies ermöglicht es Prometheus, die Metriken zu sammeln und zu visualisieren. 

Die Auswahl des passenden Metriken-Frameworks hängt von den Anforderungen und der Technologie der jeweiligen Anwendung ab. 

Tracing Frameworks und Tools

Für die Implementierung von Tracing stehen verschiedene Frameworks und Tools zur Verfügung: 

• OpenTelemetry  

OpenTelemetry ist ein Open-Source-Observability-Framework, das für die Erfassung und Verwaltung von Telemetriedaten wie Traces, Metriken und Logs entwickelt wurde. Es ist anbieterunabhängig und kann mit einer Vielzahl von Observability-Backends verwendet werden, einschließlich Open-Source-Tools wie Prometheus und Grafana.

Hauptkomponenten von OpenTelemetry sind:

• • APIs: Eine Reihe von APIs, die Entwicklern ermöglichen, Telemetriedaten zu erfassen und zu verwalten.
    
  • SDKs: SDKs für verschiedene Programmiersprachen, die die Implementierung der APIs erleichtern.
  • Tools: Eine Reihe von Tools zur Erfassung, Analyse und Visualisierung von Telemetriedaten.
    
  • Agent: Ein Agent, der an eine JVM-Instanz angebunden wird und automatisch Traces aus der JVM exportiert. Folgende Traces werden von einem Java-Agent erfasst:
    
    • HTTP(S)-Anfragen und Antworten
      
    • DB-Zugriffe
      
    • Cronjobs
      
    • Es können auch eigene Erweiterungen entwickelt werden, um eigene Traces zu erzeugen (z. B. für Business-Prozesse, wie getätigte Einkäufe)
• Zipkin

Ähnlich wie OpenTelemetry ist Zipkin ein Open-Source-System zum verteilten Tracing, dass die Überwachung der Leistung und Verfügbarkeit von verteilten Anwendungen ermöglicht. Es erfasst und speichert Trace-Daten, die Informationen über den Aufrufstapel, die Start- und Endzeit, die Dauer und die Kosten eines Aufrufs enthalten. Diese Daten können genutzt werden, um die Leistung von Anwendungen zu analysieren und Probleme zu identifizieren.

Zipkin basiert auf dem Dapper-Paper von Google und nutzt einen dezentralen Ansatz zur Erfassung und Speicherung von Trace-Daten. Die Trace-Daten werden in einem Trace-Aggregator gespeichert, der die Daten aus verschiedenen Quellen sammelt und zusammenführt.

Funktionen von Zipkin sind:

• • Dezentrale Erfassung und Speicherung: Zipkin verwendet einen dezentralen Ansatz zur Erfassung und Speicherung von Trace-Daten, der skalierbar und robust ist.
  • Trace-Aggregation: Zipkin kann Trace-Daten aus verschiedenen Quellen sammeln und zusammenführen. Dies ermöglicht es Ihnen, die Leistung von gesamten verteilten Anwendungen zu überwachen.
  • Trace-Visualisierung: Zipkin kann Trace-Daten mit einer Vielzahl von Visualisierungstools visualisieren. Dies erleichtert die Analyse von Trace-Daten und die Identifizierung von Problemen.

• Jaeger
  

• • Tracer: Der Tracer ist für die Erfassung von Trace-Daten verantwortlich. Er wird in den Anwendungen ausgeführt, die überwacht werden sollen. 
  • Collector: Der Collector ist für die Speicherung von Trace-Daten verantwortlich. Er kann als eigenständige Anwendung oder als Docker-Container ausgeführt werden.
    
  • Query-Service: Der Query-Service ist für die Abfrage von Trace-Daten verantwortlich. Er kann mit einer Vielzahl von Observability-Tools verwendet werden, um Trace-Daten zu visualisieren und zu analysieren. 

Fazit: Wie Ihnen der Aufbau eines Monitoring-Stacks Ihr Legacy-System effizienter und sicherer macht

Der Aufbau eines Observatory- oder Monitoringsystems, insbesondere für ein Legacy-System, ist keine einfache Aufgabe. Dennoch rechtfertigt das Kosten/Nutzen-Verhältnis die investierte Arbeit. Die Implementierung eines effektiven Monitorings bietet nicht nur die Möglichkeit, die Leistung und Verfügbarkeit des Systems zu verbessern, sondern ermöglicht auch eine proaktive Identifikation und Behebung von Problemen. Die Auswahl geeigneter Tools und Frameworks, wie beschrieben, spielt dabei eine entscheidende Rolle, um eine umfassende Observability und damit eine effiziente Systemverwaltung zu gewährleisten. 

Die praxisnahe Herangehensweise an das Monitoring von Legacy-Systemen, wie in unserer Schritt-für-Schritt-Anleitung beschrieben, verdeutlicht, dass die Implementierung von Monitoring und Tracing keine undurchschaubare Herausforderung darstellen muss. Vielmehr kann sie durch klare Richtlinien und bewährte Methoden effizient umgesetzt werden. 

Insgesamt zeigt sich, dass Monitoring nicht nur eine technische Notwendigkeit, sondern eine strategische Investition in die Zuverlässigkeit und Effizienz von Legacy-Systemen ist. Eine durchdachte Implementierung von Monitoring, Tracing und Logging ermöglicht es Unternehmen, den Herausforderungen im IT-Betrieb souverän zu begegnen und langfristig von stabilen und leistungsfähigen Systemen zu profitieren. 

Für weitere Informationen zum Thema Monitoring und Observability für ein Legacy-System nehmen Sie Kontakt zu unseren Expertinnen und Experten auf! 

Die 7P kann durch langjährige Erfahrung mit dem Aufbau von Monitoring für Ihr Legacy- (und Greenfield) -System unterstützen. Wir helfen Ihnen bei der Auswahl der Monitoring-, Tracing- und Logging-Systeme sowie bei der Implementierung eines Monitoring-Stacks in Ihrer Systemlandschaft.