Google ACE: Monitoramento, Geração de Registros e Solução de Problemas Operacionais — Guia de estudos

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Faz parte do Google Associate Cloud Engineer — 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 excelência operacional no Google Cloud depende da conversão de telemetria em ação. Monitoramento, Logging e Solução de Problemas (Troubleshooting) juntos fornecem os sinais, as barreiras de proteção (guardrails) e os fluxos de trabalho que mantêm os serviços confiáveis. Esta seção aborda os principais serviços de observabilidade, ferramentas de diagnóstico, práticas de confiabilidade e operações de incidentes, com justificativas de design, trade-offs e modos de falha comuns.

Fundamentos de Monitoramento e Alertas

O Cloud Monitoring ingere séries temporais de serviços do Google Cloud, agentes e métricas personalizadas para fornecer dashboards, verificações de tempo de atividade (uptime checks), SLOs e alertas.

Métricas e cardinalidade
- Tipos de recursos monitorados (por exemplo, gce_instance, aws_ec2_instance, global) definem o escopo de dimensões como projeto, região e ID da instância.
- Minimize valores de rótulos (labels) ilimitados (por exemplo, user_id) para evitar explosões de alta cardinalidade que tornam as consultas lentas e aumentam o custo.
- Prefira métricas de distribuição para latência (p50/p90/p99) e use janelas de alinhamento para rollups consistentes.
Dashboards
- Use os dashboards de serviço integrados para um início rápido. Crie dashboards personalizados para agrupar métricas de vários projetos. Organize os painéis por sintoma (latência, erros, saturação) antes da causa (CPU, memória).
- Evite gráficos por instância para frotas (fleets); agregue por serviço, zona ou MIG para reduzir o ruído e aumentar o sinal.
Políticas de alerta
- Crie alertas baseados em sintomas vinculados à experiência do usuário: queima de SLO de disponibilidade (availability SLO burn), percentis de latência, taxas de erro. Use alertas de múltiplas janelas e múltiplas taxas de queima (multi-window, multi-burn-rate) para capturar queimas rápidas e lentas (por exemplo, 2% em 1 hora e 5% em 5 minutos).
- Defina limites de taxa de notificação e comportamentos de fechamento automático razoáveis. Use anotações de mitigação automática de incidentes para documentar runbooks.
- Use alertas de ausência de métrica para jobs em lote (batch) críticos e pipelines de dados com agendamentos rigorosos.
- Métricas baseadas em logs suportam alertas para eventos de aplicação ou segurança (por exemplo, repetidos permissionDenied).
Canais de notificação
- Configure canais por severidade: acionamento (paging) para SEV1 (plantonista/on-call, SMS, telefone), chat para SEV2/3, e-mail ou webhooks para baixa prioridade. Use o Pub/Sub para integração com sistemas de tickets ou automação.
- Teste os canais periodicamente; canais desatualizados são um modo de falha silencioso.
Verificações de tempo de atividade (uptime checks) e monitoramento sintético
- Verificações HTTP(S) e TCP de pontos de observação globais (vantage points) verificam a alcançabilidade externa. Combine as verificações com a correspondência de conteúdo (content match) para detectar falhas parciais.
- Use verificações de tempo de atividade privadas via conectividade híbrida ou Private Service Connect para serviços internos.
- Modos de falha: as verificações podem falhar devido a atraso no TTL do DNS, problemas na rotação de certificados TLS ou interrupções no escopo da região; corrobore com as métricas antes de acionar o plantão (paging).
Monitoramento de múltiplos projetos
- Use um único workspace do Monitoring e vincule todos os projetos para ter dashboards e alertas consolidados. Isso simplifica os SLOs de toda a frota e reduz a duplicação.

Logging, Auditoria e Diagnóstico de Aplicações

O Cloud Logging é o roteador, o armazenamento e o plano de consulta para logs de plataforma e de aplicação. Ferramentas de APM complementares (Error Reporting, Trace, Profiler) aceleram o isolamento da causa raiz.

Roteamento de logs, buckets, coletores (sinks) e retenção
- Roteie com coletores (sinks) para buckets de log (padrão ou personalizados), BigQuery (análise de dados), Pub/Sub (processamento de stream) ou Cloud Storage (arquivamento).
- Use buckets de log com escopo regional para residência de dados e desempenho. Aplique CMEK se exigido por conformidade.
- Defina a retenção por bucket (por exemplo, 30–90 dias para operações, vários anos para auditoria). Uma retenção mais longa aumenta o custo; filtre agressivamente para controlar os gastos.
- Exclusões reduzem a ingestão de logs detalhados (verbosos) (por exemplo, verificações de saúde/health checks). Valide os filtros para evitar a remoção não intencional de logs críticos.
Exemplo: criar um coletor (sink) para o BigQuery para logs de auditoria

