Google PCNE: Observabilidade de Rede, Confiabilidade e Solução de Problemas — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network 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 observabilidade de rede no Google Cloud é a coleta, correlação e análise disciplinada de sinais de rede que descrevem a alcançabilidade, o desempenho e a correção entre VPCs, balanceadores de carga, conexões híbridas e serviços. A confiabilidade resulta de um projeto que prevê a detecção de falhas e a remediação segura: instrumentar telemetria de primeira classe, validar o plano de controle antes de tocar no plano de dados, aprofundar a análise com evidências de pacotes apenas quando necessário e automatizar o rollback. Esta seção explica como usar as ferramentas e os padrões do Google Cloud para detectar, diagnosticar e prevenir problemas, minimizando o risco durante as mudanças.

Flow Logs, Logging, Monitoring, Metrics e SLOs

Os VPC Flow Logs fornecem telemetria amostrada e agregada na NIC da VM após a avaliação do firewall da VPC. Eles não são capturas de pacotes completas e não substituem o logging de regras de firewall para evidências explícitas de permissão (allow) ou negação (deny). Controles principais:

• Amostragem (Sampling): 0.0–1.0. Uma amostragem maior melhora a fidelidade ao custo de maior volume de logs e custo potencial.
• Intervalo de agregação: 5s–30m. Intervalos mais curtos reduzem o tempo de detecção, mas aumentam o número de entradas.
• Metadados (Metadata): incluir ou excluir metadados da instância e da VPC. Inclua para análises mais ricas, exclua para limitar atributos sensíveis.

Habilitação típica em uma sub-rede (subnet):

undefined

Exporte com coletores de logs (log sinks) para análise durável e compartilhamento entre projetos:

• BigQuery para análises SQL e análise de tendências de longo prazo.
• Pub/Sub para pipelines quase em tempo real para SIEM/IDS.
• Cloud Storage para arquivamento.

• Exemplo de coletor (sink) para o BigQuery:

undefined

O logging de regras de firewall complementa os flow logs registrando as decisões de permissão/negação e as regras correspondentes. Para observar o tráfego bloqueado, adicione uma regra de negação total (deny-all) com logging próximo ao final do seu conjunto de regras:

undefined

O Cloud Logging permite consultas estruturadas e correlação com logs de requisição, logs de verificação de saúde (health-check), logs de NAT e logs de balanceador de carga (load-balancer). Crie métricas baseadas em logs para sinais como:

• Aumentos repentinos em conexões negadas para tags de backend (possíveis allowlists mal configuradas).
• Altos volumes de retransmissões SYN para uma porta (possível saturação ou blackholing).
• Eventos de “nenhuma porta disponível” (no available ports) do NAT (esgotamento do Cloud NAT).

O Cloud Monitoring agrega métricas e fornece dashboards, alertas e SLOs:

• Métricas para observar: taxa de erros 5xx do balanceador de carga, latência do backend, bytes/pacotes da NIC da instância, portas alocadas/usadas/em overflow do Cloud NAT, status da sessão BGP do Cloud Router, quedas de pacotes em túneis VPN, utilização do link do Interconnect, perda de pacotes e latência.
• Dashboards: crie dashboards por serviço e por conectividade com templates compartilhados entre projetos para operações consistentes.
• Alertas: prefira alertas de sintomas (taxa de erro, latência, contadores de queda) com feedback rápido, e alertas de causa (oscilação de BGP, link inativo) com acionamento de sobreaviso (paging) quando o impacto para o usuário é provável.
• SLOs: defina SLOs centrados no usuário (por exemplo, sucesso e latência de HTTP global) e alertas de burn-rate para identificar queimas rápidas e lentas. Use logs de requisição como numerador/denominador através de métricas baseadas em logs para uma avaliação precisa do SLO.

Compromissos e modos de falha:

• Amostragem baixa ou agregação longa ocultam microbursts e falhas de curta duração.
• Os flow logs não têm visibilidade de descartes pré-firewall; dependa do logging de regras de firewall para evidências de negação.
• O excesso de logs sem filtragem aumenta o custo e pode retardar as investigações; exporte e particione os dados de forma inteligente.

Network Intelligence Center e Diagnósticos Avançados

O Network Intelligence Center (NIC) fornece diagnósticos proativos e estruturados:

Connectivity Tests:

