Cloud-Monitoring: Die 6 größten Herausforderungen in hybriden und Multi-Cloud-Umgebungen

Auf dem Papier klingen hybride Cloud und Multi-Cloud einfach, denn einige Workloads laufen in der Public Cloud, andere On-Premises, und alles ist verbunden. In der Praxis verwalten Sie beim Cloud-Monitoring jedoch Abhängigkeiten über Teams und Systeme hinweg. Dazu kommen Tools ohne gemeinsamen Kontext und Incidents, die sich nicht auf einen Ort beschränken.

Die meisten Umgebungen kombinieren VMs, Container, Managed Services und SaaS-Abhängigkeiten, verteilt auf On-Premises und eine oder mehrere Clouds. Jede Komponente fällt auf eigene Weise aus und hat oft einen anderen Verantwortlichen.

Zugriff, Aufbewahrung und Zuständigkeiten werden schwieriger, weil ältere Systeme und neue Cloud- und SaaS-Dienste unterschiedlichen Regeln und Teams folgen. Auch Incidents sind keine Seltenheit. Die jährliche Outage-Analyse des Uptime Institute verfolgt Ausfalltrends und zeigt, dass Ausfälle weiterhin passieren, mit echten Kosten und Störungen, wenn Teams die Transparenz verlieren.

Hält das Monitoring nicht Schritt, verlieren Sie Zeit bei größeren Incidents, bei Routine-Releases und in Planungsrunden. In diesen Runden fehlt dann das Vertrauen in die Daten, um eine belastbare gemeinsame Entscheidung zu treffen.

Diese sechs Herausforderungen im Cloud-Monitoring treten in vielen hybriden und Multi-Cloud-Umgebungen auf. Wenn Ihnen einige davon bekannt vorkommen, geht es Ihnen wie vielen anderen IT-Teams.

1) Fragmentierte Monitoring-Daten

Hybride und Multi-Cloud-Umgebungen sammeln mit ihrem Wachstum immer mehr Monitoring-Tools an. Die meisten Teams nutzen schließlich mehrere Observability-Plattformen, wodurch die Transparenz fragmentiert wird.“. Das erschwert eine gemeinsame Sicht auf das aktuelle Geschehen.

Da sind zunächst die großen Cloud-Anbieter wie AWS, Azure, Google Cloud und Oracle Cloud Infrastructure. Mit ihnen kommen ihre nativen Monitoring-Tools, also Amazon CloudWatch, Azure Monitor, Google Cloud Monitoring und Oracle Cloud Infrastructure Monitoring. Prometheus läuft auf dem Kubernetes-Cluster. Das Anwendungsteam arbeitet in einem APM-Tool, das Netzwerkteam hat weiterhin sein eigenes System. Jedes Tool war sinnvoll, als es eingeführt wurde.

Mehr Tools bedeuten auch mehr Stellen, an denen Sie Berechtigungen und Aufbewahrungsfristen verwalten. Das wird schnell unübersichtlich, wenn das Monitoring Provider, Kubernetes, SaaS und On-Premises umfasst und verschiedene Teams einzelne Bereiche verantworten. Das Problem zeigt sich, sobald etwas ausfällt und Sie die Zusammenhänge erkennen müssen.

Wenn Sie schon einmal Rufbereitschaft (On-Call) in einer gemischten Umgebung hatten, kennen Sie das. Die Anwendungslogs zeigen Fehler ab 10:14 Uhr, das Dashboard des Datenbankteams zeigt eine Spitze um 10:11 Uhr. Dazu kommt ein kurzer Ausschlag im Netzwerkdiagramm um 10:09 Uhr. Jetzt wechseln Sie zwischen drei Konsolen und versuchen, Zeitstempel abzugleichen. Sie wollen herausfinden, welche Spitze welches Symptom verursacht hat. Außerdem müssen Sie klären, ob irgendetwas davon mit dem Deployment von 10:00 Uhr zusammenhängt.