undefined

Exemplo: criar uma exclusão

undefined

Consultas e Log Explorer
- Use filtros avançados em resource.type, severity, rótulos (labels) e payloads JSON. Salve consultas para caminhos de triagem comuns (falhas de inicialização, permissionDenied, quotaExceeded).
- Crie métricas baseadas em logs do tipo distribuição e contador para alertas e dashboards.
Cloud Audit Logs
- Logs de Atividade do Administrador (Admin Activity): sempre ativos, sem custo de ingestão; registram operações de escrita administrativas (por exemplo, createInstance).
- Logs de Acesso a Dados (Data Access): registram operações de leitura e escrita no plano de dados (data-plane) (por exemplo, storage.objects.get). Desativados por padrão para muitos serviços; ative seletivamente, pois o volume e o custo podem ser altos.
- Logs de Eventos do Sistema (System Event): ações do sistema do Google (por exemplo, autoscaler, migração em tempo real para manutenção).
- Logs de Política Negada (Policy Denied): registros explícitos de negações de políticas do IAM e da organização. Críticos para a solução de problemas de acesso e revisões de segurança.
- Roteie os logs de auditoria para o BigQuery para retenção e investigação; indexe rótulos como authenticationInfo.principalEmail para atribuições.
Error Reporting, Trace e Profiler
- O Error Reporting agrupa automaticamente stack traces por serviço e versão; integre com canais de notificação para novos grupos de erros e picos repentinos.
- O Cloud Trace coleta distribuições de latência de requisições e spans; defina a amostragem (sampling) para equilibrar a sobrecarga (overhead) e a fidelidade (por exemplo, 1 em 1000 para serviços de alto QPS, com amostragem baseada em cauda/tail-based sampling se estiver usando coletores OpenTelemetry).
- O Profiler fornece profiling contínuo de CPU/heap com baixa sobrecarga (overhead) em produção. Limite a caminhos críticos (hot paths) ou cargas de trabalho representativas para controlar o volume de dados e a sobrecarga. Use o mapeamento de código-fonte (source mapping) para obter grafos de chamadas legíveis.
- Trade-offs: uma amostragem mais alta melhora o diagnóstico, mas aumenta o custo e a exposição potencial de PII (informações de identificação pessoal); remova (scrub) campos sensíveis e use tokenização.

Solução de Problemas de Serviços, Recursos e Redes

A solução de problemas eficiente parte dos sintomas para os limites do sistema e, em seguida, para os recursos e dependências.

Integridade de serviços gerenciados, status do serviço, cotas, incidentes regionais
- Valide se um incidente é upstream: verifique a integridade do serviço e os avisos regionais recentes. Procure por picos de erros, latência elevada ou erros de cota.
- As cotas são por projeto e, muitas vezes, por região; quotaExceeded e rateLimitExceeded nos logs indicam throttling. Solicite aumentos antes de eventos de pico.
- Modo de falha: interrupções regionais parciais podem aparecer como erros intermitentes; configure o failover multirregional sempre que possível.
Integridade de recursos e diagnósticos de VM
- Use operações de instância, eventos de manutenção e verificações de integridade (health checks). Para MIGs, inspecione reinicializações do autohealing e falhas de health check para isolar imagens ou configurações problemáticas.
- Console serial da VM para mensagens de boot e do kernel:
  - gcloud compute connect-to-serial-port VM_NAME –zone=ZONE
  - Causas comuns: kernel panics, entradas incorretas no fstab que bloqueiam o boot, configurações de rede incorretas, configuração incorreta do OS Login causando falhas de SSH.
- Garanta o uso do OS Login com chaves SSH por usuário e papéis do IAM (compute.osLogin ou compute.osAdminLogin) para acesso atribuível.
Logs Explorer para análise de falhas
- Comece com os logs de sintomas (5xx, deadlineExceeded), pivoteie por labels de recursos e, em seguida, correlacione com alterações de implantação e logs de cota. Use as visualizações de histograma para localizar os pontos de mudança.
Observabilidade de rede
- VPC Flow Logs: amostragem por VNIC do tráfego de 5 tuplas; habilite nas sub-redes. Ajuste a amostragem (por exemplo, 0.5) e as opções de metadados para equilibrar desempenho e detalhe.
  - gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –flow-sampling=0.5 –aggregation-interval=interval-5-min –metadata=include-all