• Valida a alcançabilidade do plano de controle através de rotas, regras de firewall (incluindo políticas hierárquicas), contas de serviço/tags, balanceadores de carga, Cloud NAT e conectividade híbrida.
• Os diagnósticos de rota calculam o próximo salto (next hop) selecionado e relatam configurações incorretas, como rotas ausentes ou caminhos assimétricos.
• Use antes e depois de qualquer mudança na rede para detectar um raio de impacto (blast radius) não intencional. Ele modela o plano de controle e não garante a qualidade do plano de dados; combine-o com evidências de pacotes/métricas.

Performance Dashboard:

• Visão gerenciada pelo Google da perda de pacotes e latência entre regiões e para pontos de observação da internet. Útil para detectar eventos macro (congestionamento regional ou em todo o caminho) em vez de problemas locais do serviço.

Network Topology:

• Visualiza conexões entre projetos, entre VPCs e híbridas, bem como os volumes de tráfego (aproveitando os logs) para identificar pontos de acesso intenso (hot spots), caminhos de peering inesperados e comportamentos transitivos que você pode não ter a intenção de criar.

Firewall Insights:

• Detecta regras ofuscadas (shadowed rules), permissões não utilizadas, origens excessivamente permissivas e regras sem tags/contas de serviço de destino. Ele recomenda regras mais restritivas para reduzir a superfície de ataque sem interromper os fluxos conhecidos.

Network Analyzer:

• Verificações de configuração estáticas e dinâmicas entre projetos para expor condições como:
  • Verificações de saúde (health checks) bloqueadas por firewall (lembre-se de permitir os intervalos de IP de origem das verificações de saúde do Google).
  • Backends de balanceador de carga em regiões erradas ou sem as portas nomeadas (named ports).
  • Sub-redes com o Private Google Access desativado, bloqueando o acesso à API para instâncias sem IPs externos.
  • Rotas que causam blackhole para prefixos importantes ou roteamento assimétrico através de VPNs/Interconnects.

Orientação operacional:

• Incorpore as verificações do NIC no CI/CD para mudanças de rede e execute-as de forma agendada. Trate os achados como dívida de confiabilidade e priorize as correções com impacto na redução de riscos.

Espelhamento de Pacotes, Balanceadores de Carga e Telemetria Híbrida

Packet Mirroring:

• Espelha o tráfego da VM para um coletor (appliance ou IDS gerenciado) para inspeção profunda. Defina o escopo por sub-rede, tags de rede ou contas de serviço; restrinja aos protocolos necessários para controlar os custos.
• Sobrecargas e trade-offs: o tráfego de saída espelhado incorre em custos; o espelhamento excessivo pode sobrecarregar os coletores; não espelhe indiscriminadamente em produção. Use sessões com tempo limitado e escopo restrito para incidentes.
• Integração com IDS:
  • O Cloud IDS fornece detecção de ameaças gerenciada e fora de banda (out-of-band) utilizando o Packet Mirroring. Prefira-o para ativação rápida e redução da manutenção.
  • Appliances de IDS de terceiros continuam viáveis onde assinaturas específicas ou ecossistemas de fornecedores são necessários.

Logs de balanceador de carga e evidências de verificação de integridade:

• Os logs de requisição do balanceador de carga HTTP(S) incluem método, URL, backend, código de resposta, latência e IPs do cliente via X-Forwarded-For. Use-os para análise do caminho do cliente, pois o traceroute para nos Google Front Ends (GFEs).
• Habilite os logs nos serviços de backend e configure a amostragem para equilibrar custo versus visibilidade. Ative o logging da verificação de integridade para ver os resultados das sondas (probes) e os motivos das falhas.
• Restringindo o acesso do cliente: aplique nos backends marcando instâncias com tags e criando regras de firewall que permitem apenas faixas de IP de clientes aprovados e IPs de verificação de integridade do Google. Para mitigação de ameaças L7 e implementação gradual, use as regras do Cloud Armor no modo de visualização (preview) antes de aplicá-las.

Telemetria de VPN e Interconnect:

• Métricas do Cloud VPN (HA VPN): bytes, descartes (drops), erros de criptografia, tempo de atividade do túnel (uptime) e estado da sessão BGP. Crie alertas para descartes de pacotes, eventos DPD frequentes e oscilações de BGP (BGP flaps).
• Escalonamento de throughput: adicione túneis para IPs de peer distintos e distribua o tráfego; monitore a capacidade ociosa (headroom). Se você precisar de ativo/standby entre Cloud Routers, prefira o atributo MED on-prem para influenciar a seleção de caminho.
• Métricas do Interconnect: utilização por link, erros de CRC e disponibilidade; observe a utilização sustentada >60–70% e picos de erro. Mantenha capacidade de reserva e circuitos diversificados. Investigue aumentos de latência com retransmissões e indicadores de enfileiramento.
• Sinais de saturação nas bordas: aumento de retransmissões TCP, aumento da latência do 99º percentil sem alterações no código, eventos de estouro de porta NAT e alertas de ocupação de fila são avisos precoces de um impacto iminente.

