Was sollte man bei einer Website und Anwendung überwachen? Eine praktische Liste von Uptime bis zu Fehlern und Performance

CPU, RAM, Load Average, Container, Prozesse, Anfragen, Fehler, Logs, Queues, Datenbanken, DNS, SSL, APIs, Uptime, Antwortzeiten, Core Web Vitals und vieles mehr.

Das Problem ist, dass mehr überwachte Metriken nicht automatisch besseres Monitoring bedeuten.

In der Praxis ist es am wichtigsten, Probleme zu erkennen, die sich tatsächlich auf Benutzer oder das Geschäft auswirken.

Deshalb sollte man nicht mit der Frage beginnen:

„Was können wir messen?“

Sondern besser fragen:

„Von welchen Problemen möchten wir erfahren, bevor uns ein Kunde darauf aufmerksam macht?“

1. Funktioniert die Website überhaupt?

Das ist die grundlegendste Ebene des Monitorings.

Ein externes System sendet regelmäßig eine Anfrage an die Website und überprüft, ob es eine korrekte Antwort erhält.

So lassen sich unter anderem folgende Probleme erkennen:

• HTTP 500,
• HTTP 502,
• HTTP 503,
• Timeouts,
• fehlgeschlagene Verbindungsversuche,
• DNS-Probleme,
• fehlerhafte Weiterleitungen.

Das ist klassisches Uptime-Monitoring.

Wenn die Website jede Minute überprüft wird, kann ein Problem potenziell innerhalb von etwa einer Minute erkannt werden, anstatt darauf zu warten, dass jemand zufällig die Website besucht und den Ausfall meldet.

Uptime allein ist jedoch nur der Anfang.

2. Antwortet die Website schnell genug?

Eine Website kann verfügbar und gleichzeitig sehr langsam sein.

Deshalb sollte bei jeder Überprüfung auch die Antwortzeit gespeichert werden.

Nehmen wir an, eine Anwendung antwortet normalerweise innerhalb von:

250-400 ms

Plötzlich steigt die Antwortzeit auf:

1.8-3.5 s

Es gibt noch keinen vollständigen Downtime.

Das Verhalten des Systems hat sich jedoch deutlich verändert.

Mögliche Ursachen sind:

• Serverüberlastung,
• Probleme mit der Datenbank,
• eine langsame externe API,
• keine verfügbaren Worker mehr,
• Probleme mit dem Cache,
• eine Änderung nach dem letzten Deployment.

Das Monitoring der Antwortzeit kann ein Problem daher früher erkennen als eine klassische Warnmeldung über die Nichtverfügbarkeit.

3. Ist die Verschlechterung vorübergehend oder dauerhaft?

Eine einzelne langsamere Anfrage muss noch kein Problem bedeuten.

Das Internet ist keine vollständig deterministische Umgebung.

Deshalb sollte man nicht auf jede einzelne Anomalie reagieren, sondern das Verhalten über einen längeren Zeitraum analysieren.

Zum Beispiel:

10:00 - 320 ms
10:01 - 340 ms
10:02 - 310 ms
10:03 - 870 ms
10:04 - 350 ms

Ein einzelner Wert von 870 ms ist wahrscheinlich noch kein Grund für eine Warnmeldung.

Aber:

10:00 - 320 ms
10:01 - 510 ms
10:02 - 840 ms
10:03 - 1.3 s
10:04 - 2.1 s
10:05 - 3.4 s

zeigt bereits einen deutlichen Trend.

Gutes Monitoring sollte dabei helfen, eine vorübergehende Abweichung von einer tatsächlichen Verschlechterung des Dienstes zu unterscheiden.

4. Ist das SSL-Zertifikat gültig?

Das SSL-Zertifikat gehört zu den einfachsten Elementen, die überwacht werden können.

Gleichzeitig gehört es zu den Dingen, die sehr leicht vergessen werden.

Ein Problem mit dem Zertifikat kann dazu führen, dass der Benutzer anstelle der Website eine Sicherheitswarnung sieht.

Bei einem Onlineshop oder einer Anwendung kann dies den Zugriff praktisch vollständig verhindern.

Deshalb sollte das Monitoring überprüfen:

• ob das Zertifikat gültig ist,
• wann es abläuft,
• ob die Domain des Zertifikats korrekt ist,
• ob eine HTTPS-Verbindung korrekt hergestellt werden kann.

Der wichtigste Vorteil eines solchen Monitorings ist die Möglichkeit, vor einem Ausfall zu reagieren.

Man muss nicht warten, bis das Zertifikat tatsächlich abläuft.

Eine Warnmeldung kann rechtzeitig vorher ausgelöst werden.

5. Erzeugt die Anwendung Fehler?

Externes Monitoring zeigt die Anwendung aus der Perspektive des Benutzers.

Fehlermonitoring zeigt sie von innen.