- Logging de firewall: capture decisões de permitir/negar (allow/deny) em regras críticas para diagnosticar bloqueios inesperados ou shadowing (regras sobrepostas).
  - gcloud compute firewall-rules update RULE_NAME –enable-logging
- Connectivity Tests: modele e verifique a alcançabilidade entre VPCs, peering, Cloud VPN, Cloud Interconnect e regras de firewall. Útil para validação pré-mudança e triagem de incidentes.
  - gcloud network-management connectivity-tests create test-a –source-instance=projects/PRJ/zones/ZONE/instances/VM1 –destination-ip=10.0.3.21 –protocol=TCP –destination-port=443
- Sinais complementares: logs do Cloud NAT e do balanceador de carga para problemas de saída (egress) e de borda. Os modos de falha incluem roteamento assimétrico, rotas ausentes, regras de firewall em ordem incorreta e restrições de políticas.

Confiabilidade, SLOs e Operações de Incidentes

A disciplina operacional vincula a telemetria aos objetivos de impacto no usuário e à execução consistente de incidentes.

SLOs, orçamentos de erro e linhas de base
- Defina SLOs em SLIs centrados no usuário (disponibilidade, latência, correção). Exemplo: 99,9% das solicitações de leitura são concluídas em menos de 200 ms ao longo de 30 dias.
- Monitore orçamentos de erro e crie dashboards consolidados por serviço e versão de lançamento. Controle os rollouts com base no consumo do orçamento.
- Estabeleça linhas de base de desempenho antes dos aumentos de tráfego; regressões são detectadas por desvio, não por valores absolutos.
Redução de ruído de alertas
- Prefira alertas em nível de serviço em vez de em nível de instância. Use condições baseadas em taxa de mudança e percentis. Aplique limitação de notificações, fechamento automático de incidentes e silenciamento de alertas para janelas de manutenção.
- Desduplique alertas por meio de labels e políticas comuns; use roteamento ciente de dependências para evitar o acionamento (paging) tanto para o banco de dados quanto para a aplicação no mesmo incidente.
Fluxo de trabalho de resposta a incidentes
- Faça a triagem e declare a severidade; atribua papéis (comandante do incidente, operações, comunicações, escriba).
- Caminhos de escalonamento: rotações de plantão (on-call), especialistas no assunto e suporte do fornecedor (inclua ID do projeto, IDs de solicitação, timestamps e regiões nos tickets de suporte).
- Comunicação: mantenha uma fonte única da verdade (canal de chat e documento do incidente). Forneça atualizações periódicas para as partes interessadas (stakeholders) com impacto, mitigação e ETAs.
- Playbooks de mitigação: rollback, failover, desativação de feature flag ou adição de capacidade. Prefira alterações reversíveis com um raio de impacto (blast radius) curto.
Revisão pós-incidente e RCA (Análise de Causa Raiz)
- Orientada por evidências: correlacione métricas, logs, traces e eventos de mudança. Inclua quais sinais de detecção dispararam, por que ou por que não, e o tempo para detectar/mitigar.
- Identifique fatores contribuintes, não apenas a causa imediata. Capture itens de ação concretos com responsáveis e prazos; atualize runbooks e alertas de acordo.
- A cultura sem culpa (blameless) incentiva a divulgação completa e correções sistêmicas.
Runbooks operacionais
- Estrutura: gatilho e detecção, árvore de diagnóstico rápido, mitigações seguras, passos de rollback/restauração, verificação e critérios de saída.
- Mantenha comandos e filtros prontos para copiar e colar; verifique o IAM de privilégio mínimo para a equipe de resposta (por exemplo, storage.objectCreator para backups somente de escrita; contas de serviço dedicadas para identidade de carga de trabalho).
- Versione runbooks com gerenciamento de mudanças; teste durante game days.

Cenário de Problema Prático

A Northwind Outfitters opera uma plataforma de e-commerce regional no Google Cloud. Após um pico recente de tráfego, os usuários relatam intermitentemente timeouts no checkout e lentidão nas buscas de produtos. A equipe de operações precisa restaurar rapidamente a confiabilidade, reduzir o ruído de alertas e reforçar os diagnósticos em múltiplos projetos.

Abordagem:

Consolidar o monitoramento entre projetos

Ação: Criar um único workspace do Monitoring e vincular os projetos de produção (prod), pagamentos (payments) e busca (search). Construir um dashboard de “Jornada do Usuário” mostrando disponibilidade, latência e taxas de erro para o checkout e a busca.
Justificativa: A visibilidade centralizada apoia a triagem em nível de serviço e correlaciona problemas entre serviços (por exemplo, latência na busca causando timeouts em cascata no checkout).

