Wie viele Fehlerdaten brauchen Sie beim Anwendungsmonitoring wirklich?
Beim Monitoring kann man leicht in die Falle geraten zu glauben, dass mehr Daten immer besseres Monitoring bedeuten. Jeder Stack Trace, jede Anfrage und jede Transaktion kann den Eindruck erwecken, dass sie dauerhaft gespeichert werden sollte.
In der Praxis hat die langfristige Speicherung aller Rohdaten jedoch ihren Preis. Die Datenmenge wächst, die Speicherkosten steigen und die Analyse historischer Informationen wird zunehmend schwieriger.
Deshalb sollte ein gut konzipiertes Monitoring zwischen Daten unterscheiden, die zur Lösung eines konkreten Problems benötigt werden, und Daten, die langfristige Trends sichtbar machen sollen.
Wozu dienen Rohdaten?
Ein einzelnes Rohereignis ist besonders wertvoll, wenn Sie die Frage beantworten möchten: „Was genau ist in der Anwendung passiert?“
Stack Trace, Fehlermeldung, Anfrageadresse, Umgebung und zusätzlicher Kontext helfen dabei, die Ursache eines Problems zu finden und die Situation nachzuvollziehen. Diese Daten werden vor allem bei der Analyse eines konkreten Fehlers benötigt.
In der Regel benötigen Sie jedoch keinen vollständigen Stack Trace von vor zwei Jahren, um festzustellen, ob Ihre Anwendung in diesem Monat stabiler lief als noch vor sechs Monaten.
Rohdaten und Statistiken erfüllen unterschiedliche Anforderungen
Deshalb lohnt es sich, die Aufbewahrung detaillierter Daten von der Historie der Statistiken zu trennen.
Rohereignisse können für einen begrenzten Zeitraum gespeichert werden. Während dieser Zeit haben Sie Zugriff auf die für die Fehlersuche erforderlichen Details: Fehlermeldung, Stack Trace und Kontext der Anfrage.
Gleichzeitig können grundlegende Informationen über längere Zeiträume aggregiert werden. Statt eine Million einzelner Ereignisse zu speichern, genügt beispielsweise die Information, dass an einem bestimmten Tag 12.438 Fehler aufgetreten sind.
Was sollte in der Historie gespeichert werden?
Eine langfristige Historie muss nicht kompliziert sein. Je nach Art des Monitorings können beispielsweise folgende Informationen ausreichen:
- Anzahl der Fehler an einem bestimmten Tag,
- Anzahl der verarbeiteten Anfragen,
- Anzahl der Vorkommnisse eines bestimmten Problems,
- durchschnittliche oder repräsentative Antwortzeit,
- Ergebnisse von Verfügbarkeits- und Performance-Messungen,
- Zeitpunkt von Beginn und Ende eines Problems.
Solche Daten benötigen deutlich weniger Speicherplatz als vollständige Ereignisse und reichen gleichzeitig aus, um Diagramme zu erstellen und langfristige Trends zu analysieren.
Warum sind aggregierte Daten beim Fehlermonitoring wichtig?
Aggregation dient nicht nur dazu, Speicherplatz zu sparen. Sie ist auch bei der Erkennung von Anomalien hilfreich.
Wenn Sie feststellen möchten, ob die heutige Anzahl der Fehler ungewöhnlich ist, benötigen Sie historische Daten zum Vergleich. Dafür müssen jedoch nicht sämtliche detaillierten Ereignisse jedes vergangenen Tages gespeichert werden.
Die tägliche Anzahl der Fehler kann als Referenzwert für zukünftige Warnmeldungen dienen, selbst wenn die detaillierten Ereignisse aus diesem Zeitraum bereits gelöscht wurden.
Datenaufbewahrung und Limits
Ein weiterer wichtiger Aspekt ist: Das Limit für die Anzahl der Ereignisse sollte nicht von der Aufbewahrungsdauer der Rohdaten abhängen.
Wenn detaillierte Ereignisse regelmäßig gelöscht werden, zeigt ihre aktuelle Anzahl in der Datenbank nicht mehr, wie viele Ereignisse innerhalb eines bestimmten Abrechnungszeitraums tatsächlich empfangen wurden. Deshalb sollte die Nutzung des Limits über einen unabhängigen Zähler erfasst werden, der nicht zusammen mit den Rohdaten gelöscht wird.
So setzt das Löschen alter Fehler die Nutzung des Limits nicht zurück und verändert auch nicht die historische Verbrauchsstatistik.
Wie findet man ein sinnvolles Gleichgewicht?
Ein guter Ansatz besteht darin, sich eine einfache Frage zu stellen: Wird diese Information benötigt, um ein konkretes Problem zu lösen, oder lediglich, um einen Trend zu analysieren?
Wenn Sie die Daten zur Fehlersuche benötigen, speichern Sie das detaillierte Ereignis für einen angemessenen Zeitraum. Wenn Sie sich für die langfristige Entwicklung Ihrer Anwendung interessieren, reichen aggregierte Statistiken aus.
Durch diese Trennung lässt sich die Menge der gespeicherten Daten reduzieren, ohne Informationen zu verlieren, die für den Betrieb und die Wartung der Anwendung tatsächlich relevant sind.
Monitoring muss nicht alles speichern
Das beste Monitoring-System ist nicht dasjenige, das jedes Detail unbegrenzt aufbewahrt. Es ist ein System, das die richtigen Daten für den richtigen Zeitraum speichert.
Details helfen dabei, einen konkreten Fehler zu beheben. Aggregierte Daten machen die Entwicklung einer Anwendung über längere Zeiträume sichtbar. Die Trennung dieser beiden Ebenen ermöglicht zugleich ein nützliches Monitoring, eine sinnvolle Datenaufbewahrung und den Zugriff auf langfristige Statistiken.
