Google PCNE: Observabilidad de red, confiabilidad y solución de problemas — Guía de estudio

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

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La observabilidad de red en Google Cloud es la recopilación, correlación y análisis disciplinados de señales de red que describen la alcanzabilidad, el rendimiento y la corrección a través de VPC, balanceadores de carga, conexiones híbridas y servicios. La fiabilidad se consigue diseñando para la detección de fallos y la remediación segura: instrumentar telemetría de primera clase, validar el plano de control antes de tocar el plano de datos, profundizar con evidencia de paquetes solo cuando sea necesario y automatizar la reversión (rollback). Esta sección explica cómo usar las herramientas y patrones de Google Cloud para detectar, diagnosticar y prevenir problemas mientras se minimiza el riesgo durante los cambios.

Flow Logs, Logging, Monitoring, Métricas y SLO

Los VPC Flow Logs proporcionan telemetría muestreada y agregada en la NIC de la VM después de la evaluación del firewall de la VPC. No son capturas de paquetes completas y no reemplazan el registro de reglas de firewall para obtener evidencia explícita de permisos/denegaciones (allow/deny). Controles clave:

Muestreo (Sampling): 0.0–1.0. Un muestreo más alto mejora la fidelidad a costa del volumen de registros y un posible aumento del costo.
Intervalo de agregación: 5s–30m. Intervalos más cortos reducen el tiempo de detección pero aumentan el número de entradas.
Metadatos: incluir o excluir metadatos de la instancia y de la VPC. Incluirlos para un análisis más enriquecido, excluirlos para limitar atributos sensibles.

Habilitación típica en una subred:

undefined

Exportar con receptores de registros (log sinks) para un análisis duradero y para compartir entre proyectos:

BigQuery para análisis SQL y análisis de tendencias a largo plazo.
Pub/Sub para pipelines casi en tiempo real hacia SIEM/IDS.
Cloud Storage para archivado.
Ejemplo de receptor hacia BigQuery:

undefined

El registro de reglas de firewall complementa los flow logs al registrar las decisiones de permitir/denegar (allow/deny) y las reglas que coincidieron. Para observar el tráfico bloqueado, añade una regla de denegación total (deny-all) con el registro activado cerca del final de tu conjunto de reglas:

undefined

Cloud Logging permite consultas estructuradas, correlación con registros de solicitudes, registros de comprobación de estado (health-check), registros de NAT y registros de balanceadores de carga. Crear métricas basadas en registros para señales como:

Aumentos repentinos en conexiones denegadas a etiquetas de backend (posibles listas de permisos mal configuradas).
Altos volúmenes de retransmisiones SYN a un puerto (posible saturación o blackholing).
Eventos de NAT “no available ports” (agotamiento de Cloud NAT).

Cloud Monitoring agrega métricas y proporciona paneles (dashboards), alertas y SLO:

Métricas a observar: tasa de errores 5xx del balanceador de carga, latencia del backend, bytes/paquetes de la NIC de la instancia, puertos asignados/usados/en desbordamiento de Cloud NAT, estado de la sesión BGP de Cloud Router, caídas de paquetes del túnel VPN, utilización del enlace de Interconnect, pérdida de paquetes y latencia.
Paneles (Dashboards): construir paneles por servicio y por conectividad con plantillas compartidas entre proyectos para operaciones consistentes.
Alertas: favorecer las alertas de síntomas (tasa de errores, latencia, contadores de paquetes descartados) con retroalimentación rápida, y las alertas de causa (caída de BGP, enlace caído) con notificaciones (paging) cuando el impacto al usuario es probable.
SLO: definir SLO centrados en el usuario (p. ej., éxito y latencia de HTTP global) y alertas de tasa de consumo (burn-rate) para identificar consumos rápidos y lentos del presupuesto de error. Usar los registros de solicitudes como numerador/denominador a través de métricas basadas en registros para una evaluación precisa del SLO.

Compromisos y modos de fallo:

Un muestreo bajo o una agregación prolongada ocultan microrráfagas y fallos de corta duración.
Los flow logs carecen de visibilidad sobre los paquetes descartados antes del firewall; confía en el registro de reglas de firewall para obtener evidencia de denegación.
El registro excesivo sin filtrado aumenta los costos y puede ralentizar las investigaciones; exporta y particiona los datos de forma inteligente.

Network Intelligence Center y Diagnósticos Avanzados

Network Intelligence Center (NIC) proporciona diagnósticos proactivos y estructurados:

Connectivity Tests:

