Middleware-Monitoring & Observability: Kennzahlen, Traces und Betrieb
Middleware-Monitoring: warum die Vermittlungsschicht einen eigenen Blick braucht
Middleware-Monitoring überwacht den Datenfluss zwischen angebundenen Systemen, nicht die Systeme selbst. Gemessen wird, ob Nachrichten ankommen, wie lange sie unterwegs sind und an welcher Station sie liegen bleiben. Laut dem Observability Forecast 2025 von New Relic belaufen sich die mittleren Kosten schwerwiegender IT-Ausfälle in den befragten deutschen Unternehmen auf 169 Millionen US-Dollar pro Jahr, 46 Prozent verzeichnen mindestens wöchentlich einen solchen Ausfall. Unternehmen mit umfassender Betriebstransparenz zahlen eine statt zwei Millionen US-Dollar pro Ausfallstunde.
Middleware-Monitoring kurz definiert
Middleware-Monitoring bezeichnet die kontinuierliche Überwachung der Vermittlungsschicht zwischen getrennten Anwendungen. Erfasst werden Warteschlangenlänge, Durchsatz, Antwortzeiten, Fehlerquoten und Auslastung der beteiligten Broker, Adapter, Warteschlangen und Schnittstellen. Ziel ist der Nachweis, dass Nachrichten vollständig, in korrekter Reihenfolge und innerhalb vereinbarter Zeitfenster übertragen werden. Die Messpunkte liegen dabei in der Middleware selbst, nicht auf Host- oder Netzebene.
Warum genügt Infrastruktur-Monitoring für die Middleware-Schicht nicht?
Weil es Gerätezustände prüft, nicht den Weg einer Nachricht. Ein Broker kann laufen, Prozessor und Speicher im grünen Bereich, während sich zehntausend unverarbeitete Aufträge stapeln. Ein grünes Infrastruktur-Dashboard beweist keinen funktionierenden Datenfluss. Wie die Middleware als Vermittlungsschicht im Gesamtbild arbeitet, ordnet der übergeordnete Leitfaden ein. Middleware-Monitoring setzt eine Ebene darüber an. Es fragt nach dem Zustand der Nachricht, nicht nach dem Zustand der Maschine.
Blinde Flecken im Host- und Netz-Monitoring
Manche Störungsbilder belasten keine Ressource und tauchen in Infrastruktur-Dashboards nicht auf. Genau diese Lücke schließt das Middleware-Monitoring. Es reicht tiefer als das allgemeine Software-Monitoring als Dienstleistung, weil es die Übergabe zwischen Systemen misst. Diese Fälle bleiben sonst unsichtbar:
- Wachsende Warteschlangen bei laufendem Broker-Prozess
- Nachrichten, die stillschweigend in der Dead-Letter-Queue landen
- Adapter, die nach einem Zielsystem-Update falsch abbilden
- Transaktionen, die halb durchlaufen und halb zurückgerollt werden
- Reihenfolgeverletzungen bei parallel verarbeiteten Nachrichten
- Ablaufende Zertifikate, die eine Anbindung ohne Alarm stilllegen
Middleware-Überwachung als eigene Betriebsdisziplin
Middleware-Überwachung braucht eigene Messpunkte, eigene Schwellwerte und eigene Alarmwege. Die tragenden Signale entstehen dort, wo Nachrichten die Schicht betreten und verlassen, also an Queues, Topics, Adaptern und Transaktionsgrenzen. Ohne separate Instrumentierung melden die Fachbereiche die Störung. Genau hier trennt sich Integrations-Monitoring von der Infrastrukturüberwachung, die auf Hosts und Netzstrecken zielt. In der Anwendungsbetreuung und im laufenden Betrieb verkürzt eine saubere Kontrolle der Vermittlungsschicht die Zeit bis zur Ursachenfindung deutlich.
Was unterscheidet Middleware-Monitoring von Observability?
Monitoring prüft bekannte Zustände gegen feste Grenzwerte, Observability rekonstruiert unbekannte Ursachen aus Rohdaten. Der Unterschied zwischen Observability und Monitoring liegt damit weniger im Werkzeug als in der Fragestellung. Monitoring meldet den Symptomzustand, Observability erklärt den Weg dorthin. In einer gewachsenen Integrationslandschaft sind beide Ebenen nötig, weil kein Alarmkatalog alle möglichen Störungsbilder vorwegnimmt. Ein reifes Middleware-Monitoring verbindet feste Grenzwerte mit einer Datenbasis, die unbekannte Fälle rekonstruierbar macht.
Vom festen Schwellwert zum Distributed Tracing
Schwellwerte funktionieren, solange die Fehlerbilder bekannt sind. Sobald mehrere Dienste an einem Vorgang beteiligt sind, verschiebt sich die Frage von der einzelnen Kennzahl zur gesamten Kette. Wie viel Gewicht Traces bekommen, hängt auch am Protokoll: Bei einer Entscheidung für gRPC vs REST fallen binäre Nutzdaten an, die sich ohne Tracing kaum noch nachvollziehen lassen. Observability für cloud-native Middleware und Microservices stützt sich daher auf drei Datenarten, die nur gemeinsam etwas erklären:
- Metriken als verdichtete Zeitreihen zu Durchsatz und Latenz
- Logs als Einzelereignisse mit Kontext zur jeweiligen Nachricht
- Traces als vollständiger Weg einer Transaktion über alle Stationen
- Gemeinsame Kennungen, die Metriken, Logs und Traces verbinden
Traces verbinden, was Kennzahlen trennen
Distributed Tracing markiert jede Nachricht beim Eintritt in die Schicht und trägt diese Kennung durch jede Weiterleitung. So lassen sich Transaktionen über Systemgrenzen nachverfolgen, ohne vorher zu wissen, wonach gesucht wird. Damit lassen sich der Durchsatz am API-Gateway und die Verweildauer im Broker demselben Vorgang zuordnen. Erst die Spur über alle Stationen macht die Ursache sichtbar und den Unterschied zwischen Observability und Monitoring praktisch greifbar. OpenTelemetry hat sich dafür als herstellerneutraler Standard etabliert.
Middleware-Überwachung im Verhältnis zum klassischen APM
Application Performance Monitoring blickt in den Anwendungscode, Middleware-Überwachung blickt auf den Verkehr zwischen den Anwendungen. APM zeigt die langsame Datenbankabfrage in einem Dienst, Middleware-Monitoring zeigt, dass die Antwort nie beim Empfänger ankam. Beide Perspektiven ersetzen sich nicht, sie beantworten verschiedene Fragen. Von der Absicherung und Härtung der Middleware unterscheidet sich Betriebstransparenz ebenfalls klar. Härtung verhindert unerlaubte Zugriffe, Observability macht erlaubte Vorgänge nachvollziehbar. Beide Disziplinen greifen auf dieselben Protokolldaten zu, ziehen daraus aber unterschiedliche Schlüsse. Wer Schnittstellen neu baut, legt die Messpunkte am besten schon in der Schnittstellen- und API-Entwicklung fest, statt sie später nachzurüsten.
Golden Signals für die Middleware-Schicht
Die vier Golden Signals aus dem Site Reliability Engineering (Latenz, Traffic, Fehler und Sättigung) lassen sich direkt auf die Vermittlungsschicht übertragen. Sie liefern ein knappes Kennzahlenset, das ohne tiefes Werkzeugwissen lesbar bleibt. Vier Signale genügen für ein belastbares Lagebild der Integrationsschicht. Im Middleware-Monitoring kommt eine fünfte, schichttypische Größe hinzu, die Warteschlangentiefe.
Die vier Signale auf Queues und Transaktionen übertragen
Jedes Signal bekommt in der Vermittlungsschicht eine eigene Bedeutung. Wichtig ist im Middleware-Monitoring die Messung je Anbindung, nicht als Summe über alle Schnittstellen hinweg. Diese Kennzahlen bilden das Fundament jeder Middleware-Überwachung:
- Latenz: Verweildauer einer Nachricht von Eintritt bis Bestätigung
- Traffic: Nachrichten pro Minute je Queue, Topic und Adapter
- Fehler: Anteil fehlgeschlagener und wiederholter Übertragungen
- Sättigung: Warteschlangentiefe im Verhältnis zur Kapazität
- Alter der ältesten unverarbeiteten Nachricht je Warteschlange
Queue-Tiefe als Frühwarnsignal
Die Warteschlangentiefe zeigt Störungen, bevor die Fachbereiche sie bemerken. Steigt sie stetig, verarbeitet der Empfänger langsamer, als der Sender liefert. Ein dauerhaft wachsender Rückstand kündigt den Stillstand an, statt ihn nur zu melden. Message Queues in der Middleware überwachen heißt deshalb, auf die Steigung zu achten und nicht allein auf den Absolutwert. Im Middleware-Monitoring bewährt sich ein zweiter Alarm auf das Alter der ältesten Nachricht, weil eine kleine, aber festsitzende Warteschlange sonst unbemerkt bleibt.
Latenz getrennt je Anbindung messen
Ein Mittelwert über alle Schnittstellen verdeckt genau die eine Anbindung, die klemmt. Deshalb gehört jede Verbindung als eigene Messreihe in die Auswertung, ergänzt um Perzentile statt reiner Durchschnitte. Das 95. Perzentil deckt Ausreißer auf, die der Mittelwert glättet. Auffällig sind Anbindungen, deren Perzentil über Wochen nach oben wandert. Auch beim Betrieb einer iPaaS folgt das Middleware-Monitoring dieser Logik, weil gebuchte Plattformen eigene Grenzwerte je Konnektor mitbringen.
Wann lohnt es sich, Betrieb und Überwachung auszulagern?
Sobald die Systemlandschaft geschäftskritisch ist und niemand im Haus die Vermittlungsschicht dauerhaft im Blick behält. Monitoring Tools allein lösen das nicht, denn sie erzeugen Daten, keine Reaktion. Erst eine feste Zuständigkeit macht aus Messwerten eine Betriebsentscheidung. Die Beobachtung der Integrationsschicht wird damit zur Personalfrage, nicht zur Werkzeugfrage. Middleware-Monitoring im eigenen Haus bindet Rufbereitschaft, Werkzeugpflege und Fachwissen dauerhaft.
Kriterien für die Auslagerung
Die Middleware-Überwachung scheitert selten an der Technik, sondern an der Verfügbarkeit von Menschen und Zeit. Diese Punkte sprechen in der Praxis für Middleware-Monitoring als Managed Service:
- Störungen fallen erst im Fachbereich auf, nicht im Betrieb
- Außerhalb der Kernzeiten existiert keine Rufbereitschaft
- Kennzahlen liegen vor, aber niemand bewertet sie regelmäßig
- Audit- und Nachweispflichten verlangen belegte Datenflüsse
- Monitoring Tools sind lizenziert, aber nur teilweise eingerichtet
Middleware-Monitoring als Managed Service
TenMedia entwickelt und betreibt Vermittlungsschichten und übernimmt deren Middleware-Überwachung im Rahmen der Anwendungsbetreuung, mit vereinbarten Reaktionszeiten und regelmäßiger Auswertung der Kennzahlen. Dazu gehören die Instrumentierung von Queues und Adaptern, eine Alarmierung mit klaren Eskalationswegen und die Nachvollziehbarkeit der Datenflüsse für Audits. Wie das im Dauerbetrieb aussieht, zeigt der Betrieb und die Wartung einer hochverfügbaren Plattform für medienrettung. So wird Middleware-Monitoring zur dauerhaften Betriebsleistung statt zum einmaligen Projekt.
