Google PCD: Observabilidade, Depuração e Operações de Site Reliability — Guia de estudos

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Developer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A observabilidade, a depuração e as operações de confiabilidade de sites (SRE) no Google Cloud se concentram em tornar os sistemas mensuráveis, diagnosticáveis e resilientes. Uma observabilidade robusta requer logging e métricas consistentes, rastreamento distribuído, alertas acionáveis e uma resposta a incidentes disciplinada. A confiabilidade exige clareza sobre os indicadores e objetivos de nível de serviço (SLIs e SLOs), uma sinalização de integridade rigorosa e um ciclo de feedback que transforma insights da produção em melhorias de engenharia. Esta seção descreve como construir essas capacidades de ponta a ponta no Google Cloud e como raciocinar sobre trade-offs e modos de falha comuns.

Fundamentos de Logging e Monitoramento

Cloud Logging

Emita logs estruturados. Prefira JSON com nomes de campo estáveis para que as consultas e as métricas baseadas em logs permaneçam robustas entre as versões. Inclua severidade, nome do serviço, versão, local e um ID de requisição ou contexto de rastreamento para correlação.
Correlacione logs a traces definindo os campos:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
Buckets e retenção. O bucket _Default normalmente tem retenção de 30 dias (configurável). O bucket _Required contém certos logs de auditoria com retenção mais longa e fixa. Crie buckets regionais para controlar a residência dos dados e defina uma retenção personalizada por bucket.
Coletores (Sinks). Encaminhe logs para o BigQuery para análise, para o Pub/Sub para consumidores de streaming ou para o Storage para arquivamento. Use coletores agregados no nível da pasta ou organização para capturar projetos filhos.
Consultas. Use a linguagem de consulta do Logging para filtrar por resource.type, labels, jsonPayload, httpRequest ou textPayload.

Exemplos:

Entrada de log estruturado (abreviada): { “severity”: “ERROR”, “message”: “Checkout failed”, “service”: “payments”, “version”: “2026-09-01”, “user_id_hash”: “9c1…”, “labels”: {“tenant”:“gold”}, “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”, “logging.googleapis.com/spanId”: “00f067aa0ba902b7” }
Atualizar retenção: gcloud logging buckets update _Default –location=global –retention-days=180
Criar um coletor (sink) para o BigQuery para logs de erro: gcloud logging sinks create bq-errors
bigquery.googleapis.com/projects/myproj/datasets/log_analytics
–log-filter=‘severity>=ERROR’
Ler 5xx recentes para o Cloud Run: gcloud logging read ‘resource.type=“cloud_run_revision” AND httpRequest.status>=500’ –limit=20

Cloud Monitoring

Métricas. Use as métricas do Google Cloud, métricas personalizadas e métricas baseadas em logs. Prefira rótulos de baixa cardinalidade; a explosão da cardinalidade dos rótulos causa problemas de custo e latência de consulta.
Painéis (Dashboards). Crie painéis selecionados por serviço e por dependência (banco de dados, cache, filas). Visualize os sinais RED (requisições, erros, duração) e USE (utilização, saturação, erros).
Políticas de alerta. Acione com base em limites, ausência de métricas, proporções, taxas de consumo de SLO (burn rates) ou falhas na verificação de tempo de atividade (uptime check). Configure canais de notificação (e-mail, SMS, PagerDuty, Pub/Sub, webhooks). Suprima a instabilidade (flapping) usando janelas de tempo (windowing) e alinhadores (aligners).
Verificações de tempo de atividade (Uptime checks). Sonde a partir de várias regiões; use verificações de tempo de atividade privadas para endpoints internos ou execute testes sintéticos de dentro da VPC.

Métricas baseadas em logs