Metodologia de Solução de Problemas, Gerenciamento de Incidentes e Confiabilidade Proativa

Solução de problemas estruturada do DNS à aplicação:

1. Identifique a jornada do usuário que está falhando e a janela de tempo; localize a região e o caminho (público via LB, privado via VPC ou híbrido).
2. DNS:

• Valide a resolução com os logs do Cloud DNS, a saída do comando dig e o comportamento da política. Verifique conflitos de split-horizon e garanta que as políticas de encaminhamento estejam em vigor.
• Confirme os TTLs e as alterações recentes; caches obsoletos podem simular interrupções.

3. Balanceador de carga e borda:

• Revise os logs de requisição e de verificação de integridade (health-check). Correlacione picos de 5xx com a saúde do backend e eventos de implantação. Para L7, confie nos logs de requisição em vez do traceroute.
• Verifique as listas de permissão (allowlists) de clientes e os IPs de verificação de integridade do Google nas regras de firewall quando o acesso é restrito.

4. Roteamento e firewall:

• Use o Connectivity Tests para uma avaliação determinística do plano de controle. Inspecione as rotas efetivas e as políticas de firewall hierárquicas. Procure por roteamento assimétrico e regras sobrepostas (shadowed rules).
• Para pacotes negados, confie nos logs de regras de firewall; considere adicionar uma regra deny-all com logging ativado perto do final da pilha de prioridade durante as investigações.

5. Saída (egress) para APIs do Google:

• Se as instâncias não tiverem IPs externos, confirme o Private Google Access e/ou o Cloud NAT. A falta de um deles resulta em falhas intermitentes e timeouts confusos.

6. Híbrido:

• Examine as métricas do Cloud Router e do VPN/Interconnect. BGP ativo, mas rotas não instaladas podem refletir preferências de atributos; verifique MED/local-pref e ASNs. Observe quedas de pacotes (packet drops) e problemas de MTU do caminho.

7. Evidência de pacotes:

• Se o plano de controle parece correto, mas os sintomas persistem, use o Packet Mirroring de forma restrita para coletar PCAP perto da VM ou da camada afetada; verifique o tempo de SYN/SYN-ACK, retransmissões e os bits MSS/DF para blackholes de MTU.

Gerenciamento de incidentes:

• Segurança nas alterações: implemente as alterações em estágios, definindo o escopo para tags/contas de serviço, com menor precedência e com regras desabilitadas; habilite o logging e teste com canaries. Use o modo de visualização (preview) do Cloud Armor para alterações de política L7.
• Reversão (Rollback): pré-defina as alterações inversas, mantenha as configurações anteriores no controle de versão e use feature flags de curta duração na borda da aplicação, quando aplicável.
• Análise pós-incidente: construa uma linha do tempo a partir de logs e métricas, classifique os fatores contribuintes (ex: regra permissiva sobreposta por uma de negação, esgotamento de NAT), registre lacunas na detecção e adicione salvaguardas: alertas, verificações de NIC e endurecimento de políticas (policy hardening).

Planejamento de capacidade e confiabilidade proativa:

• Monitore as metas de margem de capacidade (headroom): 30–50% nos links de VPN/Interconnect, uso de portas NAT abaixo de 60% de forma sustentada, CPU e QPS do backend do LB bem abaixo dos gatilhos de autoescalonamento.
• Crie métricas baseadas em logs para riscos-chave: picos de negação (deny), estouro de NAT (overflow), contagens de BGP flap, taxas de 5xx e erros de conexão do backend do LB. Use alertas de burn-rate de múltiplas janelas para capturar tanto incidentes rápidos quanto lentos.
• Monitoramento sintético: use Uptime Checks de múltiplas regiões para endpoints públicos e sondas privadas de VMs de teste para serviços internos.
• Melhorias preventivas: refine as regras de firewall usando o Firewall Insights, resolva os achados do Network Analyzer, reduza o tempo de agregação do Flow Log durante eventos de pico e exporte os logs para o BigQuery para detecção recorrente de anomalias.

Cenário de Problema Prático

A Contoso Games opera uma API de jogos global com balanceamento de carga HTTP(S) em us-east1 e europe-west1, com HA VPN para um data center on-premise. Usuários na Europa relatam timeouts intermitentes e latência mais alta após uma recente alteração no firewall. As instâncias não têm IPs externos e devem acessar as APIs do Google de forma privada.