Wenn eine Anwendung eine Ausnahme erzeugt:

PaymentException

oder:

DatabaseConnectionException

sollte man davon erfahren - unabhängig davon, ob die Homepage weiterhin den Statuscode 200 zurückgibt.

Auch die Fehlermeldung allein reicht häufig nicht aus.

Wesentlich hilfreicher ist der Kontext:

• wo der Fehler aufgetreten ist,
• wann er zum ersten Mal aufgetreten ist,
• wann er zuletzt aufgetreten ist,
• wie oft er aufgetreten ist,
• welche Version der Anwendung bereitgestellt war,
• welcher Endpoint ausgeführt wurde,
• wie der Stack Trace aussieht,
• ob die Anzahl der Fehler zunimmt.

So kommt man von: „Wir haben einen Fehler“ zu: „Wir wissen, wo wir mit der Suche beginnen können.“

6. Nicht jeder Fehler ist gleich wichtig

Nehmen wir an, das System hat zwei Ausnahmen registriert.

Die erste:

5 Vorkommnisse innerhalb von 30 Tagen

Die zweite:

5.000 Vorkommnisse innerhalb der letzten 20 Minuten

Technisch können beide genau denselben Ausnahmetyp darstellen.

Aus operativer Sicht handelt es sich jedoch um völlig unterschiedliche Situationen.

Deshalb ist beim Fehlermonitoring nicht nur die Information wichtig:

„Welcher Fehler ist aufgetreten?“

sondern auch:

„Wie verändert sich die Häufigkeit seines Auftretens?“

Ein plötzlicher Anstieg der Fehlerzahl nach dem Deployment einer neuen Version kann wesentlich wichtiger sein als die bloße Tatsache, dass eine bestimmte Ausnahme existiert.

7. Hat das Deployment einer neuen Version etwas beschädigt?

Eine der wertvollsten Einsatzmöglichkeiten des Monitorings ist die Beobachtung einer Anwendung direkt nach einem Deployment.

Stellen wir uns Folgendes vor:

14:02 - Deployment Version 2.18.4
14:05 - erste neue Fehler
14:07 - 120 Fehler
14:10 - 640 Fehler

Ohne Informationen über die Anwendungsversion sehen wir lediglich einen Anstieg der Fehlerzahl.

Wenn das Monitoring den Release kennt, erhalten wir wesentlich mehr Kontext:

Die Probleme begannen wenige Minuten nach dem Deployment der Version 2.18.4.

Das bedeutet nicht automatisch, dass das Deployment die Ursache ist.

Es ist jedoch ein sehr wichtiger diagnostischer Hinweis.

8. Ist die Website für den Benutzer schnell?

Die Antwortzeit des Servers und die Geschwindigkeit der Website im Browser sind nicht dasselbe.

Der Server kann das HTML innerhalb von 150 ms zurückgeben, während die Website weiterhin Folgendes lädt:

• große Bilder,
• JavaScript,
• Schriftarten,
• Werbung,
• Analyseskripte,
• externe Widgets.

Deshalb lohnt es sich, auch die Performance der Website zu überwachen.

Ein etablierter Referenzpunkt sind die Core Web Vitals.

LCP - Largest Contentful Paint

Misst, wie schnell das größte sichtbare Inhaltselement der Seite erscheint.

INP - Interaction to Next Paint

Misst die Reaktionsfähigkeit der Website nach einer Benutzerinteraktion.

Das Klicken auf eine Schaltfläche, die Auswahl einer Option oder die Eingabe von Daten kann wie ein Fehler wirken, wenn der Browser mit großer Verzögerung reagiert.

Als guter INP-Wert gelten bis zu 200 ms beim 75. Perzentil.

CLS - Cumulative Layout Shift

Misst unerwartete Verschiebungen von Elementen während der Nutzung einer Website.

Zum Beispiel möchte ein Benutzer auf folgende Schaltfläche klicken:

Jetzt kaufen

Doch kurz vor dem Klick wird darüber ein Banner geladen und die Schaltfläche verschiebt sich an eine andere Stelle.

Genau solche Probleme hilft CLS zu messen.

9. Warum sollte die Performance regelmäßig überwacht werden?

Ein einmaliger PageSpeed-Test ist hilfreich.

Eine Website bleibt jedoch nicht unverändert.

Es können hinzukommen:

• ein neuer Banner,
• ein neues Marketingskript,
• ein zusätzlicher Analyse-Tag,
• eine neue Version der Anwendung,
• eine neue JavaScript-Bibliothek,
• größere Produktbilder,
• geänderte Schriftarten,
• ein neues Chat-Widget.

Jede dieser Änderungen kann die Performance verschlechtern.

Deshalb ist die Frage:

„Verschlechtert sich die Performance unserer Website im Laufe der Zeit?“

deutlich interessanter als:

