Mit einer Betriebsfrage beginnen
„Warum steigt die Fehlerrate nur in einer Region?“ ist ein besserer Test als „Ist das Dashboard fertig?“. Die erste Frage verlangt Zusammenhang: Service, Region, Revision, Zeitfenster und ein Weg von der Metrik zum relevanten Log. Die zweite kann schon mit einer optisch passenden Kurve beantwortet werden.
Für einen Vergleich würde ich einige bekannte Untersuchungswege auswählen und in beiden Systemen nachvollziehen. Dabei geht es nicht darum, jedes alte Panel unverändert zu konservieren. Entscheidend ist, dass die nützliche Frage weiterhin beantwortet werden kann.
Bedeutung vor Gleichheit
Timestamp und Zeitzone, Feldtypen, Service-Namen, Labels und Parsing bestimmen, was eine Abfrage tatsächlich auswählt. Ein numerischer Wert, der als Text ankommt, oder ein anders benanntes Umgebungsfeld kann einen Vergleich verzerren, obwohl Daten sichtbar eingehen.
Auch Aggregation und fehlende Daten brauchen eine bewusste Entscheidung. Durchschnitt, Perzentil und Summe sind keine austauschbaren Darstellungen. Eine ruhige Kurve kann geringe Last bedeuten, einen anderen Filter oder eine unterbrochene Erfassung.
Alerts haben Verhalten, nicht nur Schwellenwerte
Ich würde Auswertung, Wartezeit, Gruppierung, Recovery und Benachrichtigungsweg getrennt vergleichen. Eine gleiche Zahl im Threshold-Feld garantiert noch kein gleiches Alarmverhalten. Während eines Parallelbetriebs sollten produktive Benachrichtigungen bewusst gesteuert werden, damit ein Vergleich nicht doppelt eskaliert.
Soll ein neues Regelwerk im Hintergrund verglichen werden, muss es tatsächlich ausgewertet werden. Eine pausierte Regel ist dafür je nach Produkt kein Ersatz. Ein Test- oder nicht eskalierender Benachrichtigungsweg kann geeigneter sein; das konkrete Tool-Verhalten muss geprüft werden.
Die Übergabe ist ein Funktionstest
Kann jemand, der die Migration nicht umgesetzt hat, einen relevanten Fehler untersuchen? Sind die neuen Einstiege, Begriffe, Retention-Grenzen und verbleibenden Unterschiede bekannt? Diese Fragen machen aus einer technisch vorhandenen Installation ein nutzbares Betriebsmittel.
Nachrechnen: 5,5 % oder 1,9 % Fehler?
Reproduzierbares Lernbeispiel mit synthetischen Daten. Kein Bericht über ein Arbeitgeber- oder Kundenprojekt.
Zwei Ansichten können dieselben Requests verwenden und unterschiedliche Zahlen zeigen. Im Beispiel gibt es in einem gemeinsamen Fünf-Minuten-Fenster 100 abgeschlossene Requests in Region A, davon 10 mit HTTP 5xx, und 900 in Region B, davon 9 mit HTTP 5xx.
Lokal ausführen
Python 3 genügt. Das Skript erzeugt die 1.000 synthetischen Datensätze im Arbeitsspeicher und benötigt keine Bibliotheken, Dateien oder Verbindung zu einem Observability-Produkt. Nach dem Download ausführen:
Python-Beispiel herunterladen · error-rate-aggregation.py
python error-rate-aggregation.pyAusgabe des Beispiels
Region A: 10/100 = 10.0%
Region B: 9/900 = 1.0%
Mean of regional percentages: 5.5%
All completed requests: 1.9%
No records: unknown5,5 % ist das ungewichtete Mittel der beiden regionalen Prozentsätze: (10 % + 1 %) / 2. Die Fehlerrate über alle erfassten Requests beträgt dagegen (10 + 9) / (100 + 900) = 1,9 %. Beide Zahlen sind mathematisch nachvollziehbar, beantworten aber unterschiedliche Fragen. Für „Welcher Anteil aller Requests scheitert?“ ist hier der gemeinsame Nenner von 1.000 Requests maßgeblich.
Den Nenner mitprüfen
Bei einem Vergleich zuerst Zeitfenster, Service- und Umgebungsfilter sowie die Definition von „Request“ und „Fehler“ abgleichen. Werden Retries einzeln gezählt? Fehlen Timeouts ohne fertigen Log-Eintrag? Gibt es Sampling oder doppelte Events? Danach die Aggregation prüfen. Ohne Datensätze bleibt die Rate unbekannt; null Fehler bei vorhandenen Requests ist eine andere Aussage. Und 1,9 % insgesamt darf das regionale Problem mit 10 % nicht verdecken.
Hier entspricht ein Datensatz genau einem abgeschlossenen Request; nur HTTP 5xx zählt als Fehler. Das ist eine definierte Übungsannahme, keine allgemeingültige SLI-Definition. Der Vergleich prüft weder ein bestimmtes Produkt noch den Erfolg einer realen Migration.