Implementar SLOs e alertas de burn rate

Ação: Definir SLOs: 99,9% de checkouts em menos de 400 ms, 99,95% de buscas em menos de 250 ms. Criar alertas de burn rate de múltiplas janelas (2% em 1 hora e 5% em 5 minutos) sobre os SLIs de latência e taxa de erro. Notificar o plantão (on-call) via pager e as partes interessadas (stakeholders) via chat.
Justificativa: Alertas de burn rate capturam regressões rápidas e “queimas lentas” sustentadas sem acionar o plantão (paging) por variações normais.

Adicionar verificações sintéticas de tempo de atividade (uptime) com correspondência de conteúdo

Ação: Configurar verificações de uptime TCP e HTTPS para os pontos de entrada públicos e uma verificação de uptime privada para a API de pagamento interna, validando que o corpo da resposta contém “ok”.
Justificativa: Detecta alcançabilidade e falhas parciais, como backends com roteamento incorreto ou upstreams degradados.

Ajustar rotas e retenção de logs

Ação: Criar buckets de log dedicados: ops (90 dias), auditoria de segurança (2 anos, CMEK). Roteie os logs de Admin Activity, Data Access, System Event e Policy Denied para o BigQuery por meio de coletores (sinks) para análise. Adicionar exclusões para health checks “falantes” (chatty).
Justificativa: A retenção dimensionada corretamente controla os custos; o BigQuery permite uma análise forense rápida. Exclusões reduzem o ruído sem perder evidências críticas.

Habilitar diagnósticos de aplicação

Ação: Instrumentar serviços com OpenTelemetry para Trace; habilitar o Error Reporting para backend e frontend; implantar o Profiler no serviço de checkout com perfis de CPU e heap em uma amostragem conservadora.
Justificativa: Traces identificam os caminhos críticos (hot paths) de latência; o Error Reporting destaca novos grupos de erros; o Profiler revela contenção de CPU e vazamentos de memória com baixo overhead.

Fortalecer a observabilidade da rede

Ação: Habilitar VPC Flow Logs nas sub-redes de produção (amostragem de 0.5, incluir todos os metadados) e logging de firewall nas regras de permissão/negação (allow/deny) para tráfego de entrada (ingress) para busca e pagamentos. Criar Connectivity Tests da camada web para a de busca e da de pagamentos para o Cloud SQL.
Justificativa: Logs de fluxo e de firewall expõem pacotes descartados (drops), retransmissões e regras sobrepostas (shadowed rules); os Connectivity Tests validam a alcançabilidade e identificam configurações incorretas.

Diagnósticos em nível de recurso e acesso seguro

Ação: Para VMs instáveis, inspecione problemas de inicialização (boot) com o console serial:

undefined

Se o SSH for necessário, imponha o uso do OS Login e conceda compute.osAdminLogin ao grupo “ops-admins”. Cada administrador usa sua própria chave SSH.
Justificativa: Logs seriais revelam falhas de kernel e de inicialização (init). O OS Login com chaves por usuário garante acesso atribuível e de privilégio mínimo.

Verificação de cota e de saúde regional

Ação: Revisar eventos quotaExceeded recentes nos logs; aumentar a cota regional de API e de IP para o autoscaling da busca. Verificar os avisos de saúde do serviço para a região impactada; desviar o tráfego temporariamente com a ponderação do balanceador de carga.
Justificativa: Limitação por cota (throttling) e incidentes regionais são fontes comuns de falhas intermitentes; escalonamento proativo e direcionamento de tráfego mitigam o impacto.

Redução de ruído e atualizações de runbooks

Ação: Substituir alertas de CPU por instância por alertas de saturação em nível de serviço. Adicionar janelas de manutenção para silenciar alertas não acionáveis. Atualizar runbooks com novas consultas de triagem, dashboards de trace e procedimentos de rollback.
Justificativa: Reduz a fadiga de acionamentos (paging) e acelera respostas consistentes e seguras.

Revisão pós-incidente e ações

Ação: Conduzir uma revisão sem culpa (blameless). Correlacionar incidentes de burn rate com o aumento da latência de cauda (tail latency) da busca e um rollout recente de índice. Itens de ação: adicionar lançamentos canary para a busca, proteções (guardrails) para o tamanho do índice e folga (headroom) no autoscaler; comprometer-se com testes periódicos do canal de alertas.
Justificativa: A RCA orientada por evidências previne a recorrência e melhora a detecção, a mitigação e a resiliência.

← Implantação · Todos os domínios · Segurança →

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