Valida la alcanzabilidad del plano de control a través de rutas, reglas de firewall (incluidas las políticas jerárquicas), cuentas de servicio/etiquetas, balanceadores de carga, Cloud NAT y conectividad híbrida.
Los diagnósticos de ruta calculan el siguiente salto seleccionado e informan sobre configuraciones erróneas, como rutas faltantes o rutas asimétricas.
Úsalo antes y después de cualquier cambio en la red para detectar un radio de impacto no deseado. Modela el plano de control y no garantiza la calidad del plano de datos; combínalo con evidencia de paquetes/métricas.

Performance Dashboard:

Vista gestionada por Google de la pérdida de paquetes y la latencia entre regiones y hacia puntos estratégicos de Internet. Es útil para detectar macroeventos (congestión regional o en toda la ruta) frente a problemas locales del servicio.

Network Topology:

Visualiza las conexiones entre proyectos, entre VPC e híbridas, así como los volúmenes de tráfico (aprovechando los registros) para identificar puntos calientes (hot spots), rutas de peering inesperadas y comportamientos transitivos que podrías no haber previsto.

Firewall Insights:

Detecta reglas eclipsadas (shadowed rules), reglas de permiso no utilizadas, orígenes demasiado permisivos y reglas sin etiquetas de destino/cuentas de servicio. Recomienda reglas más estrictas para reducir la superficie de ataque sin interrumpir los flujos conocidos.

Network Analyzer:

Comprobaciones de configuración estáticas y dinámicas entre proyectos para revelar condiciones como:
- Comprobaciones de estado (health checks) bloqueadas por el firewall (recuerda permitir los rangos de IP de origen de las comprobaciones de estado de Google).
- Backends de balanceadores de carga en regiones incorrectas o sin los puertos con nombre requeridos.
- Subredes con el Acceso Privado a Google deshabilitado que bloquean el acceso a las API para instancias sin IP externas.
- Rutas que causan blackholing para prefijos importantes o enrutamiento asimétrico a través de VPN/Interconnects.

Guía operativa:

Integra las comprobaciones de NIC en el CI/CD para los cambios de red y ejecútalas de forma programada. Trata los hallazgos como deuda de fiabilidad y prioriza las correcciones con impacto en la reducción de riesgos.

Replicación de paquetes, balanceadores de carga y telemetría híbrida

Replicación de paquetes (Packet Mirroring):

Replica el tráfico de las VM a un colector (dispositivo o IDS gestionado) para una inspección profunda. Delimita el alcance por subred, etiquetas de red o cuentas de servicio; restringe a los protocolos necesarios para controlar los costos.
Sobrecostos y contrapartidas: el egreso del tráfico replicado incurre en costos; una replicación excesiva puede sobrecargar los colectores; no repliques indiscriminadamente en producción. Utiliza sesiones con límites de tiempo y un alcance reducido para incidentes.
Integración con IDS:
- Cloud IDS proporciona detección de amenazas gestionada y fuera de banda (out-of-band) aprovechando Packet Mirroring. Prefiérelo para una activación rápida y una reducción del mantenimiento.
- Los dispositivos IDS de terceros siguen siendo viables cuando se requieren firmas específicas o ecosistemas de proveedores concretos.

Registros del balanceador de carga y evidencia de las comprobaciones de estado:

Los registros de solicitudes del balanceador de carga HTTP(S) incluyen el método, la URL, el backend, el código de respuesta, la latencia y las IP de los clientes a través de X-Forwarded-For. Úsalos para el análisis de la ruta del cliente, ya que traceroute se detiene en los Google Front Ends (GFEs).
Habilita el registro en los servicios de backend y configura el muestreo para equilibrar el costo frente a la visibilidad. Activa el registro de las comprobaciones de estado para ver los resultados de los sondeos y los motivos de los fallos.
Restricción del acceso de clientes: aplícala en los backends etiquetando instancias y creando reglas de firewall que solo permitan los rangos de clientes aprobados y las IP de comprobación de estado de Google. Para la mitigación de amenazas L7 y el despliegue gradual, utiliza las reglas de Cloud Armor en modo de vista previa antes de aplicarlas de forma forzosa.

Telemetría de VPN e Interconnect:

Métricas de Cloud VPN (HA VPN): bytes, caídas (drops), errores de cifrado, tiempo de actividad del túnel y estado de la sesión BGP. Alerta sobre caídas de paquetes, eventos DPD frecuentes y oscilaciones (flaps) de BGP.
Escalado del rendimiento: añade túneles a IP de pares distintas y distribuye el tráfico; supervisa el margen de capacidad (headroom). Si necesitas un modo activo/en espera entre Cloud Routers, prefiere el atributo MED on-prem para influir en la selección de la ruta.
Métricas de Interconnect: utilización por enlace, errores de CRC y disponibilidad; vigila una utilización sostenida >60–70% y picos de errores. Mantén capacidad de reserva y circuitos diversos. Investiga los aumentos de latencia junto con los indicadores de retransmisiones y de colas.
Señales de saturación en los bordes de la red: retransmisiones TCP en aumento, incremento de la latencia del percentil 99 sin cambios en el código, eventos de desbordamiento de puertos NAT y alertas de ocupación de colas son advertencias tempranas de un impacto inminente.