Jemand macht einen Screenshot seiner Ansicht und postet ihn in Slack oder Microsoft Teams. Jemand anderes antwortet: „Das sehe ich so nicht.“ Zwanzig Minuten nach Beginn des Incidents bauen Sie noch an einer Zeitachse, statt einen Fix zu testen. Der Grund ist der Zeitaufwand für den manuellen Datenabgleich, mit der Incidents regelmäßig beginnen. Sie gleichen Zeitstempel ab, übersetzen Terminologie und setzen eine Darstellung aus Fragmenten zusammen, die nicht für eine gemeinsame Auswertung ausgelegt sind. Speichert ein System die Daten sieben Tage und ein anderes dreißig, fehlen Ihnen selbst mit der richtigen Zeitachse womöglich entscheidende Daten.

Der Zeitverlust ist vorhersehbar. Sie verbringen den ersten Abschnitt des Incidents damit, Daten zu korrelieren, statt den Fehler zu untersuchen.

Funktioniert das Cloud-Monitoring in einer verteilten Umgebung gut, entfällt diese Steuer weitgehend. Sie erkennen Zusammenhänge, ohne fünf Tabs zu öffnen, und die Zeitachse steht bereits, wenn Sie dazukommen. Anwendungsfehler, Datenbanklatenz und Netzwerküberlastung erscheinen in einer gemeinsamen Ansicht auf einer einheitlichen Zeitachse. SSo können Sie sich auf die eigentliche Untersuchung konzentrieren, statt Zeit mit der Korrelation von Daten zu verbringen. Etwas Automatisierung hilft dabei. Entscheidend ist aber der gemeinsame Kontext, den Observability für hybride IT-Umgebungen liefert.

2) Komponenten-Monitoring ohne Servicekontext

Ein kundenseitiger Service besteht selten aus nur einem Baustein. Nehmen Sie einen Login- oder Checkout-Prozess. Er ruft vielleicht einen Identity Provider auf, der oft in einer anderen Cloud oder als SaaS läuft. Danach greift er auf eine Datenbank zu, schreibt in eine Queue, löst eine Serverless-Funktion aus und nutzt eine Drittanbieter-API. Jeder dieser Bausteine kann unbemerkt nachlassen, während der Rest in Echtzeit-Dashboards unauffällig aussieht.

Die meisten Ansätze im Cloud-Monitoring sind jedoch nach Infrastrukturebenen organisiert, also nach Servern, Containern, Datenbanken und Netzwerken. Der Service, den Kunden nutzen möchten, steht dabei selten im Mittelpunkt. Das zeigt sich besonders, wenn Sie bei einem Incident die entscheidende Frage beantworten wollen, nämlich welcher kundenseitige Service betroffen ist und wie stark.

Wenn sich Alerts anhäufen, erhalten Sie eine Liste mit hoher CPU-Last auf drei Nodes, erhöhten Abfragezeiten in der Datenbank und steigenden Fehlerraten am API-Gateway. Das sind alles echte Signale. Keines davon zeigt jedoch, ob sich Nutzer anmelden oder einen Kauf abschließen können.

Im Incident-Channel beginnt dann eine Debatte über Prioritäten. Die einen vermuten, dass die CPU-Spitze die Datenbank ausbremst, die anderen halten eine langsame Abfrage für die Ursache der CPU-Last. Offen ist auch, ob Sie die Nodes skalieren oder die Abfrage optimieren sollten. Jemand schlägt vor, die Drittanbieter-API zu prüfen. Niemand weiß aber genau, ob sie im Monitoring erfasst ist, und selbst dann liegen die Daten in einem anderen Tool. Hier helfen einfache Outside-in-Checks, denn wenn ein grundlegender Login- oder Checkout-Pfad fehlschlägt, wissen Sie es vor dem zehnten Infrastruktur-Alert.

Bis Sie die Auswirkungen auf Kunden bestätigt haben, haben Ihre Kunden das oft schon für Sie erledigt.

Die Verwirrung ist systembedingt. Komponenten-Alerts beschreiben Symptome, zeigen aber nicht zuverlässig, was gefährdet ist. Servicebezogenes Monitoring kehrt die Reihenfolge um. Sie beginnen mit wenigen Signalen, die den Zustand des Service beschreiben, etwa Latenz, Fehler und Verfügbarkeit gemessen an Ihrem Zielwert. Anschließend verknüpfen Sie diese Signale mit den Abhängigkeiten, auf die der Service angewiesen ist. Wird der Checkout langsamer, sehen Sie sofort die Auswirkungen auf Kunden und erkennen, ob die wahrscheinliche Ursache bei Identity, Datenbanklatenz, Queue-Rückstau oder einer Drittanbieter-API liegt.