Contadores (Counters) resumem ocorrências (por exemplo, contagem de requisições /api/alpha/*).
Distribuições (Distributions) capturam latência ou tamanhos de payload.
Exemplo: gcloud logging metrics create api_alpha_count
–description=“Count of /api/alpha/* requests”
–log-filter=‘httpRequest.requestUrl=~"/api/alpha/.*" AND resource.type=“cloud_run_revision”’

Análise operacional

Para análise ad hoc, encaminhe para o BigQuery por meio de um coletor (sink); projete esquemas e particionamento por timestamp para controlar o custo.
Use o Log Analytics nos buckets do Logging para agregar sem exportar, quando aplicável.
Crie sinais de capacidade a partir de métricas como CPU, memória, profundidade da fila, conexões do Cloud SQL, CPU de alta prioridade do Spanner, mensagens não confirmadas (unacked) do Pub/Sub e taxas de 429/5xx do Cloud Storage.

Armadilhas e trade-offs comuns

O excesso de logs (over-logging) aumenta o custo de ingestão e ofusca o sinal; prefira amostragem e disciplina de severidade.
A falta de IDs de correlação dificulta a triagem de incidentes; propague os IDs de rastreamento de ponta a ponta.
A retenção longa em buckets “quentes” (hot) aumenta o custo; exporte para um arquivo ou para o BigQuery para necessidades de longo prazo.

Rastreamento, Erros e Diagnóstico Aprofundado

Rastreamento distribuído

Contexto de rastreamento. Prefira o trace-context do W3C (traceparent, tracestate). Para interoperabilidade com o Cloud Trace, continue a suportar x-cloud-trace-context: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
Propagação. Encaminhe os cabeçalhos de rastreamento entre serviços, filas de mensagens e limites assíncronos; capture novos spans filhos ao fazer chamadas RPC ou SQL. A perda de contexto quebra os mapas de serviço e infla os nós de “serviço desconhecido”.
Amostragem. Equilibre custo e fidelidade; a amostragem dinâmica baseada no início (head-based) na entrada (ingress) e a amostragem baseada no final (tail-based) para requisições lentas e raras podem melhorar a utilidade.

Cloud Trace

Fornece histogramas de latência, cascata de spans (span waterfalls) e mapas de serviço. Use anotações para suboperações críticas (RPCs, consultas a banco de dados).
Diagnostique outliers usando rastreamentos p95/p99; observe fan-out, consultas N+1 ou contenção de locks.
Habilite a correlação entre rastreamento e log para que, ao clicar em um rastreamento, seus logs sejam revelados.

Error Reporting

Agrega exceções automaticamente por assinatura de pilha (stack signature) por serviço/versão. Configure o contexto do serviço para evitar a mesclagem entre serviços. Suprima erros conhecidos e ruidosos ou direcione-os para notificações de menor prioridade.
Redija PII das mensagens de exceção; em vez disso, registre códigos de erro estáveis e IDs de correlação.

Cloud Profiler

Profiling contínuo de CPU/heap com baixo overhead para runtimes suportados. Compare perfis entre versões e níveis de tráfego para detectar regressões. Evite interpretar artefatos de amostragem como contagens exatas.

Cloud Debugger

Snapshots capturam variáveis em um local do código sem pausar o processo. Logpoints injetam instruções de log temporárias. Restrinja o acesso, redija variáveis sensíveis e limite o escopo a expressões que não contenham PII.

Exemplo rápido: adicionar traceparent do W3C e correlacionar um log

Propagação HTTP: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Campo de log para vincular ao Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Engenharia de Confiabilidade, Alertas e Sinais de Saúde

SLIs, SLOs, SLAs e orçamentos de erro

SLIs medem a satisfação do usuário: disponibilidade, latência, corretude. Defina por endpoint crítico e jornada do usuário.
SLOs definem metas, por exemplo, 99,9% das requisições abaixo de 300 ms em 30 dias.
Orçamentos de erro (error budgets) quantificam a não confiabilidade permitida. Gaste os orçamentos em lançamentos, experimentos ou migrações; congele as alterações se a taxa de consumo (burn rate) for muito alta.
SLAs são compromissos externos; mantenha o SLO mais rigoroso que o SLA para proteger a margem.

Design de alertas de qualidade

Prefira alertas baseados em SLOs e sintomas em vez de alertas baseados em causas, sempre que possível.
Use alertas de múltiplas janelas e múltiplas taxas de consumo (multi-burn-rate) (por exemplo, 14x em 5 minutos e 2x em 1 hora) para capturar consumos rápidos e lentos, reduzindo o ruído.
Adicione ausência de métrica para watchdogs (por exemplo, heartbeat de um job de longa duração).
Roteie por severidade; limite a taxa de notificações (rate-limit); forneça links para runbooks e dashboards.

Verificações de saúde (health checks) e probes

Verificações de prontidão (readiness checks) bloqueiam o tráfego até que as dependências estejam prontas; verificações de atividade (liveness checks) acionam reinicializações em processos travados; probes de inicialização (startup probes) protegem aplicações de inicialização lenta contra reinicializações prematuras.
Para VMs com balanceamento de carga, permita os intervalos de origem do verificador de saúde, caso contrário o tráfego nunca chegará aos backends: gcloud compute firewall-rules create allow-lb
–network prod –allow tcp
–source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Exemplo para Kubernetes: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
Testes sintéticos. Use verificações de tempo de atividade (uptime checks) e fluxos de ponta a ponta personalizados via Cloud Scheduler + Cloud Run/Functions para validar login, pagamentos ou outros caminhos críticos.
Monitoramento de dependências. Acompanhe a saturação de conexões do banco de dados, taxas de erro de RPC, acúmulo em filas (backlogs), erros de egresso e SLIs de terceiros. Configure novas tentativas (retries) com backoff exponencial truncado para erros transitórios 429/5xx, com chaves de idempotência para segurança.

Resposta a Incidentes, Debugging Consciente da Segurança e Causa Raiz

Ciclo de vida da resposta a incidentes

Triagem: classificar a severidade, designar um comandante do incidente e acionar o plantonista (on-call) por meio de canais definidos.
Contenção: aplicar mitigações conhecidas e controles de tráfego (roll back, canary, circuit breaker, limitadores de taxa).
Comunicação: manter uma sala de guerra (war-room) interna, atualizar as partes interessadas (stakeholders) regularmente e publicar o status para os usuários quando necessário.
Resolução e recuperação: verificar a saúde por meio de SLIs; evitar um “tudo certo” prematuro.
Postmortem: analisar sem atribuição de culpa a linha do tempo, as lacunas na detecção, os fatores contribuintes e os itens de ação com responsáveis e prazos. Acompanhar até a conclusão.

Runbooks

Incluir gatilhos, contexto necessário, comandos de diagnóstico, mitigações seguras, etapas de rollback e caminhos de escalonamento. Adicionar links para dashboards, logs e playbooks para modos de falha específicos.

Monitoramento de cota e capacidade

Monitorar cotas de serviço por meio de métricas do Cloud Monitoring. Automatizar alertas para 70–80% de utilização e solicitar aumentos com antecedência para testes de carga ou lançamentos planejados.
Sinais de capacidade a serem acompanhados: CPU, memória, descritores de arquivo, pools de threads, conexões de banco de dados, limites do autoscaler e profundidade da fila de solicitações.

Debugging sem expor informações sensíveis

Redigir segredos e PII (Informações de Identificação Pessoal) na origem; centralizar segredos no Secret Manager. Usar hashing ou tokenização para identificadores de usuário. Habilitar a redação em nível de campo no middleware de logging.
Limitar o acesso a logs, traces e ferramentas de debug via IAM; usar CMEK e VPC Service Controls quando aplicável.
No Debugger, desabilitar a coleta de grandes grafos de objetos e adicionar condições para evitar a captura de frames sensíveis.

Análise de causa raiz (RCA) entre camadas

Runtime: correlacionar picos em GC, pools de threads ou CPU via Profiler com a latência p99 no Trace.
Rede: inspecionar logs do balanceador de carga, VPC Flow Logs, logs de firewall e Connectivity Tests para validar caminhos. Falhas de verificação de saúde (health-check) geralmente resultam de regras de firewall ausentes ou portas incorretas.
IAM: revisar os Cloud Audit Logs em busca de negações de permissão ou alterações de política; confirmar as funções da conta de serviço e os escopos dos tokens.
Dados: usar o Cloud SQL Insights, estatísticas de consulta do Spanner, CPU e hot tablets do Bigtable e taxas de erro do Storage para encontrar hotspots. Aplicar novas tentativas (retries) com backoff para falhas transitórias e reduzir o fan-out que amplifica a latência de cauda (tail latency).
Unificar tudo com IDs de trace correlacionados e métricas baseadas em logs; exportar para o BigQuery para executar joins de múltiplas fontes durante a análise pós-incidente.

Cenário de Problema Prático

A Fjord Retail migra um checkout multisserviço para o Google Cloud usando Cloud Run, Cloud SQL, Pub/Sub e uma API de impostos externa. Os usuários relatam timeouts intermitentes e picos nas taxas de erro durante promoções relâmpago (flash sales), e a equipe de plantão (on-call) recebe alertas ruidosos e de baixo sinal.

Abordagem:

Instrumentar logging estruturado com correlação de traces

Adicionar propagação de W3C traceparent entre os serviços e incluir logging.googleapis.com/trace em todos os logs. Justificativa: a correlação de ponta a ponta (end-to-end) permite que os engenheiros passem de uma solicitação de usuário lenta para o RPC ou a consulta lenta exata e seus logs.

Criar buckets, retenção e exportações do Logging

Aumentar a retenção do _Default para 90 dias e criar um bucket regional para cargas de trabalho na UE. Adicionar um coletor (sink) agregado ao BigQuery para logs de ERROR e WARNING:

undefined

Justificativa: uma retenção quente (hot) suficiente auxilia no debugging; o BigQuery permite análises rápidas de incidentes sem inflar os custos de armazenamento quente. 3) Definir SLIs/SLOs e alertas baseados em SLOs

SLI de disponibilidade: solicitações bem-sucedidas / total. SLI de latência: duração p95 para POST /checkout.
SLOs: 99,9% de disponibilidade mensal; 95% dos checkouts < 300 ms.
Configurar alertas de taxa de queima (burn-rate) de múltiplas janelas e um alerta de ausência de métrica para o heartbeat do checkout. Justificativa: alertas baseados em sintomas reduzem o ruído e acionam a equipe apenas quando há impacto para o usuário.

Configurar sondas de saúde (health probes) e verificações sintéticas

Os serviços do Cloud Run expõem /ready e /healthz. Adicionar uma verificação de tempo de atividade (uptime check) global para /checkout e uma tarefa sintética privada na VPC que realiza um checkout completo com credenciais de teste. Justificativa: a prontidão (readiness) impede que backends frios recebam tráfego; as verificações sintéticas detectam problemas de ponta a ponta e regressões de terceiros.

Habilitar o Cloud Trace e o Profiler e adotar novas tentativas (retries) com backoff

Instalar agentes do Trace/Profiler onde aplicável; habilitar a instrumentação automática de cliente HTTP e a anotação de span SQL. Implementar backoff exponencial truncado com chaves de idempotência para chamadas à API de impostos. Justificativa: o tracing isola os contribuidores de latência; o backoff reduz a amplificação de erros 429/5xx e protege os orçamentos de erro (error budgets).

Monitorar capacidade e cotas

Adicionar dashboards e alertas para conexões do Cloud SQL, CPU, buffer pool do InnoDB, mensagens não confirmadas (unacked) do Pub/Sub, simultaneidade do Cloud Run e uso de cotas de serviço. Justificativa: a saturação da capacidade é uma causa oculta comum da latência de cauda; alertas antecipados previnem interrupções.

Reforçar o debugging para privacidade

Usar IDs de usuário com hash e excluir PII de mensagens de erro. Restringir o Debugger à produção apenas com regras de redação e logpoints. Justificativa: manter a observabilidade em conformidade com a minimização de dados.

Construir monitores de dependência e circuit breakers

Acompanhar a taxa de sucesso e a latência da API de impostos externa por meio de métricas personalizadas; acionar um circuit breaker para usar taxas de imposto em cache quando as falhas excederem um limite. Justificativa: isolar falhas em dependências de terceiros e manter a disponibilidade do checkout principal.

Preparar runbooks e caminhos de escalonamento

Documentar os passos: verificar dashboards de SLO, checar o mapa de serviços do Trace em busca de arestas quentes (hot edges), inspecionar o Cloud SQL Insights em busca de consultas lentas, verificar firewall e health checks, e avaliar a margem de cota (quota headroom). Incluir procedimentos de rollback e canary. Justificativa: uma resposta consistente e rápida reduz o MTTR e evita alterações arriscadas e ad-hoc.

Pipeline de análise pós-incidente

Usar exportações do BigQuery para calcular taxas de erro por locatário (per-tenant) e para correlacionar logs com traces e insights do Cloud SQL por ID de trace. Justificativa: um histórico durável e consultável permite RCAs precisas e medidas de prevenção.

Este plano eleva a qualidade do sinal, encurta o tempo de detecção e resolução, protege a experiência do usuário durante picos e reforça a privacidade durante o debugging em produção.

← Entrega Contínua · Todos os domínios · Desempenho →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →