Cómo funciona la detección de picos de uso
Última actualización: November 2026
Qué mide
- Uso, no coste. FireShield lee el uso de cada servicio monitoreado en Google Cloud Monitoring: lecturas de documentos, invocaciones, datos descargados, tokens, etc.
- Detecta lo que los presupuestos no ven: Google informa del gasto con un retraso de 15 minutos a varias horas, mientras que las métricas de uso llegan en minutos.
- Forma parte del plan Pro y se analiza cada 5 minutos.
- Servicios que puedes monitorear: Cloud Firestore (lecturas, escrituras y eliminaciones de documentos), Cloud Functions (invocaciones), Cloud Functions y Cloud Run (tiempo de cómputo), Cloud Storage (operaciones, datos descargados y datos subidos), Realtime Database (datos descargados), SQL Connect (operaciones), Cloud SQL (bytes enviados y transacciones), Hosting (transferencia de datos), Vertex AI y Firebase AI Logic (tokens), Gemini API (peticiones). Una clave de la Gemini API creada en Google AI Studio suele vivir en su propio proyecto de Google Cloud, así que vincula ese proyecto para vigilarla.
Cuándo salta un pico
- Lo normal es la hora media de los últimos 7 días. Una hora sin uso cuenta como cero, así que no hay periodo de aprendizaje.
- Una regla salta cuando los últimos 60 minutos llegan al multiplicador que elijas (por ejemplo ×10 lo normal) y superan lo normal en al menos el aumento mínimo que elijas.
- El aumento mínimo es opcional. Evita que un multiplicador grande salte cuando el uso normal es muy bajo: si lo normal son 3 por hora, ×10 son solo 30.
- Un servicio sin uso en toda la semana que de repente recibe tráfico cuenta como un pico desde cero, siempre que supere el aumento mínimo.
- No hay nada que abrir ni cerrar: cada análisis (cada 5 minutos) que siga cumpliendo la regla vuelve a ejecutar sus acciones, hasta que el uso baje.
Las mismas acciones se ejecutan en cada comprobación
Mientras el uso siga por encima de la regla, cada comprobación vuelve a ejecutar todas sus acciones: los emails y los mensajes de Slack y Telegram se repiten cada 5 minutos hasta que el uso baje. Tu endpoint de Soft Kill recibirá la misma llamada varias veces seguidas, así que hazlo idempotente: activar el modo degradado cuando ya está activo no debe causar ningún problema. Consulta Webhooks de Soft Kill · guía de integración.
Cómo se configura
- Abre un proyecto en el panel. Da a la cuenta de servicio de FireShield el rol de solo lectura Monitoring Viewer en ese proyecto, desde la consola de Google Cloud o con el comando gcloud que muestra el panel, y activa la detección. Se hace una vez por proyecto y FireShield no recibe nada más.
- Elige un servicio para monitorear. Cada servicio monitoreado tiene una regla: su multiplicador, su aumento mínimo y sus acciones.
- Cada servicio monitoreado muestra el uso por hora de los últimos 7 días, con lo normal como línea discontinua, y sus últimos picos junto al gráfico.
- Al desactivar la detección se detienen los análisis de ese proyecto.
Qué pasa cuando salta
- Se ejecutan las acciones de la regla: un email, un mensaje de Slack o Telegram, un webhook de Soft Kill o un Hard Kill que desconecta la facturación del proyecto.
- Un Soft Kill enviado por un pico incluye el servicio, el uso de la última hora y el nivel normal, para que tu código lo distinga de una alerta de presupuesto. Consulta Webhooks de Soft Kill · guía de integración.
- Un Hard Kill detiene todo lo que ejecuta el proyecto. Consulta Qué es un Hard Kill.
Sin tregua tras un Hard Kill por un pico
Mientras un proyecto está parado, FireShield no lo comprueba. Al pulsar Reactivate, la siguiente comprobación (5 minutos después) vuelve a leer los últimos 60 minutos, y si reactivas antes de que pase más o menos una hora desde el corte, el pico puede seguir en esa ventana: el Hard Kill se ejecuta otra vez. Antes de reactivar, arregla la causa y después espera a que pase una hora desde el corte, o edita la regla (quita el Hard Kill o sube su multiplicador) y restáurala cuando el uso vuelva a la normalidad. El Hard Kill de un presupuesto es distinto: no vuelve a saltar en el mismo mes con el mismo importe de presupuesto.
Conviene saber
- Ve uso, no dinero: una regla no distingue un pico barato de uno caro. Ejemplo: ×10 lo normal en transferencia de datos de Hosting o en datos descargados de Cloud Storage suele significar unos pocos GB más, de céntimos a unos pocos dólares, y puede ser tráfico legítimo. ×10 en tokens de Firebase AI Logic o en escrituras de Firestore provocadas por un bucle puede costar decenas o cientos de dólares en pocas horas. Así que usa multiplicadores más bajos (con un aumento mínimo) donde cada unidad es cara, y más altos donde los picos son baratos y el tráfico varía mucho.
- Los datos de Cloud Monitoring llegan con unos minutos de retraso, así que los últimos minutos de un pico aparecen en el análisis siguiente.
- Complementa tu presupuesto, no lo sustituye. Mantén umbrales de presupuesto en cada proyecto: son los que miden el dinero.