Mit servicebezogenem Monitoring ändert sich der Ausgangspunkt. Sie sehen, dass die Checkout-Latenz steigt und welche Abhängigkeiten beteiligt sind. Das Team hat damit eine klare Priorität und einen kürzeren Weg zur Ursachenanalyse. Komponenten-Monitoring bleibt wichtig. Es unterstützt die Servicesicht, damit Incidents nicht mit Detektivarbeit beginnen müssen.

3) Alertflut und zeitaufwendige Triage

Umgebungsübergreifende Incidents ziehen schnell mehrere Teams hinein. Das Anwendungsteam sieht Fehler, das Plattformteam sieht Pod-Neustarts. Das Datenbankteam bemerkt einen erschöpften Connection Pool, das Netzwerkteam sporadischen Paketverlust. Innerhalb weniger Minuten gehen nacheinander mehrere Alerts ein. Das Ausmaß der Auswirkungen über Provider, Cluster und On-Premises hinweg ist zu diesem Zeitpunkt noch unklar.

Jetzt haben Sie einen Slack- oder Microsoft-Teams-Channel mit acht Personen. Drei untersuchen dasselbe Symptom aus verschiedenen Blickwinkeln, ohne es zu merken. Zwei warten darauf, dass jemand bestätigt, ob das ihr Problem ist. Eine Person fragt, ob es mit dem Deployment von gestern zusammenhängt. Die Alerts laufen weiter ein, und die Diskussion verliert die Richtung. Es fehlt ein gemeinsames Bild davon, was bekannt ist und was nur Rauschen ist. Es wird schlimmer, wenn mehrere Monitoring-Tools dieselben Signale erfassen. Gleiches gilt, wenn das Monitoring bei gewöhnlichen Schwankungen zu viele Benachrichtigungen auslöst.

Ein wesentlicher Grund dafür ist, dass Alerts als ungefilterter Strom einzelner Benachrichtigungen eingehen. Sie erhalten vielleicht Dutzende Pages aus mehreren Systemen, ausgelöst durch ein einziges Problem, ohne Gruppierung und ohne Priorisierung. Die erste Phase des Incidents wird so zur manuellen Triage, das heißt Sortieren, Deduplizieren und Entscheiden, wer überhaupt dabei sein muss.

Deshalb fühlen sich selbst „einfache“ Ausfälle langsam an. Bevor Sie etwas beheben, setzen Sie erst einmal den Kontext zusammen.

Diese Verzögerung trifft genau die Kennzahlen, die für Sie zählen. Die Wiederherstellung dauert länger, Kunden spüren mehr Auswirkungen, und das Risiko einer SLA-Verletzung steigt. Der Grund ist, dass das Team die ersten Minuten mit dem Sortieren von Rauschen verbringt, statt die Ursache einzugrenzen. Das zermürbt auch die Menschen und führt zu Alert Fatigue, also Alarmmüdigkeit. Wenn der Pager ständig anschlägt und die Hälfte der Alerts irrelevant ist, verlieren Engineers das Vertrauen in das Signal. Das gilt selbst dann, wenn die nächste Page echt ist.

Das Problem liegt in der fehlenden Struktur rund um die Alerts. Teams arbeiten außerdem besser, wenn Alerts die Auswirkungen auf Kunden abbilden und über reine Komponenten-Schwellenwerte hinausgehen. So holen Sie nicht acht Personen wegen etwas zusammen, das nur bedrohlich aussieht. Gutes Alerting funktioniert eher wie ein Incident-Feed als wie eine Flut von Benachrichtigungen. Zusammengehörige Symptome werden zu einem Incident gebündelt. Neue Signale aktualisieren denselben Thread, statt neues Rauschen zu erzeugen. Das Team sieht, was ausgefallen ist, was betroffen ist und was bereits geprüft wurde. Auch die Zuständigkeit ist klarer, denn Alerts werden anhand des beeinträchtigten Service geroutet und weniger danach, welche Infrastruktur die meisten Alerts erzeugt. Hier zahlt sich Automatisierung schnell aus.

