Todo engenheiro que opera infraestrutura em nuvem acaba se deparando com a mesma pergunta: meu sistema está realmente funcionando bem agora? Responder essa pergunta exige um sistema para coletar e analisar três tipos de sinais — métricas, logs e rastreamentos — que em conjunto formam o que a indústria chama de stack de observabilidade. No Google Cloud, Cloud Monitoring e Cloud Logging ocupam o centro desse stack.
---
O que significa operar a nuvem sem observabilidade
Em um ambiente onde dezenas de VMs e serviços gerenciados estão fortemente acoplados, ir fisicamente verificar um servidor simplesmente não é uma opção. Quando algo falha, não saber onde ocorreu, quando começou ou por que aconteceu é chamado de operação caixa-preta. Observabilidade é a capacidade de inferir o que está acontecendo dentro de um sistema a partir de sinais observáveis de fora.
Os três pilares da observabilidade mapeiam diretamente para ferramentas do GCP:
| Sinal | O que te diz | Ferramenta GCP | |-------|-------------|----------------| | Métricas | Estado numérico do sistema — CPU a 80%, latência de requisição 200ms | Cloud Monitoring | | Logs | O que aconteceu em um momento específico — mensagens de erro, eventos de auditoria | Cloud Logging | | Rastreamentos | Como uma requisição fluiu entre serviços — identificar gargalos | Cloud Trace |
Métricas respondem "qual é o estado atual", logs respondem "o que aconteceu" e rastreamentos respondem "por que está lento". Cenários de prova frequentemente exigem distinguir qual tipo de sinal — e qual ferramenta — se aplica a cada situação. Ter esses três conceitos bem definidos desde o início facilita todos os cenários de operações que você encontrará.
---
Componentes principais do Cloud Monitoring
Cloud Monitoring foi anteriormente conhecido como Stackdriver Monitoring. Ele ingere milhares de métricas automaticamente dos recursos do GCP, armazena-as em um banco de dados de séries temporais e fornece dashboards e Alerting Policy para que as equipes de operações avaliem a saúde do sistema de relance.
Arquitetura de coleta de métricas
Para VMs no Compute Engine, instalar o Ops Agent habilita a coleta de métricas em nível de sistema — CPU, memória, disco, rede — juntamente com logs de aplicações do mesmo host. Serviços gerenciados como Cloud SQL, GKE e Cloud Run emitem métricas automaticamente sem necessidade de agente. Métricas personalizadas de aplicações podem ser enviadas via SDK do OpenTelemetry ou Prometheus. Em ambientes GKE, o Managed Service for Prometheus ingere métricas do Prometheus nativamente sem exigir alterações na instrumentação existente.
Dashboards e Alerting Policy
As duas funcionalidades principais do Cloud Monitoring são os dashboards para visualização de métricas e o Alerting Policy para notificações automatizadas. Uma Alerting Policy tem três componentes: uma condição que define qual métrica e limiar dispara o alerta, um canal de notificação que especifica quem recebe a notificação e como, e documentação que fornece orientação de runbook junto com a notificação de alerta.
| Componente | Função | Exemplo | |------------|--------|--------| | Condição | Qual métrica, qual limiar, por quanto tempo | disk/read_latencies > 100ms por 5 min | | Canal de notificação | Quem recebe o alerta e como | Email, Slack, PagerDuty, Webhook, Pub/Sub | | Duração | Ignorar picos transitórios, disparar apenas em violações sustentadas | 1 min, 5 min, 10 min | | Documentação | Runbook ou mensagem de orientação anexada ao alerta | "Se isso disparar, verifique X primeiro" |
A janela de duração é fundamental para reduzir a fadiga de alertas. Sem ela, um pico de CPU que se resolve em segundos ainda gera uma notificação. Configurar uma duração de cinco minutos filtra o ruído transitório e garante que apenas problemas genuínos e sustentados gerem notificações. Esse único detalhe de configuração é a diferença entre uma equipe de plantão que confia em seus alertas e uma que os ignora.
---
Como funcionam o Cloud Logging e o Log Router
Cloud Logging é o serviço centralizado de gerenciamento de logs do GCP. Duas categorias de logs de auditoria são especialmente importantes para a prova. Os logs de auditoria de Admin Activity registram criação, exclusão e modificação de recursos — incluindo mudanças no IAM e alterações de esquema — automaticamente e não podem ser desabilitados. Os logs de auditoria de Data Access registram operações do plano de dados como consultas do BigQuery e leituras do Cloud Storage. Estão desabilitados por padrão e devem ser habilitados explicitamente por serviço.
Log Router e Sinks
O núcleo arquitetural do Cloud Logging é o Log Router e seus sinks. O Log Router inspeciona cada entrada de log à medida que chega e a avalia em relação a todos os filtros de sink configurados. Entradas que correspondem a um filtro são exportadas para o destino do sink. O fluxo é: fonte de log → ingestão no Cloud Logging → Log Router → correspondência com filtro de sink → destino.
Escolher o destino de sink correto é o conceito de Log Router avaliado com maior frequência. A tabela abaixo mapeia palavras-chave de cenário para a resposta correta:
| Destino do Sink | Caso de uso | Palavras-chave | |----------------|-------------|----------------| | Cloud Storage | Retenção de longo prazo, arquivamento para conformidade, preservação de logs de auditoria | "longo prazo", "arquivo", "conformidade" | | BigQuery | Análise baseada em logs, consultas SQL, integração com dashboards de BI | "analisar", "consulta SQL", "BigQuery" | | Pub/Sub | Processamento em tempo real, integração com sistemas externos, pipelines de streaming | "tempo real", "sistema externo", "streaming" | | Splunk | Integração com ferramentas SIEM existentes | "Splunk", "SIEM" | | Outro Cloud Logging | Centralizar logs entre organizações, rotear logs de auditoria para um projeto de segurança | "centralizar", "outro projeto" |
---
Métricas baseadas em log e alertas baseados em SLO
Log-based Metrics
Uma das funcionalidades mais poderosas do Cloud Logging é a capacidade de derivar métricas diretamente dos dados de log. Uma métrica contador que conta entradas de log contendo a string "ERROR" torna-se uma série temporal sobre a qual o Cloud Monitoring pode alertar, assim como qualquer métrica de infraestrutura. Dois tipos de métricas estão disponíveis: métricas contador (contagem de entradas de log que correspondem a um filtro) e métricas de distribuição (distribuição estatística de um valor numérico extraído das entradas de log). Quando um cenário de prova descreve alertar quando um padrão de log específico ultrapassa um limiar, a resposta são as Log-based Metrics combinadas com uma Alerting Policy.
Alertas baseados em SLO
Um Service Level Objective define um objetivo de confiabilidade para um serviço. O Cloud Monitoring pode definir SLOs diretamente e alertar com base na taxa de consumo do error budget em vez de limiares brutos de métricas. Para um SLO de disponibilidade mensal de 99,9%, um alerta dispara imediatamente quando 10% do error budget é consumido em uma hora, e é enviado por um canal mais lento quando 1% é consumido em 24 horas. Essa é a abordagem idiomática de SRE para alertas — ela expõe o impacto real sobre o usuário em vez do ruído transitório de infraestrutura.
| Abordagem de alerta | Características | Melhor usado para | |--------------------|-----------------|-------------------| | Baseado em limiar | Dispara quando uma métrica ultrapassa um valor numérico | Métricas de infraestrutura que exigem resposta imediata | | Alerta de Log-based Metric | Dispara quando a frequência de um padrão de log ultrapassa um limiar | Picos de logs de erro, detecção de eventos de segurança | | Alerta baseado em SLO | Dispara com base na taxa de consumo do error budget | Serviços gerenciados com SLO, minimização de fadiga de alertas |
---
Medindo disponibilidade com Uptime Check
Uptime Check é o mecanismo do Cloud Monitoring para sondar a disponibilidade do serviço de fora para dentro. O Cloud Monitoring envia requisições HTTP, HTTPS ou TCP a partir de múltiplas regiões globais para uma URL ou IP especificada, inspecionando então o código de resposta, o corpo da resposta e o tempo de resposta.
| Componente | Descrição | |------------|----------| | Alvo | URL, endereço IP ou endpoint de recurso GCP (ex. https://example.com/health) | | Protocolo | HTTP, HTTPS, TCP | | Intervalo de verificação | 1 a 15 minutos (recomenda-se 1 minuto) | | Verificador de conteúdo | O corpo da resposta deve conter uma string específica (ex. "OK", "healthy") para ser considerado bem-sucedido | | Locais de verificação | Múltiplas regiões simultaneamente — us-east1, europe-west1, asia-east1 e mais |
Quando um Uptime Check falha, ele se integra à Alerting Policy para enviar notificações imediatas. Essa é a forma mais rápida de detectar que usuários reais não conseguem acessar um serviço. Uma restrição importante: VMs com IPs exclusivamente internos não podem ser verificadas por padrão. O Uptime Check aplica-se apenas a endpoints acessíveis externamente.
---
Cloud Trace, Error Reporting e Cloud Profiler — Resumos em uma linha
Além do Cloud Monitoring e Cloud Logging, o stack de observabilidade do GCP inclui três ferramentas adicionais. Compreender o papel distinto de cada uma previne confusão em questões de prova baseadas em cenários.
| Serviço | Função | Quando usar | |---------|--------|-------------| | Cloud Trace | Rastreamento distribuído — acompanha uma requisição enquanto ela se move entre serviços | Alta latência de API, identificar o serviço gargalo | | Error Reporting | Agrega e agrupa erros automaticamente, alerta sobre novos tipos de erro | Detectar rapidamente picos de erros após um deploy | | Cloud Profiler | Análise de flame graph do consumo de CPU e memória em produção | Otimização de desempenho, detecção de vazamentos de memória |
Cloud Trace é instrumentado via SDK do OpenTelemet