Geben Sie das SLO-Ziel, ein Fenster aus gesamten und fehlerhaften Events und dessen Länge in Tagen ein. Das Panel zeigt das verbrauchte Budget, die Burn Rate und wie lange der Rest bei dieser Rate hält.
Läuft lokal in deinem BrowserEine Burn Rate von 1× verbraucht das gesamte Fehlerbudget in einem SLO-Zeitraum; dieser Rechner ruft keine Monitoring-Daten ab.
Vier Zahlen gehen hinein: das SLO-Ziel in Prozent, die Gesamtzahl der Events im Beobachtungsfenster, wie viele davon fehlerhaft waren und die Länge dieses Fensters in Tagen. Das Panel beantwortet die beiden Fragen eines Fehlerbudgets — wie viel davon die beobachteten Fehler verbrauchen und wie lange der Rest bei dieser Rate hält — und rechnet im Tab, ohne ein Monitoring-System zu kontaktieren.
Beide Zählungen stammen aus einem Fenster. Das Werkzeug vergleicht sie nur mit der erlaubten Fehlerrate und weiß nicht, wie Ihr Monitoring ein Event einordnet: Zählt die Fehlerzahl Zeitüberschreitungen mit, die Ihr SLO ausschließt, verschiebt sich das Budget genau um diesen Betrag.
Die erlaubte Fehlerrate ist 100 − Ziel: ein SLO von 99,9 % lässt 0,1 % der Events fehlschlagen. Mit der Gesamtzahl multipliziert ergibt das die Größe erlaubte Fehler-Events — 1.000 bei einer Million Events und 99,9 %. Das verbrauchte Budget ist die beobachtete Fehlerzahl geteilt durch diese Erlaubnis: 2.500 Fehler bei 1.000 erlaubten lesen sich als 250 % und lassen nichts übrig, 500 Fehler als 50 % und lassen die Hälfte. Die Verfügbarkeit ist das schlichte Fehlerverhältnis, 1 − fehlerhaft ÷ gesamt: 99,75 % im ersten und 99,95 % im zweiten Fall.
Das verbleibende Budget bleibt bei 0 % stehen: ist die Erlaubnis aufgebraucht, machen weitere Fehler die Zahl nicht negativ, sondern der Balken wird rot und das Panel sagt es. Fehler genau in Höhe der Erlaubnis gelten als vollständig verbraucht, nicht als Überschreitung; diese Grenze wird mit einer Toleranz entschieden, weil die Erlaubnis ein Produkt zweier eingetippter Zahlen ist und eine exakte Eingabe um einen Bruchteil eines ulp darüber liegen kann.
Die Burn Rate teilt die beobachtete Fehlerrate durch die erlaubte. 1× heißt, das Budget wird genau mit der Rate verbraucht, die das SLO erlaubt, und reicht einen vollen Zeitraum; 2,50× heißt zweieinhalb Mal schneller; unter 1× überlebt es den Zeitraum.
Die voraussichtliche Erschöpfung ist die verbleibende Zeit bei dieser Rate, nicht die Laufzeit eines frischen Budgets: der Zeitraum multipliziert mit dem noch unverbrauchten Anteil, geteilt durch die Burn Rate. Bei 0,50× und halbem Budget bleiben aus einem 30-Tage-Fenster etwa 30 weitere Tage. Ein aufgebrauchtes Budget zeigt „Budget bereits aufgebraucht“, ein Fenster ohne fehlerhafte Events „nicht bei dieser Rate“. Das Zeitraum-Feld dient nur dieser Projektion: es skaliert die Zählungen nicht.
Er ruft kein Monitoring-System, keine Metrik-API und kein DNS auf. Die vier Werte sind die einzige Eingabe, alles wird im Browser gerechnet, und die Seite funktioniert weiter offline.
Und dabei bleibt es: keine Multi-Window-Burn-Rate-Alarme (die Paare 1 h / 6 h / 3 d), keine Gewichtung nach Dienst oder Nutzer, kein zeitbasierter SLI, bei dem die Verfügbarkeit in Minuten statt in Events gemessen wird, kein Alarm-Routing. Das gehört in Ihre Monitoring-Plattform. Diese Seite ist die arithmetische Probe, ob ein Fenster von Zahlen noch im Budget liegt oder schon darüber.