4) Spitzen bei Cloud-Kosten und schwache Feedbackschleifen

Cloud-Kosten sind ein operatives Signal. Im Pay-as-you-go-Modell, und selbst bei begrenzten On-Premises-Kapazitäten, summieren sich kleine Fehler schnell. Eine Skalierungsrichtlinie wird geändert und nicht wieder zurückgesetzt. Das Logging-Volumen verdoppelt sich über Nacht. Eine Testumgebung läuft weiter, weil niemand sie abgeschaltet hat. Ein Workload arbeitet ineffizient und verbraucht unbemerkt Rechenleistung. Manchmal verursacht das Monitoring selbst die Kostenspitze. Typische Ursachen sind hohe Log-Volumen im Log-Monitoring, doppelte Agents oder eine Datenerfassung, die über Provider und Umgebungen hinweg schleichend gewachsen ist.

Das Problem ist, dass Kosten und Performance oft in getrennten Welten liegen. Engineering beobachtet Dashboards und Alerts, Finance beobachtet die Abrechnung. Sind beide nicht verbunden, bricht die Feedbackschleife ab.

Ein typisches Muster sieht so aus. Ein deutlicher Kostenanstieg fällt erst Wochen später auf, und Ihre Billing-Konsole zeigt eine Spitze bei den Compute-Ausgaben in einer Region. Jemand durchsucht die Deployment-Historie und Konfigurationsänderungen nach Hinweisen. Der Engineer, der die Änderung vorgenommen hat, ist schwer erreichbar, und der Grund für die Änderung steckt in einem Ticket. Das System lief inzwischen so lange überdimensioniert, dass das Geld bereits weg ist. Das gilt besonders bei Spitzen durch Egress, Interconnect oder regionsübergreifenden Datenverkehr, denn diese Kosten tauchen weit entfernt vom auslösenden Service auf.

Das andere Muster ist Kapazität „für alle Fälle“. Teams behalten größere Instanzen und zusätzliche Reserven, weil niemand belegen kann, dass eine Reduzierung sicher ist. Alte Umgebungen bleiben bestehen, weil eine Stilllegung riskant wirkt, solange niemand nachweisen kann, dass nichts mehr von ihnen abhängt.

Dadurch führen Unsicherheiten häufig zu dauerhaft höheren Kosten. Kostenmanagement funktioniert besser, wenn es im gleichen Takt läuft wie der Betrieb. Ausgaben müssen zeitnah zur Änderung sichtbar sein. Außerdem muss sich die Änderung leicht auf etwas Konkretes zurückführen lassen, etwa ein Deployment, ein Skalierungsereignis, eine Logging-Anpassung oder eine vergessene Umgebung. Einige einfache Leitplanken machen einen großen Unterschied. Dazu gehören Budgets pro Umgebung, Alerts bei ungewöhnlichem Ausgabeverhalten und Tagging, das Kosten einem Service oder Verantwortlichen zuordnet. So kann das richtige Team schnell handeln.

Ein Überblick über die Kostenentwicklung hilft Teams, unerwartete Ausgaben frühzeitig zu erkennen. Schon eine einfache Sicht auf die Ausgabenentwicklung und die Prognose ohne Gegenmaßnahmen macht die Budgetplanung weniger reaktiv. Das reduziert auch die Hektik zum Monatsabschluss.

In der Praxis ist Rightsizing ein regelmäßiger Prozess, bei dem dauerhaft unterausgelastete Ressourcen identifiziert, ungenutzte oder verwaiste Umgebungen markiert und anschließend sichere Anpassungen mit einem entsprechenden Rollback-Plan vorgenommen werden. Dazu gehören beispielsweise Downsizing, die Einführung von Zeitplänen für Nicht-Produktivumgebungen oder das Abschalten tatsächlich ungenutzter Ressourcen.

