Wenn Sie SaaS-Anwendungen betreiben, wissen Sie bereits, dass deren Überwachung eine Herausforderung ist. Ihre Server laufen vielleicht gut, aber Benutzer in verschiedenen Regionen beschweren sich über Verlangsamungen. Oder alles scheint in Ordnung zu sein, bis Sie feststellen, dass Ihr Zahlungsabwickler seit einer Stunde nicht mehr reagiert. Zwischen CDNs, Browser-Macken und Diensten von Drittanbietern gibt es viele Stellen, an denen etwas schief gehen kann.
In diesem Leitfaden wird erläutert, wie Sie eine SaaS-Anwendungsüberwachung einrichten, die Probleme präventiv erkennt und schnell auf mögliche Ursachen hinweist. Der Schwerpunkt des Leitfadens liegt auf Anwendungsleistung, Verfügbarkeit und Benutzerfreundlichkeit und nicht auf Sicherheit. Sie finden hier konkrete Schritte, um Probleme frühzeitig zu erkennen, wichtige Daten zu messen und die Überwachung auch bei wachsenden Anwendungen überschaubar zu halten.
Zusammenfassung der wichtigsten Best Practices für die Überwachung von SaaS-Anwendungen
Implementierung der synthetischen Überwachung
Wenn Sie sich nur darauf verlassen, dass Probleme gelöst werden, nachdem die Benutzer sie gemeldet haben, kann es zu spät sein, um einen guten ersten Eindruck oder das Vertrauen der Benutzer zu retten. An dieser Stelle kommen synthetische Tests ins Spiel. Dabei handelt es sich um skriptgesteuerte Tests, die echte Benutzerinteraktionen nachahmen, um Probleme zu erkennen, bevor die Benutzer sie bemerken.
Der Schlüssel zu synthetischen Tests sind Tests von verschiedenen geografischen Standorten aus, an denen Ihre Kunden ansässig sind. Wenn sich die meisten Ihrer Kunden in Europa befinden, Sie aber nur von US-Rechenzentren aus testen, verpassen Sie das komplette Bild. Catchpoint bietet ein globales Knotennetzwerk, mit dem Sie Tests an verschiedenen Standorten auf der ganzen Welt durchführen können, wobei Sie denjenigen den Vorrang geben, die für Ihren Nutzerstamm sinnvoll sind.
Richten Sie diese Tests für Ihre wichtigsten Benutzerabläufe ein. Wenn es sich bei Ihrer Anwendung zum Beispiel um ein CRM handelt, würde das bedeuten, dass Sie Dinge wie Benutzeranmeldung und -authentifizierung, das Erstellen von Kontakten, das Ausführen von Berichten oder was auch immer Ihre Benutzer am häufigsten tun, testen. Führen Sie diese Tests auch zu unterschiedlichen Zeiten durch - was um 3 Uhr morgens problemlos funktioniert, kann zu Stoßzeiten zu viel größeren Latenzen führen.
Echte Nutzer einsetzen und Rauchtests durchführen
Synthetische Tests sind großartig, aber manchmal kann man nicht alle möglichen Szenarien berücksichtigen, die ein Benutzer erleben könnte. In der Praxis kann es vorkommen, dass Benutzer langsame Verbindungen haben, seltsame Browser-Versionen verwenden oder versuchen, Ihre App auf ihrem Telefon zu laden, während sie im Zug sitzen.
Um die Anwendungsleistung wirklich zu verstehen und zu verbessern, benötigen Sie Erkenntnisse sowohl aus der realen Benutzerüberwachung (RUM) als auch aus der synthetischen Überwachung. Wenn Sie sich nur auf eine Quelle verlassen, erhalten Sie ein unvollständiges Bild. RUM gibt Aufschluss darüber, wie Benutzer Ihre Website tatsächlich erleben, während die synthetische Überwachung proaktiv potenzielle Probleme aufdeckt, bevor sie sich auf die Benutzer auswirken.
Sie denken vielleicht, dass Ihre App rasend schnell ist, weil Ihre synthetischen Tests gut aussehen, aber die RUM-Daten zeigen vielleicht, dass Nutzer in Südamerika durchweg ein schreckliches Erlebnis haben. Oder jeder, der Safari verwendet, stößt auf JavaScript-Fehler, die in Ihren Chrome-basierten Tests nicht auftauchen.
Behalten Sie das im Auge:
- Wie lange brauchen die Seiten zum Laden?
- Wo Ihr JavaScript erstickt
- Netzwerk-Timing-Probleme
- Fehler, auf die Benutzer stoßen, die sie aber nie melden
- Browser- und Gerätemuster
- Geografische Leistungsunterschiede
- Benutzerpfade, die Ihre synthetischen Tests nicht gefunden haben
- Mobilfunkspezifische Metriken wie Ladezeit der App und Netzwerkübergänge
Smoke-Tests können ebenfalls sehr aufschlussreich sein, da sie nach der Bereitstellung als Sicherheitsnetz dienen. Dabei handelt es sich um schnell durchzuführende Überprüfungen der Kernfunktionen, die sicherstellen, dass nichts Offensichtliches defekt ist. Können sich Benutzer zum Beispiel anmelden, Datensätze erstellen und auf die wichtigsten Funktionen zugreifen? Wenn diese Funktionen nicht funktionieren, liegt ein schwerwiegender Fehler vor, und Ihr Team sollte sofort alarmiert werden.
Das Wichtigste bei Smoke-Tests ist, dass sie sich auf die Zuverlässigkeit über verschiedene Umgebungen und Geräte hinweg konzentrieren. Wenn Ihre SaaS-Anwendung sowohl den Desktop- als auch den mobilen Zugriff unterstützt, planen Sie die Tests so, dass sie kritische Funktionen in beiden Umgebungen abdecken, um eine konsistente Zuverlässigkeit zu gewährleisten, unabhängig davon, wie sich die Benutzer verbinden. Testen Sie die kritischen Funktionen, machen Sie die Tests robust, und stellen Sie sicher, dass Fehler offensichtlich und umsetzbar sind. Wenn ein Smoke-Test fehlschlägt, sollte jeder genau wissen, was nicht funktioniert hat und was als erstes überprüft werden muss.
Moderne Monitoring-Tools werden immer umfangreicher, um die gesamte Bandbreite der Nutzererfahrungen zu erfassen. Zum Beispiel bietetCatchpoint jetzt mobiles Real User Monitoring mit OpenTelemetry-Unterstützung, damit Sie genau sehen können, wie Ihre mobilen Nutzer Ihre App erleben. Die Plattform hilft auch bei der Verfolgung neuer Frustrationsmetriken wie Wutklicks (wenn Benutzer aus Frustration wiederholt auf dieselbe Stelle klicken), tote Klicks (Klicks, die keine Reaktion auslösen) und unregelmäßige Cursorbewegungen - alles verräterische Anzeichen dafür, dass Benutzer sich mit Ihrer Benutzeroberfläche schwer tun.
Sicherstellung des API-Zustands und Implementierung einer verteilten Rückverfolgung
APIs gehören oft zu den ersten Dingen, die kaputt gehen, und zu den letzten, die bemerkt werden. Es ist wichtig, zu überwachen, wie oft Ihre APIs komplett ausfallen und wann sie zu langsam laufen, um nützlich zu sein. Eine langsame API löst vielleicht keine Fehler aus, beeinträchtigt aber die Benutzerfreundlichkeit.
Die API-Überwachung ist mit Microservices komplexer geworden. Es reicht nicht mehr aus, zu prüfen, ob ein Endpunkt 200 OK zurückgibt. Überwachungsteams müssen Antwortzeiten überprüfen, Payloads auf ihre Genauigkeit hin überprüfen und die API-Leistung aus verschiedenen Regionen überwachen.
Mit der API-Überwachungslösung von Catchpoint können Sie die Funktionalität und Leistung Ihrer APIs über mehrere geografische Standorte hinweg validieren. Sie erkennt Probleme, die nur in bestimmten Regionen oder unter bestimmten Netzwerkbedingungen auftreten können. Dank der Fähigkeit der Plattform, mehrstufige API-Transaktionen auszuführen, können Sie komplexe Benutzerströme testen, die sich über mehrere Endpunkte erstrecken, was für moderne SaaS-Anwendungen entscheidend ist.
Intelligente API-Überwachung verlangt von Ihnen, dass Sie:
- Prüfen Sie die Reaktionszeiten von mehreren Standorten aus
- Überprüfen Sie, ob der Inhalt sinnvoll ist, nicht nur der Statuscode
- Achten Sie auf Muster - ist es zu bestimmten Zeiten langsam? Von bestimmten Orten aus?
- Stellen Sie sicher, dass Ihre Drittanbieter-APIs Sie nicht im Stich lassen.
Verteilte Rückverfolgung
Bei der Fehlersuche in einer "langsamen Anwendung" kann es schwierig sein, das Problem genau zu bestimmen. Verteiltes Tracing ist eine Technik, mit der Sie eine bestimmte Anfrage verfolgen können, während sie zwischen den Diensten durchläuft, und genau sehen, wo Verzögerungen auftreten. Sie können damit Szenarien identifizieren, z. B. wenn eine API schnell antwortet, aber auf eine Datenbankabfrage wartet oder ein Drittanbieterdienst ewig braucht, um zu antworten.
Sie müssen auch wissen, wie "normal" für Ihr System aussieht. Wenn ein API-Endpunkt normalerweise in 100 ms antwortet, ist ein Sprung auf 300 ms eine Untersuchung wert, auch wenn viele Überwachungssysteme diese Werte für akzeptabel halten. Legen Sie Ihre Basislinien auf der Grundlage tatsächlicher Nutzungsmuster fest, nicht auf der Grundlage willkürlicher Zahlen.
Die Stack Map-Visualisierung vonCatchpoint erweckt dieses Konzept zum Leben, indem sie eine klare, interaktive Karte Ihres gesamten Internet-Stacks liefert, der herkömmlichen APM-Tools oft verborgen bleibt. So wissen Sie genau, wie jede Komponente - von DNS und CDN bis hin zu Drittanbieterdiensten und clientseitigem JavaScript - zur Leistung Ihrer Anwendung beiträgt. Die automatisch erstellten Karten zeigen auch Leistungsengpässe bei Ihren Anwendungen und Diensten auf, um eine schnelle Fehlerbehebung zu ermöglichen.
Festlegung relevanter SLOs und Metriken
Service Level Objectives (SLOs) sollten auf Kennzahlen beruhen, die für Ihre Benutzer und das allgemeine Benutzererlebnis tatsächlich von Bedeutung sind. Prioritäten setzen:
- Wie schnell sich Tastenaktionen für die Benutzer anfühlen (nicht nur, wie schnell sie tatsächlich sind)
- Wie häufig treten Fehler bei der Ausführung zentraler Aktionen auf?
- ob wichtige Funktionen bei Bedarf verfügbar sind
- Reaktionszeiten für einkommensschaffende Maßnahmen
Setzen Sie realistische Ziele und verfeinern Sie diese später. Die SLO-Ziele sollten je nach Bedeutung der Funktion strenger sein. Zum Beispiel sollte die Zahlungsabwicklung immer strengere SLOs haben als die Berichterstellung.
Der wirkliche Wert von SLOs ergibt sich aus der zeitlichen Entwicklung der Werte. Stellen Sie größere Schwankungen bei den Antwortzeiten fest? Werden die SLOs an manchen Tagen erfüllt und an anderen nicht? Diese Trends weisen auf zugrundeliegende Probleme hin, bevor sie zu ernsthaften Problemen werden.
Überprüfen Sie Ihre SLOs regelmäßig. Was vor einiger Zeit noch wichtig erschien, ist heute vielleicht nicht mehr wichtig, und es könnten sich neue kritische Pfade ergeben haben. Dies gilt insbesondere, wenn Sie häufig Aktualisierungen durchführen - neue Funktionen bedeuten oft neue Dinge, die überwacht werden müssen.
Automatisieren Sie Warnmeldungen und Berichte
Eine Sache, die vielleicht offensichtlich ist, ist die Notwendigkeit, Teams zu alarmieren, wenn etwas schief gelaufen ist. Der Schlüssel liegt jedoch darin, zu entscheiden, was es bedeutet, dass etwas "schief gelaufen" ist, und eine intelligente Alarmierungsstrategie zu haben, damit Ihr Team nicht vom Lärm überwältigt wird und möglicherweise die wichtigsten Meldungen verpasst.
Intelligente Alarmierung bedeutet:
- Klare Schweregrade, die jeder versteht
- Jede Ausschreibung hat einen Besitzer
- Jede Warnung liefert genügend Kontext, um das Problem zu lösen (z. B. Links zu Protokollen oder Dashboards)
- Vorher festgelegte Schwellenwerte auf der Grundlage der tatsächlichen Auswirkungen
- Gut definierte Eskalationspfade
Die besten Warnmeldungen enthalten auch Runbooks, die als einfache Anweisungen dafür dienen können, was zuerst zu prüfen ist. Etwas so Einfaches wie "Überprüfen Sie zuerst X, dann Y; häufige Ursachen sind Z" kann bei einem Ausfall wertvolle Minuten sparen. Runbooks verhindern auch Wissenssilos und verringern den Bedarf an Experten auf Abruf.
Integration der Überwachung in den DevOps-Prozess
Integrieren Sie die Überwachung von Anfang an in Ihren Entwicklungsprozess. Behandeln Sie Ihre Überwachungskonfigurationen wie Code - versionskontrolliert, geprüft und zusammen mit Ihrer Anwendung bereitgestellt. Überwachung als Code-Ansatz bedeutet:
- Ihre Überwachungseinrichtung ist dokumentiert und nachvollziehbar
- Änderungen werden genau wie Codeänderungen überprüft
- Sie können Überwachungsänderungen bei Bedarf zurücknehmen
- Neue Umgebungen erhalten automatisch die richtige Überwachung
- Jeder kann zur Verbesserung der Überwachung beitragen
Integrieren Sie die Überwachung in Ihre CI/CD-Pipeline, um sie vor der Übergabe an die Produktion zu überprüfen. Prüfen Sie das:
- Neue Funktionen haben eine angemessene Überwachung
- Warnungen sind korrekt konfiguriert
- Dashboards werden für neue Metriken aktualisiert
- Alte Überwachungen, die nicht mehr relevant sind, werden entfernt.
In vielen Fällen können CI/CD-Pipelines auch eine Form von Canary-Tests und Überwachung beinhalten. Starten Sie einen Container mit dem neuesten Code und leiten Sie einen kleinen Prozentsatz des echten Datenverkehrs. Wenn diese Pod-Umgebung nach einiger Zeit keine Alarme auslöst, können Sie sicher sein, dass der Code einsatzbereit ist.
Abhängigkeiten von Drittanbietern überwachen
Dienste von Drittanbietern können Sie davor bewahren, alles selbst zu entwickeln, aber jeder Dienst ist ein potenzieller Fehlerpunkt. Wenn Abhängigkeiten versagen, ist es Ihren Nutzern egal, dass es nicht Ihre Schuld war - sie nehmen Ihre App einfach als fehlerhaft wahr.
Die Überwachung von Abhängigkeiten beinhaltet:
- Überwachung der Antwortzeiten von APIs Dritter
- Einrichtung von Ausweichoptionen, wo immer möglich
- Verfolgung der Betriebszeitversprechen im Vergleich zur Realität
- Verstehen, welche Dienste ausfallen können, ohne die gesamte Anwendung zu beeinträchtigen
- Pläne für den Fall, dass kritische Dienste ausfallen
Es ist auch ratsam, Unterbrecher in Ihre Anwendung einzubauen. Wenn ein Dienst eines Drittanbieters zu einem Engpass wird, können Sie dies erkennen und die Weiterleitung von Anfragen, die wahrscheinlich weiterhin fehlschlagen werden, stoppen. Zwischenspeichern Sie, was Sie problemlos abbauen können, und stellen Sie sicher, dass Sie Änderungen schnell bereitstellen können, wenn der Dienst komplett ausfällt.
Am wichtigsten ist, dass Sie verfolgen, welche Funktionen von welchen Diensten abhängen. Wenn etwas schief geht, sollten Sie sofort wissen, welche Teile Ihrer Anwendung betroffen sein könnten. Diese Abhängigkeitszuordnung ist entscheidend für die Fehlerbehebung und die Planung künftiger Architekturänderungen.
Eine gute Faustregel ist, dass Sie über jeden Drittanbieterdienst Bescheid wissen sollten:
- Wie sich Ihre Anwendung verhält, wenn sie langsam ist
- Wie sich Ihre Anwendung verhält, wenn sie ausfällt
- Wie Sie feststellen können, ob es zu Problemen kommt
- Welche Möglichkeiten Sie haben, wenn es nicht klappt
- Wie man den Support kontaktiert (und die SLA für Antworten)
Internet Sonar vonCatchpoint nutzt das weltweit größte und zuverlässigste intelligente Agentennetzwerk, um in Echtzeit Einblicke in Internetausfälle zu geben, die die Leistung Ihrer Anwendung beeinträchtigen könnten. Die Sichtbarkeitsdaten versorgen die Internet Stack Maps von Catchpoint mit Energie, um automatisch visuelle Darstellungen der Abhängigkeiten Ihrer Anwendung zu erstellen, einschließlich externer Dienste. Wenn Probleme auftreten, können Sie die interne oder externe Quelle schnell ausfindig machen und Ihre mittlere Zeit bis zur Lösung (MTTR) drastisch reduzieren.
Schlussfolgerungen
Die Einrichtung einer guten Überwachung kostet Zeit, aber die Mühe lohnt sich. Der wahre Wert der Überwachung zeigt sich erst Monate später, wenn Sie herausfinden wollen, warum die Leistung schlechter ist als früher oder ob die neue Funktion geholfen hat. Behalten Sie die Metriken, die sich als nützlich erwiesen haben, und lassen Sie diejenigen, die nur Rauschen verursachen, ruhig weg.
Sorgen Sie dafür, dass Ihre Grundlagen funktionieren, um kritische Probleme rechtzeitig zu erkennen und ihre Auswirkungen zu minimieren. Ihre Überwachung wird jedoch nie "fertig" sein, und das sollte sie auch nicht. Solange sich Ihre Anwendung ändert, muss auch Ihre Überwachung Schritt halten. Nutzen Sie die Erkenntnisse, die Sie aus Vorfällen und Benutzerbeschwerden gewinnen, um Ihre nächste Überwachungsinitiative zu steuern.
Buchen Sie hier eine Demo, um mehr darüber zu erfahren, wie die Internet Performance Monitoring (IPM) Plattform von Catchpoint die Ausfallsicherheit Ihres Internet Stacks mit einem tiefen Einblick in jeden Aspekt des Internets gewährleistet.