„Welchen PageSpeed-Wert haben wir heute?“

Monitoring macht diesen Trend sichtbar.

10. Sollte man nur die Startseite überwachen?

In den meisten Fällen nicht.

Die Startseite ist normalerweise nur einer von vielen Seitentypen.

Bei einem Onlineshop kann es sinnvoll sein, folgende Seiten zu überwachen:

/
/product/example
/category/example
/cart
/checkout

Bei einer SaaS-Anwendung:

/
/login
/register
/dashboard

sowie die wichtigsten API-Endpoints.

Es geht nicht darum, jede URL auf die gleiche Weise zu überwachen.

Es geht darum, repräsentative kritische Punkte auszuwählen.

11. Was sollte man bei einem Onlineshop überwachen?

Eine sinnvolle Grundausstattung kann Folgendes umfassen:

Verfügbarkeit des Onlineshops

Antwortet der Onlineshop?

Antwortzeit

Ist der Onlineshop plötzlich deutlich langsamer geworden?

SSL

Ist das Zertifikat gültig und nähert sich das Ablaufdatum nicht zu schnell?

Anwendungsfehler

Erzeugen WooCommerce, PrestaShop oder ein individuelles Backend neue Fehler?

Checkout

Ist der kritische Teil des Kaufprozesses verfügbar?

Performance

Haben sich Core Web Vitals und andere Performance-Werte nach Änderungen verschlechtert?

Kritische Integrationen

Wenn der Verkauf von externen Diensten abhängt, können Probleme auch Folgendes betreffen:

• Zahlungen,
• ERP,
• Lagerverwaltungssysteme,
• Versanddienstleister,
• Marktplätze,
• externe APIs.

Ein Onlineshop kann technisch funktionieren und gleichzeitig nicht in der Lage sein, Bestellungen korrekt abzuwickeln.

12. Was sollte man bei einer SaaS-Anwendung überwachen?

Bei SaaS-Anwendungen können die Prioritäten etwas anders aussehen.

Es lohnt sich, Folgendes zu überwachen:

• die öffentliche Website,
• die Anmeldung,
• die API,
• Backend-Fehler,
• die wichtigsten Geschäftsprozesse,
• Antwortzeiten,
• Hintergrundaufgaben,
• Queues,
• externe Integrationen,
• SSL,
• Frontend-Performance.

Besonders wichtig ist das Monitoring der Funktionen, für die der Benutzer tatsächlich bezahlt.

Wenn das Dashboard funktioniert, aber die Hauptfunktion des Produkts ausgefallen ist, liegt aus geschäftlicher Sicht ein schwerwiegender Ausfall vor.

13. Monitoring sollte Fragen beantworten und nicht nur Daten produzieren

Es ist leicht, ein Dashboard zu erstellen mit:

47 Diagrammen
23 Metriken
15 Statuswerten
8 Tabellen

und trotzdem nicht zu wissen, ob die Anwendung korrekt funktioniert.

Gutes Monitoring sollte es ermöglichen, schnell einige einfache Fragen zu beantworten:

• Funktioniert die Anwendung?
• Ist sie so schnell wie gewöhnlich?
• Sind neue Fehler aufgetreten?
• Ist die Anzahl der Fehler plötzlich gestiegen?
• Ist das Zertifikat gültig?
• Hat sich die Performance der Website verschlechtert?
• Funktionieren die wichtigsten Geschäftsfunktionen?

Wenn das Monitoring nicht dabei hilft, diese Fragen zu beantworten, lösen mehr Daten das Problem nicht unbedingt.

14. Womit sollte man beginnen?

Man muss nicht sofort ein umfangreiches Observability-System aufbauen.

Für viele Websites und Anwendungen ist das Monitoring von vier Bereichen ein sinnvoller Anfang:

1. Uptime - ist der Dienst verfügbar?
2. Fehler - erzeugt die Anwendung Ausnahmen und nimmt deren Anzahl zu?
3. SSL - ist das Zertifikat gültig und nähert sich sein Ablaufdatum?
4. Performance - ist die Website weiterhin so schnell wie zuvor?

Erst danach können je nach Art der Anwendung detailliertere Monitoring-Mechanismen ergänzt werden.

Die wichtigste Regel beim Monitoring

Monitoring sollte nicht nur existieren, damit man ein Dashboard hat.

Es sollte die Zeit verkürzen zwischen dem Auftreten eines Problems und dem Zeitpunkt, an dem die richtige Person davon erfährt.

Noch besser ist es, wenn eine Verschlechterung erkannt werden kann, bevor es zu einem vollständigen Ausfall kommt.

Das schlimmste Szenario ist nicht immer eine Anwendung, die vollständig ausgefallen ist.

Manchmal ist eine Anwendung wesentlich problematischer, die seit mehreren Stunden nicht korrekt funktioniert, während ihr Betreiber noch nichts davon weiß.