Comment fonctionne la détection des pics d'utilisation

Dernière mise à jour : November 2026

Ce qu'elle mesure

L'utilisation, pas le coût. FireShield lit l'utilisation de chaque service surveillé dans Google Cloud Monitoring : lectures de documents, invocations, données téléchargées, tokens, etc.
Elle repère ce que les budgets manquent : Google signale les dépenses avec un retard de 15 minutes à plusieurs heures, alors que les métriques d'utilisation arrivent en quelques minutes.
Elle fait partie de la formule Pro (analyse toutes les 5 minutes).
Services que vous pouvez surveiller : Cloud Firestore (lectures, écritures et suppressions de documents), Cloud Functions (invocations), Cloud Functions et Cloud Run (temps de calcul), Cloud Storage (opérations, données téléchargées et données importées), Realtime Database (données téléchargées), SQL Connect (opérations), Cloud SQL (octets envoyés et transactions), Hosting (transfert de données), Vertex AI et Firebase AI Logic (tokens), Gemini API (requêtes). Une clé Gemini API créée dans Google AI Studio se trouve souvent dans son propre projet Google Cloud, associez donc ce projet pour la surveiller.

Quand un pic se déclenche

La normale est l'heure moyenne des 7 derniers jours. Une heure sans utilisation compte pour zéro : il n'y a pas de période d'apprentissage.
Une règle se déclenche quand les 60 dernières minutes atteignent le multiplicateur choisi (par exemple ×10 la normale) et dépassent la normale d'au moins l'augmentation minimale choisie.
L'augmentation minimale est facultative. Elle évite qu'un grand multiplicateur se déclenche quand l'utilisation normale est très faible : si la normale est de 3 par heure, ×10 ne fait que 30.
Un service sans utilisation de toute la semaine qui reçoit soudain du trafic compte comme un pic à partir de zéro, tant qu'il dépasse l'augmentation minimale.
Rien ne s'ouvre ni ne se ferme : chaque analyse (toutes les 5 minutes) qui respecte encore la règle relance ses actions, jusqu'à ce que l'utilisation redescende.

Les mêmes actions s'exécutent à chaque vérification

Tant que l'utilisation reste au-dessus de la règle, chaque vérification relance toutes ses actions : les e-mails et les messages Slack et Telegram se répètent toutes les 5 minutes jusqu'à ce que l'utilisation baisse. Votre endpoint Soft Kill recevra le même appel plusieurs fois de suite : rendez-le idempotent, activer le mode dégradé alors qu'il l'est déjà doit être sans effet. Voir Webhooks Soft Kill · guide d'intégration.

Mise en place

Ouvrez un projet dans le tableau de bord. Donnez au compte de service de FireShield le rôle en lecture seule Monitoring Viewer sur ce projet, dans la console Google Cloud ou avec la commande gcloud affichée par le tableau de bord, puis activez la détection. Cela se fait une fois par projet, et FireShield ne reçoit rien d'autre.
Choisissez un service à surveiller. Chaque service surveillé a une règle : son multiplicateur, son augmentation minimale et ses actions.
Chaque service surveillé affiche l'utilisation horaire des 7 derniers jours, avec la normale en pointillés, et ses derniers pics à côté du graphique.
Désactiver la détection arrête les analyses de ce projet.

Ce qui se passe au déclenchement

Les actions de la règle s'exécutent : un email, un message Slack ou Telegram, un webhook Soft Kill ou un Hard Kill qui dissocie la facturation du projet.
Un Soft Kill envoyé par un pic contient le service, l'utilisation de la dernière heure et le niveau normal, pour que votre code le distingue d'une alerte de budget. Voir Webhooks Soft Kill · guide d'intégration.
Un Hard Kill arrête tout ce que le projet exécute. Voir Qu'est-ce qu'un Hard Kill.

Pas de répit après un Hard Kill déclenché par un pic

Tant qu'un projet est arrêté, FireShield ne le vérifie pas. Dès que vous cliquez sur Reactivate, la vérification suivante (5 minutes plus tard) relit les 60 dernières minutes, et si vous réactivez moins d'une heure environ après la coupure, le pic peut encore être dans cette fenêtre : le Hard Kill s'exécute à nouveau. Avant de réactiver, corrigez la cause, puis attendez qu'une heure se soit écoulée depuis la coupure, ou modifiez la règle (retirez le Hard Kill ou augmentez son multiplicateur) et rétablissez-la quand l'utilisation est revenue à la normale. Le Hard Kill d'un budget est différent : il ne se redéclenche pas dans le même mois pour le même montant de budget.

Bon à savoir

Il voit l'utilisation, pas l'argent : une règle ne distingue pas un pic bon marché d'un pic coûteux. Exemple : ×10 la normale sur le transfert de données Hosting ou les données téléchargées depuis Cloud Storage représente en général quelques Go de plus, de quelques centimes à quelques dollars, et peut être du trafic légitime. ×10 sur les tokens Firebase AI Logic ou les écritures Firestore causées par une boucle peut coûter des dizaines ou des centaines de dollars en quelques heures. Utilisez donc des multiplicateurs plus bas (avec une augmentation minimale) là où chaque unité coûte cher, et plus élevés là où les pics sont bon marché et le trafic varie beaucoup.
Les données de Cloud Monitoring arrivent avec quelques minutes de retard : les toutes dernières minutes d'un pic apparaissent à l'analyse suivante.
Elle complète votre budget, elle ne le remplace pas. Gardez des seuils de budget sur chaque projet : ce sont eux qui mesurent l'argent.