Abordagem:

1. Estabelecer a janela de tempo e o impacto no SLO

• Justificativa: Delimitar a janela restringe as consultas aos logs relevantes e alinha a investigação com os SLOs que impactam o usuário. Um alerta de burn-rate confirma um consumo rápido do SLO em europe-west1.

2. Validar o plano de controle com o Connectivity Tests

• Justificativa: Crie um teste do frontend do balanceador de carga HTTP(S) externo para o serviço de backend em europe-west1 e das VMs afetadas para um VIP do Private Google Access. O teste sinaliza uma política de firewall hierárquica bloqueando as verificações de integridade para alguns backends e a falta do Private Google Access para uma sub-rede.

3. Confirmar a saúde da borda e do backend via logs

• Justificativa: Filtre os logs de requisição do balanceador de carga para europe-west1 e response_code >= 500 para isolar os erros do backend. Os logs de verificação de integridade mostram falhas de sonda a partir dos IPs de origem conhecidos de verificação de integridade do Google. Isso evidencia uma instabilidade (flapping) do backend induzida pelo firewall, em vez de regressões na aplicação.

4. Restaurar a saúde e proteger a segurança com alterações de escopo limitado

• Justificativa: Adicione uma regra de permissão (allow) direcionada às tags do backend que permita os intervalos de origem da verificação de integridade. Habilite o logging nesta regra. Como o acesso é restrito a clientes conhecidos, verifique se a regra de firewall da lista de permissão (allowlist) inclui apenas os intervalos de IP de cliente específicos e os intervalos da verificação de integridade. Mantenha a nova regra inicialmente desabilitada e, em seguida, habilite-a durante um período de baixo tráfego (canary) para limitar o raio de impacto (blast radius).

5. Restabelecer a saída privada para as APIs do Google

• Justificativa: Habilite o Private Google Access na sub-rede afetada para que as instâncias sem IPs externos acessem os serviços do Google sem fazer hairpinning através da VPN ou de firewalls de terceiros. Isso reduz a latência e remove um ponto de estrangulamento (choke point).

6. Verificar a saturação do ambiente híbrido e o MTU

• Justificativa: Revise as métricas do HA VPN para quedas de pacotes e utilização. Um túnel mostra quedas elevadas. Aumente a capacidade adicionando um segundo túnel para um IP de peer on-premise diferente e distribua o tráfego. Verifique o MTU efetivo e o MSS clamp para evitar blackholes de PMTU no caminho da VPN.

7. Usar o modo de visualização (preview) do Cloud Armor para clientes suspeitos de abuso

• Justificativa: A partir dos logs de requisição, um pequeno conjunto de IPs de clientes causa picos de tráfego pouco antes das falhas de sonda. Adicione uma regra de negação (deny) no Cloud Armor com o modo de visualização para validar que o bloqueio reduziria a carga do backend antes de aplicá-lo, evitando impacto acidental ao usuário.

8. Usar o Packet Mirroring de forma restrita para confirmar o comportamento do plano de dados

• Justificativa: Espelhe o tráfego de uma única VM de backend com problemas para o Cloud IDS por 15 minutos. O PCAP mostra esgotamento do backlog de SYN durante picos de tráfego dos IPs abusivos, corroborando a utilidade da política do Cloud Armor e a necessidade de limitação de taxa (rate limiting).

9. Encerrar o incidente e fortalecer o ambiente (harden)

• Justificativa: Após habilitar a regra de permissão da verificação de integridade, confirmar o Private Google Access, escalar a capacidade da VPN e aplicar a regra do Cloud Armor validada, as taxas de erro retornam à linha de base. Adicione dashboards para a taxa de sucesso da verificação de integridade, uso de portas NAT, quedas na VPN e 5xx por região. Crie alertas baseados em logs para negações do firewall para as tags de backend e alertas de burn-rate do SLO. Registre o incidente, as causas raiz (alteração no firewall hierárquico; tráfego abusivo; saturação da VPN) e adicione verificações do NIC Analyzer e do Firewall Insights à checklist de pré-alteração.

Esta sequência demonstra um fluxo de trabalho seguro e orientado por evidências: confirmar o plano de controle, observar o plano de dados, aplicar alterações mínimas e reversíveis e, em seguida, institucionalizar os aprendizados com alertas e verificações automatizadas.

← GKE · Todos os domínios · Automação de Rede →

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

Navegar Google →