Metodología de resolución de problemas, gestión de incidentes y fiabilidad proactiva

Resolución de problemas estructurada desde el DNS hasta la aplicación:

Identificar el recorrido de usuario que falla y la ventana de tiempo; acotar a la región y la ruta (pública a través de un LB, privada a través de una VPC o híbrida).
DNS:

Validar la resolución con los registros de Cloud DNS, la salida de dig y el comportamiento de las políticas. Comprobar conflictos de split-horizon y asegurarse de que las políticas de reenvío estén en vigor.
Confirmar los TTL y los cambios recientes; las cachés obsoletas pueden simular interrupciones del servicio.

Balanceador de carga y borde:

Revisar los registros de solicitudes y de comprobación de estado (health-check). Correlacionar los picos de errores 5xx con el estado de los backends y los eventos de despliegue. Para L7, confiar en los registros de solicitudes en lugar de traceroute.
Verificar las listas de clientes permitidos (allowlists) y las IP de comprobación de estado de Google en las reglas de firewall cuando el acceso está restringido.

Enrutamiento y firewall:

Usar Connectivity Tests para una evaluación determinista del plano de control. Inspeccionar las rutas efectivas y las políticas de firewall jerárquicas. Buscar enrutamiento asimétrico y reglas ocultas (shadowed rules).
Para los paquetes denegados, basarse en el registro de reglas de firewall; considerar añadir una regla deny-all con registro cerca del final de la pila de prioridad durante las investigaciones.

Egreso a las API de Google:

Si las instancias no tienen IP externas, confirmar que Private Google Access y/o Cloud NAT estén configurados. La falta de cualquiera de ellos provoca fallos intermitentes y tiempos de espera confusos.

Híbrido:

Examinar las métricas de Cloud Router y VPN/Interconnect. Si BGP está activo pero las rutas no se instalan, puede reflejar preferencias de atributos; verificar MED/local-pref y los ASN. Vigilar las caídas de paquetes y los problemas de MTU de la ruta.

Evidencia de paquetes:

Si el plano de control parece correcto pero los síntomas persisten, usar Packet Mirroring de forma acotada para recolectar PCAP cerca de la VM o el nivel afectado; comprobar la temporización de SYN/SYN-ACK, las retransmisiones y los bits MSS/DF para detectar MTU blackholes.

Gestión de incidentes:

Seguridad en los cambios: implementar los cambios por fases, acotándolos a etiquetas/cuentas de servicio, con menor precedencia y como reglas deshabilitadas; habilitar el registro y probar con canaries. Usar la vista previa de Cloud Armor para los cambios de política de L7.
Reversión (rollback): predefinir los cambios inversos, mantener las configuraciones anteriores en un control de versiones y usar feature flags de corta duración en el borde de la aplicación cuando sea aplicable.
Análisis post-incidente: construir una cronología a partir de registros y métricas, clasificar los factores contribuyentes (p. ej., una regla permisiva ocultada por una de denegación, agotamiento de NAT), registrar las lagunas de detección y añadir salvaguardas: alertas, comprobaciones de NIC y endurecimiento de políticas (policy hardening).

Planificación de capacidad y fiabilidad proactiva:

Seguir los objetivos de margen de capacidad (headroom): 30–50% en los enlaces de VPN/Interconnect, uso de puertos de NAT por debajo del 60% de forma sostenida, y CPU y QPS de los backends del LB muy por debajo de los umbrales de autoescalado.
Crear métricas basadas en registros para riesgos clave: picos de denegación, desbordamiento de NAT, número de caídas de BGP (flaps), tasas de errores 5xx y errores de conexión de los backends del LB. Usar alertas de tasa de consumo (burn-rate) de múltiples ventanas para detectar tanto incidentes rápidos como lentos.
Monitorización sintética: usar Uptime Checks desde múltiples regiones para los endpoints públicos y sondas privadas desde VM de prueba para los servicios internos.
Mejoras preventivas: refinar las reglas de firewall usando Firewall Insights, resolver los hallazgos de Network Analyzer, acortar la agregación de Flow Logs durante eventos de alta carga y exportar los registros a BigQuery para la detección recurrente de anomalías.

Escenario de problema práctico