Am besten funktioniert Rightsizing in Verbindung mit Cloud-Monitoring. Auslastung und Service-Zustand zeigen, was Sie gefahrlos reduzieren können und wo Änderungen riskant sind. Gut umgesetzt optimieren Sie Kosten, ohne Zuverlässigkeit einzubüßen, und unterstützen die Skalierbarkeit, weil Sie nicht überall Kapazität „für alle Fälle“ vorhalten. Liegt die Kostentransparenz direkt neben Auslastung und Service-Zustand, erkennen Sie Anomalien näher an ihrem Beginn und ordnen sie einer konkreten Änderung zu. Beim Rightsizing prüfen Sie die Auswirkungen anhand des realen Serviceverhaltens statt nach Bauchgefühl. So wird Kostenkontrolle vom periodischen Aufräumprojekt zur normalen Betriebsaufgabe.

5) Blinde Flecken im Internet-Stack

Einige der folgenreichsten Incidents für Ihr Unternehmen entstehen außerhalb Ihrer Cloud- und On-Premises-Umgebungen. Sie treten irgendwo auf dem Weg zwischen Nutzer und Service auf. Beispiele sind DNS, CDN-Verhalten, ISP-Routing, SASE-Richtlinien, Private Links oder eine Drittanbieter-API, bei der plötzlich Timeouts auftreten.

Während eines Incidents können Ihre internen Metriken unauffällig aussehen. Die Antwortzeiten der Datenbank sind normal, CPU und Arbeitsspeicher stabil. Auch die Fehlerraten in Ihrer primären Region steigen nicht. Gleichzeitig melden Nutzer in England langsame Ladezeiten, die sich in den USA nicht reproduzieren lassen.
Das Team geht vor wie üblich und schließt mögliche Ursachen nacheinander aus. Der Load Balancer ist in Ordnung, die Anwendungsschicht wirkt unauffällig, und die Datenbank zeigt keine offensichtliche Last. Danach dreht sich die Diskussion um Vermutungen wie „vielleicht ist es DNS“ oder „könnte das CDN sein“. Der Grund ist, dass Sie keine direkte Sicht auf diese Ebenen haben. Ein reales Beispiel zeigt das Muster. Ein Ausfall eines öffentlichen DNS-Resolvers kann so wirken, als sei Ihr Service down, obwohl Ihr Stack intakt ist. Beim Cloudflare-Vorfall rund um den Resolver 1.1.1.1löste eine Fehlkonfiguration einen globalen Rückzug von Routen aus. Die Folge waren plötzliche Erreichbarkeitsprobleme, die interne Dashboards für „Ihre“ Services allein nicht unbedingt erklären würden.

Hängt ein Service von einigen Drittanbieter-Endpunkten ab, sollten Sie grundlegende Health Checks und Eskalationswege vor dem nächsten Incident einrichten.

Stunden später meldet ein Provider vielleicht, dass er nichts Ungewöhnliches feststellt. Manchmal löst sich das Problem von selbst, und das Postmortem endet mit der vagen Kategorie „extern“, weil niemand belegen kann, was passiert ist. Genau hier liegt der Unterschied zwischen zwei Situationen. In der einen können Kunden keine Bestellungen aufgeben, und Sie wissen nicht, warum. In der anderen wissen Sie, wo der Ausfall begann, auch wenn die Ursache außerhalb Ihres Unternehmens liegt. 

Schon etwas Transparenz über den Internet-Stack liefert Ihnen konkrete Fakten für Provider und Kunden. Das verkürzt die Abstimmung und verhindert, dass der Incident ins Stocken gerät.

Wenn Sie die Nutzererfahrung außerhalb Ihrer Umgebung über den gesamten Internet-Stack messen, sehen Sie, wo die Beeinträchtigung beginnt und wen sie betrifft. Sie erkennen etwa, dass die Latenz aus Wien erhöht, aus Frankfurt aber normal ist. Ebenso sehen Sie, ob sich Fehler bei einem bestimmten ISP häufen. Sie können außerdem kritische Drittanbieter-Endpunkte im Blick behalten. So erkennen Sie Beeinträchtigungen, bevor daraus fehlgeschlagene Checkouts und Support-Tickets werden. Auch wenn die Behebung nicht in Ihrer Hand liegt, grenzen Sie die Untersuchung schneller ein und kommunizieren die Auswirkungen sicher gegenüber Providern und internen Teams.

