So funktioniert die Erkennung von Nutzungsspitzen
Zuletzt aktualisiert: November 2026
Was sie misst
- Nutzung, nicht Kosten. FireShield liest die Nutzung jedes überwachten Dienstes aus Google Cloud Monitoring: Dokumentlesevorgänge, Aufrufe, heruntergeladene Daten, Tokens usw.
- Sie erkennt, was Budgets entgeht: Google meldet Ausgaben mit 15 Minuten bis mehreren Stunden Verzögerung, Nutzungsmetriken kommen dagegen innerhalb von Minuten.
- Sie ist Teil des Pro-Tarifs (Prüfung alle 5 Minuten).
- Dienste, die Sie überwachen können: Cloud Firestore (Dokumentlese-, Schreib- und Löschvorgänge), Cloud Functions (Aufrufe), Cloud Functions und Cloud Run (Rechenzeit), Cloud Storage (Vorgänge, heruntergeladene und hochgeladene Daten), Realtime Database (heruntergeladene Daten), SQL Connect (Vorgänge), Cloud SQL (gesendete Bytes und Transaktionen), Hosting (Datenübertragung), Vertex AI und Firebase AI Logic (Tokens), Gemini API (Anfragen). Ein in Google AI Studio erstellter Gemini-API-Schlüssel liegt oft in einem eigenen Google-Cloud-Projekt. Verknüpfen Sie dieses Projekt, um ihn zu überwachen.
Wann eine Spitze auslöst
- Der Normalwert ist die durchschnittliche Stunde der letzten 7 Tage. Eine Stunde ohne Nutzung zählt als null, es gibt also keine Lernphase.
- Eine Regel löst aus, wenn die letzten 60 Minuten den festgelegten Multiplikator erreichen (zum Beispiel ×10 des Normalwerts) und mindestens um den festgelegten Mindestanstieg über dem Normalwert liegen.
- Der Mindestanstieg ist optional. Er verhindert, dass ein großer Multiplikator bei sehr geringer normaler Nutzung auslöst: Sind normal 3 pro Stunde, sind ×10 nur 30.
- Ein Dienst ohne Nutzung in der ganzen Woche, der plötzlich Verkehr bekommt, zählt als Spitze ab null, sofern er den Mindestanstieg überschreitet.
- Es wird nichts geöffnet oder geschlossen: Jede Prüfung (alle 5 Minuten), die die Regel noch erfüllt, führt ihre Aktionen erneut aus, bis die Nutzung wieder sinkt.
Bei jeder Prüfung laufen dieselben Aktionen
Solange die Nutzung über der Regel liegt, führt jede Prüfung alle Aktionen der Regel erneut aus: E-Mails sowie Slack- und Telegram-Nachrichten wiederholen sich alle 5 Minuten, bis die Nutzung sinkt. Ihr Soft-Kill-Endpoint erhält denselben Aufruf mehrmals hintereinander, machen Sie ihn also idempotent: Den eingeschränkten Modus einzuschalten, wenn er schon an ist, darf nichts kaputt machen. Siehe Soft-Kill-Webhooks · Integrationsleitfaden.
Einrichtung
- Öffnen Sie ein Projekt im Dashboard. Geben Sie dem Dienstkonto von FireShield die schreibgeschützte Rolle Monitoring Viewer für dieses Projekt, in der Google Cloud Console oder mit dem gcloud-Befehl, den das Dashboard anzeigt, und schalten Sie dann die Erkennung ein. Das ist einmal pro Projekt nötig, und FireShield erhält sonst nichts.
- Wählen Sie einen Dienst zur Überwachung. Jeder überwachte Dienst hat eine Regel: Multiplikator, Mindestanstieg und Aktionen.
- Jeder überwachte Dienst zeigt die stündliche Nutzung der letzten 7 Tage mit dem Normalwert als gestrichelte Linie und daneben seine letzten Spitzen.
- Wenn Sie die Erkennung ausschalten, werden die Prüfungen für dieses Projekt beendet.
Was beim Auslösen passiert
- Die Aktionen der Regel werden ausgeführt: eine E-Mail, eine Slack- oder Telegram-Nachricht, ein Soft-Kill-Webhook oder ein Hard Kill, der die Abrechnung des Projekts trennt.
- Ein Soft Kill, der von einer Spitze ausgelöst wird, enthält den Dienst, die Nutzung der letzten Stunde und den Normalwert, damit Ihr Code ihn von einer Budgetwarnung unterscheiden kann. Siehe Soft-Kill-Webhooks · Integrationsleitfaden.
- Ein Hard Kill stoppt alles, was das Projekt ausführt. Siehe Was ist ein Hard Kill.
Keine Schonfrist nach einem Hard Kill durch eine Spitze
Solange ein Projekt gestoppt ist, prüft FireShield es nicht. Sobald Sie auf Reactivate klicken, liest die nächste Prüfung (5 Minuten später) wieder die letzten 60 Minuten, und wenn Sie innerhalb von etwa einer Stunde nach der Trennung reaktivieren, kann die Spitze noch in diesem Fenster liegen: Der Hard Kill läuft erneut. Beheben Sie vor dem Reaktivieren die Ursache, und warten Sie dann, bis seit der Trennung eine Stunde vergangen ist, oder bearbeiten Sie die Regel (Hard Kill entfernen oder Multiplikator erhöhen) und stellen Sie sie wieder her, sobald die Nutzung normal ist. Der Hard Kill eines Budgets verhält sich anders: Er löst im selben Monat beim selben Budgetbetrag nicht erneut aus.
Gut zu wissen
- Es sieht Nutzung, nicht Geld: Eine Regel unterscheidet keine günstige von einer teuren Spitze. Beispiel: ×10 normal bei der Datenübertragung von Hosting oder bei heruntergeladenen Daten aus Cloud Storage bedeutet meist ein paar GB mehr, Cents bis wenige Dollar, und kann legitimer Traffic sein. ×10 bei Firebase-AI-Logic-Tokens oder Firestore-Schreibvorgängen durch eine Schleife kann innerhalb weniger Stunden Dutzende oder Hunderte Dollar kosten. Verwenden Sie daher niedrigere Multiplikatoren (mit Mindestanstieg), wo jede Einheit teuer ist, und höhere, wo Spitzen günstig sind und der Traffic stark schwankt.
- Daten aus Cloud Monitoring kommen einige Minuten verzögert an, daher erscheinen die neuesten Minuten einer Spitze bei der folgenden Prüfung.
- Sie ergänzt Ihr Budget, sie ersetzt es nicht. Behalten Sie Budgetschwellen für jedes Projekt bei: Sie messen das Geld.