Contoso Games opera una API de juegos con balanceo de carga HTTP(S) global en us-east1 y europe-west1, con una VPN de alta disponibilidad (HA) a un centro de datos local (on-prem). Los usuarios en Europa reportan tiempos de espera intermitentes y una mayor latencia después de un cambio reciente en el firewall. Las instancias no tienen IP externas y deben alcanzar las API de Google de forma privada.

Enfoque:

Establecer la ventana de tiempo y el impacto en el SLO

Fundamento: Acotar la ventana de tiempo limita las consultas a los registros relevantes y alinea la investigación con los SLO que impactan al usuario. Una alerta de tasa de consumo (burn-rate) confirma un consumo rápido del SLO en europe-west1.

Validar el plano de control con Connectivity Tests

Fundamento: Crear una prueba desde el frontend del balanceador de carga HTTP(S) externo hasta el servicio de backend de europe-west1 y desde las VM afectadas hasta una VIP de Private Google Access. La prueba señala una política de firewall jerárquica que bloquea las comprobaciones de estado a algunos backends y la falta de Private Google Access para una subred.

Confirmar el estado del borde y de los backends a través de los registros

Fundamento: Filtrar los registros de solicitudes del balanceador de carga para europe-west1 y response_code >= 500 para aislar los errores del backend. Los registros de comprobación de estado muestran fallos en las sondas desde las IP de origen conocidas de las comprobaciones de estado de Google. Esto evidencia caídas intermitentes del backend (flapping) inducidas por el firewall en lugar de regresiones en la aplicación.

Restaurar el estado y proteger la seguridad con cambios acotados

Fundamento: Añadir una regla de permiso (allow) dirigida a las etiquetas del backend que permita los rangos de origen de las comprobaciones de estado. Habilitar el registro en esta regla. Dado que el acceso está restringido a clientes conocidos, verificar que la regla de firewall de la lista de permitidos (allowlist) incluya solo los rangos de IP de cliente específicos y los rangos de las comprobaciones de estado. Mantener la nueva regla inicialmente deshabilitada, y luego habilitarla durante una prueba canary de bajo tráfico para limitar el radio de impacto (blast radius).

Restablecer el egreso privado a las API de Google

Fundamento: Habilitar Private Google Access en la subred afectada para que las instancias sin IP externas alcancen los servicios de Google sin hacer hairpinning a través de la VPN o firewalls de terceros. Esto reduce la latencia y elimina un cuello de botella.

Comprobar la saturación híbrida y el MTU

Fundamento: Revisar las métricas de la VPN de alta disponibilidad (HA) en busca de caídas de paquetes y utilización. Un túnel muestra un número elevado de caídas. Aumentar la capacidad añadiendo un segundo túnel a una IP de par (peer) diferente en el entorno local y distribuir el tráfico. Verificar el MTU efectivo y el MSS clamp para prevenir PMTU blackholes en la ruta de la VPN.

Usar la vista previa de Cloud Armor para clientes sospechosos de abuso

Fundamento: A partir de los registros de solicitudes, un pequeño conjunto de IP de clientes provoca picos de tráfico justo antes de los fallos de las sondas. Añadir una regla de denegación (deny) en Cloud Armor en modo de vista previa para validar que el bloqueo reduciría la carga del backend antes de aplicarla, evitando un impacto accidental en los usuarios.

Usar Packet Mirroring de forma acotada para confirmar el comportamiento del plano de datos

Fundamento: Reflejar el tráfico de una única VM de backend en mal estado a Cloud IDS durante 15 minutos. El PCAP muestra un agotamiento del backlog de SYN durante las ráfagas de las IP abusivas, lo que corrobora la utilidad de la política de Cloud Armor y la necesidad de limitar la tasa (rate limiting).

Cerrar el incidente y reforzar la seguridad (harden)

Fundamento: Después de habilitar la regla de permiso para la comprobación de estado, confirmar Private Google Access, escalar la capacidad de la VPN y aplicar la regla de Cloud Armor validada, las tasas de error vuelven a la normalidad. Añadir paneles de control para la tasa de éxito de las comprobaciones de estado, el uso de puertos NAT, las caídas de la VPN y los errores 5xx por región. Crear alertas basadas en registros sobre denegaciones de firewall a las etiquetas de backend y alertas de tasa de consumo del SLO. Registrar el incidente, las causas raíz (cambio en el firewall jerárquico; tráfico abusivo; saturación de la VPN) y añadir las comprobaciones de NIC Analyzer y Firewall Insights a la lista de verificación previa al cambio.

Esta secuencia demuestra un flujo de trabajo seguro y basado en evidencias: confirmar el plano de control, observar el plano de datos, aplicar cambios mínimos y reversibles, y luego institucionalizar los aprendizajes con alertas y comprobaciones automatizadas.

← GKE · Todos los dominios · Automatización de red →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →