Como funciona a detecção de picos de uso
Última atualização: November 2026
O que ela mede
- Uso, não custo. O FireShield lê o uso de cada serviço monitorado no Google Cloud Monitoring: leituras de documentos, invocações, dados baixados, tokens etc.
- Ela pega o que os orçamentos não veem: o Google informa os gastos com atraso de 15 minutos a várias horas, enquanto as métricas de uso chegam em minutos.
- Faz parte do plano Pro, verificado a cada 5 minutos.
- Serviços que você pode monitorar: Cloud Firestore (leituras, gravações e exclusões de documentos), Cloud Functions (invocações), Cloud Functions e Cloud Run (tempo de computação), Cloud Storage (operações, dados baixados e dados enviados), Realtime Database (dados baixados), SQL Connect (operações), Cloud SQL (bytes enviados e transações), Hosting (transferência de dados), Vertex AI e Firebase AI Logic (tokens), Gemini API (requisições). Uma chave da Gemini API criada no Google AI Studio costuma ficar em um projeto do Google Cloud próprio, então vincule esse projeto para monitorá-la.
Quando um pico dispara
- O normal é a hora média dos últimos 7 dias. Uma hora sem uso conta como zero, então não há período de aprendizado.
- Uma regra dispara quando os últimos 60 minutos chegam ao multiplicador que você definiu (por exemplo ×10 o normal) e ficam acima do normal em pelo menos o aumento mínimo que você definiu.
- O aumento mínimo é opcional. Ele evita que um multiplicador grande dispare quando o uso normal é muito baixo: se o normal é 3 por hora, ×10 é só 30.
- Um serviço sem uso a semana toda que de repente recebe tráfego conta como um pico a partir de zero, desde que passe do aumento mínimo.
- Não há nada para abrir ou fechar: cada verificação (a cada 5 minutos) que ainda atenda à regra executa as ações de novo, até o uso baixar.
As mesmas ações rodam a cada verificação
Enquanto o uso continuar acima da regra, cada verificação roda de novo todas as ações dela: e-mails e mensagens no Slack e no Telegram se repetem a cada 5 minutos até o uso cair. Seu endpoint de Soft Kill vai receber a mesma chamada várias vezes seguidas, então torne-o idempotente: ativar o modo degradado quando ele já está ativo não pode causar problema. Veja Webhooks de Soft Kill · guia de integração.
Como configurar
- Abra um projeto no painel. Dê à conta de serviço do FireShield o papel somente leitura Monitoring Viewer nesse projeto, no console do Google Cloud ou com o comando gcloud que o painel mostra, e ative a detecção. É feito uma vez por projeto, e o FireShield não recebe mais nada.
- Escolha um serviço para monitorar. Cada serviço monitorado tem uma regra: seu multiplicador, seu aumento mínimo e suas ações.
- Cada serviço monitorado mostra o uso por hora dos últimos 7 dias, com o normal como linha tracejada, e seus últimos picos ao lado do gráfico.
- Desativar a detecção interrompe as verificações daquele projeto.
O que acontece quando dispara
- As ações da regra são executadas: um email, uma mensagem no Slack ou no Telegram, um webhook de Soft Kill ou um Hard Kill que desconecta o faturamento do projeto.
- Um Soft Kill enviado por um pico traz o serviço, o uso da última hora e o nível normal, para que seu código o diferencie de um alerta de orçamento. Veja Webhooks de Soft Kill · guia de integração.
- Um Hard Kill para tudo o que o projeto executa. Veja O que é um Hard Kill.
Sem trégua depois de um Hard Kill por pico
Enquanto um projeto está parado, o FireShield não o verifica. Quando você clica em Reactivate, a próxima verificação (5 minutos depois) lê de novo os últimos 60 minutos, e se você reativar menos de uma hora depois do corte, o pico ainda pode estar nessa janela: o Hard Kill roda de novo. Antes de reativar, corrija a causa e então espere passar uma hora desde o corte, ou edite a regra (remova o Hard Kill ou aumente o multiplicador) e restaure-a quando o uso voltar ao normal. O Hard Kill de um orçamento é diferente: ele não dispara de novo no mesmo mês com o mesmo valor de orçamento.
Bom saber
- Ele vê uso, não dinheiro: uma regra não distingue um pico barato de um caro. Exemplo: ×10 o normal em transferência de dados do Hosting ou em dados baixados do Cloud Storage costuma significar alguns GB a mais, de centavos a poucos dólares, e pode ser tráfego legítimo. ×10 em tokens do Firebase AI Logic ou em gravações do Firestore causadas por um loop pode custar dezenas ou centenas de dólares em poucas horas. Por isso, use multiplicadores mais baixos (com um aumento mínimo) onde cada unidade é cara, e mais altos onde os picos são baratos e o tráfego varia muito.
- Os dados do Cloud Monitoring chegam com alguns minutos de atraso, então os minutos mais recentes de um pico aparecem na verificação seguinte.
- Ela complementa o seu orçamento, não o substitui. Mantenha limites de orçamento em todos os projetos: são eles que medem o dinheiro.