6) Konfigurationsdrift und Monitoring-Lücken

Verteilte IT-Umgebungen verändern sich kontinuierlich. Accounts, Subscriptions und Projekte kommen hinzu, Cluster werden ersetzt, Services werden refaktoriert, und Zuständigkeiten verschieben sich bei Reorganisationen. Entwickelt sich das Monitoring nicht im gleichen Tempo weiter, bildet es nicht mehr ab, was tatsächlich läuft. In hybriden und Multi-Cloud-Setups ist das schwieriger. Legacy-Systeme passen nicht immer zu modernen Discovery-Mechanismen oder Namenskonventionen. Zudem ist die Zuständigkeit oft unklar, wenn das ursprüngliche Team weitergezogen ist.

Diese Diskrepanz zeigt sich meist mitten in einem Incident. Jemand öffnet das Dashboard, das das Team „immer nutzt“, und stellt fest, dass es veraltet ist. Neuere Abhängigkeiten fehlen, Systeme, die längst stillgelegt sein sollten, sind noch zu sehen, und beim Trennen von Signal und Rauschen hilft es kaum.

Die Drift zeigt sich auch im Hintergrund. Ein alter Alert feuert weiter, obwohl das zugrunde liegende System nicht mehr existiert. Ein neuer Service geht ohne Baseline live, weil niemand sicher war, was eingerichtet werden musste oder wer dafür zuständig war. Wenn Wochen später etwas ausfällt, hat das Team keine Historie zum Vergleich und keine Schwellenwerte, die normales Verhalten abbilden. Auch die Aufbewahrung spielt hier eine Rolle. Speichern Sie nicht genug Historie, um den Normalzustand vor einer Änderung zu sehen, fehlt Ihnen bei einer Rollback-Entscheidung eines der besten Werkzeuge.

Präzises Cloud-Monitoring braucht kontinuierliche Pflege. Je mehr davon manuell geschieht, desto eher bleibt etwas liegen. Das gilt besonders in Umgebungen mit häufigen Releases, in denen Cloud-Infrastruktur ständig ersetzt wird.

Monitoring bleibt stabiler, wenn Discovery und Onboarding fest im Workflow verankert sind. Neue Ressourcen werden automatisch erfasst und starten mit sinnvollen Standardeinstellungen. Baselines passen sich an, wenn sich Traffic-Muster ändern. Stillgelegte Systeme verschwinden aus Dashboards und Alerts, damit niemand Zeit verliert. Klare Standards dafür, was „im Monitoring erfasst“ bedeutet, leisten einen großen Beitrag, weil Teams den Prozess nicht bei jedem Release neu erfinden. Automatisierung sorgt dafür, dass dieser Workflow auch bei wachsender Umgebung funktioniert.

Fazit:

Hybride und Multi-Cloud-Umgebungen verändern sich schnell, mit neuen Accounts, Clustern, Abhängigkeiten und Verantwortlichen. Cloud-Monitoring bewährt sich, wenn es mit diesem Wandel Schritt hält und Teams bei Störungen gemeinsamen Kontext liefert. Dazu gehören die Service-Ebene, Abhängigkeiten außerhalb Ihrer Umgebung und operative Grundlagen wie Zuständigkeiten, Aufbewahrung und Leitplanken, die das Monitoring dauerhaft vertrauenswürdig halten.

Dadurch lassen sich Incidents schneller bearbeiten, weil Sie die Zeitachse nicht von Grund auf neu aufbauen. Releases wirken weniger riskant, weil Sie Auswirkungen früh erkennen. Entscheidungen zu Kosten, Performance und Zuverlässigkeit fallen leichter, weil die Daten konsistent genug sind, um ihnen zu vertrauen.

Ein guter Test ist Ihr letzter größerer Incident. Wenn Sie die ersten 30 Minuten damit verbracht haben, Daten abzugleichen und über den Umfang zu diskutieren, wissen Sie, was Sie als Nächstes verbessern sollten.

FAQs