Google PCD: Observabilidad, depuración y operaciones de fiabilidad del sitio — Guía de estudio

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

Forma parte de la Google Professional Cloud Developer — 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, la depuración y las operaciones de fiabilidad de sitios en Google Cloud se centran en hacer que los sistemas sean medibles, diagnosticables y resilientes. Una observabilidad sólida requiere un registro de logs y métricas consistente, trazado distribuido, alertas procesables y una respuesta a incidentes disciplinada. La fiabilidad exige claridad sobre los indicadores y objetivos de nivel de servicio, una señalización rigurosa del estado del sistema y un ciclo de retroalimentación que convierte los conocimientos de producción en mejoras de ingeniería. Esta sección describe cómo construir estas capacidades de extremo a extremo en Google Cloud y cómo razonar sobre las contrapartidas y los modos de fallo comunes.

Fundamentos de Logging y Monitorización

Cloud Logging

• Emitir logs estructurados. Prefiera JSON con nombres de campo estables para que las consultas y las métricas basadas en logs se mantengan robustas entre versiones. Incluya la severidad, el nombre del servicio, la versión, la ubicación y un ID de solicitud o contexto de traza para la correlación.
• Correlacione los logs con las trazas estableciendo los campos:
  • logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
  • logging.googleapis.com/spanId: SPAN_ID
  • logging.googleapis.com/trace_sampled: true
• Buckets y retención. El bucket _Default suele tener una retención de 30 días (configurable). El bucket _Required contiene ciertos logs de auditoría con una retención más larga y fija. Cree buckets regionales para controlar la residencia de los datos y establezca una retención personalizada por bucket.
• Receptores. Enrute los logs a BigQuery para análisis, a Pub/Sub para consumidores de streaming o a Storage para archivado. Use receptores agregados a nivel de carpeta u organización para capturar los proyectos hijos.
• Consultas. Use el lenguaje de consulta de Logging para filtrar por resource.type, labels, jsonPayload, httpRequest o textPayload.

Ejemplos:

• Entrada de log estructurado (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” }
• Actualizar la retención: gcloud logging buckets update _Default –location=global –retention-days=180
• Crear un receptor de BigQuery para logs de errores: gcloud logging sinks create bq-errors
  bigquery.googleapis.com/projects/myproj/datasets/log_analytics
  –log-filter=‘severity>=ERROR’
• Leer los 5xx recientes para Cloud Run: gcloud logging read ‘resource.type=“cloud_run_revision” AND httpRequest.status>=500’ –limit=20

Cloud Monitoring

• Métricas. Use métricas de Google Cloud, métricas personalizadas y métricas basadas en logs. Favorezca las etiquetas de baja cardinalidad; una cardinalidad de etiquetas descontrolada causa problemas de costo y latencia en las consultas.
• Paneles. Organice paneles por servicio y por dependencia (base de datos, caché, colas). Visualice las señales RED (peticiones, errores, duración) y USE (utilización, saturación, errores).
• Políticas de alertas. Active alertas por umbrales, ausencia de métricas, ratios, tasas de consumo de SLO (burn rates) o fallos en las verificaciones de tiempo de actividad. Configure canales de notificación (correo electrónico, SMS, PagerDuty, Pub/Sub, webhooks). Suprima las alertas intermitentes (flapping) mediante ventanas de tiempo y alineadores.
• Verificaciones de tiempo de actividad. Sondee desde múltiples regiones; use verificaciones de tiempo de actividad privadas para endpoints internos o ejecute pruebas sintéticas desde dentro de la VPC.

Métricas basadas en logs

• Los contadores resumen ocurrencias (por ejemplo, el recuento de solicitudes a /api/alpha/*).
• Las distribuciones capturan la latencia o los tamaños de las cargas útiles (payloads).
• Ejemplo: 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álisis operacional

• Para análisis ad hoc, enrute a BigQuery a través de un receptor; diseñe esquemas y particiones por marca de tiempo para controlar el costo.
• Use Log Analytics en los buckets de Logging para agregar datos sin necesidad de exportarlos, cuando sea aplicable.
• Construya señales de capacidad a partir de métricas como CPU, memoria, profundidad de la cola, conexiones de Cloud SQL, CPU de alta prioridad de Spanner, mensajes no confirmados (unacked) de Pub/Sub y tasas de errores 429/5xx de Cloud Storage.

Errores comunes y contrapartidas

• El exceso de logs aumenta el costo de ingesta y oculta la señal; prefiera el muestreo y la disciplina en la severidad.
• La falta de IDs de correlación dificulta la clasificación de incidentes; propague los IDs de traza de extremo a extremo.
• Una retención prolongada en buckets de acceso frecuente (hot) aumenta el costo; exporte a un archivo o a BigQuery para necesidades a largo plazo.

Trazado, errores y diagnóstico profundo

Trazado distribuido

• Contexto de traza. Prefiere el W3C trace-context (traceparent, tracestate). Para la interoperabilidad con Cloud Trace, continúa soportando x-cloud-trace-context: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
• Propagación. Reenvía las cabeceras de traza a través de servicios, colas de mensajes y límites asíncronos; captura nuevos spans hijos al realizar llamadas RPC o SQL. La pérdida de contexto rompe los mapas de servicio e infla los nodos de “servicio desconocido”.
• Muestreo. Equilibra el costo y la fidelidad; el muestreo dinámico basado en cabecera (head-based) en la entrada (ingress) y el muestreo basado en cola (tail-based) para solicitudes lentas y poco comunes puede mejorar la utilidad.

Cloud Trace

• Proporciona histogramas de latencia, cascadas de spans y mapas de servicio. Usa anotaciones para suboperaciones críticas (RPC, consultas a BD).
• Diagnostica valores atípicos (outliers) usando trazas p95/p99; vigila el fan-out, las consultas N+1 o la contención de bloqueos (lock contention).
• Habilita la correlación traza-log para que al hacer clic en una traza se muestren sus logs.

Error Reporting

• Agrega automáticamente excepciones por firma de pila (stack) por servicio/versión. Configura el contexto del servicio para evitar la mezcla entre servicios. Suprime errores conocidos y ruidosos o canalízalos a notificaciones de menor prioridad.
• Redacta la PII (Información de Identificación Personal) de los mensajes de excepción; en su lugar, registra códigos de error estables e ID de correlación.

Cloud Profiler

• Perfilado continuo de CPU/heap de bajo impacto (overhead) para entornos de ejecución compatibles. Compara perfiles entre versiones y niveles de tráfico para detectar regresiones. Evita interpretar los artefactos del muestreo como recuentos exactos.

Cloud Debugger

• Las instantáneas (snapshots) capturan variables en una ubicación del código sin pausar el proceso. Los puntos de registro (logpoints) inyectan sentencias de logging temporales. Restringe el acceso, redacta variables sensibles y limita el alcance a expresiones sin PII.

Ejemplo corto: añadir un W3C traceparent y correlacionar un log

• Propagación HTTP: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
• Campo de log para enlazar con Cloud Trace: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

Ingeniería de fiabilidad, alertas y señales de estado

SLI, SLO, SLA y presupuestos de error

• Los SLI (Indicadores de Nivel de Servicio) miden la satisfacción del usuario: disponibilidad, latencia, corrección. Defínelos por cada endpoint crítico y recorrido de usuario (user journey).
• Los SLO (Objetivos de Nivel de Servicio) establecen metas, p. ej., 99.9% de las solicitudes por debajo de 300 ms en un período de 30 días.
• Los presupuestos de error cuantifican la falta de fiabilidad permitida. Gasta los presupuestos en lanzamientos, experimentos o migraciones; congela los cambios si la tasa de consumo (burn rate) es demasiado alta.
• Los SLA (Acuerdos de Nivel de Servicio) son compromisos externos; mantén el SLO más estricto que el SLA para proteger el margen.

Diseño de alertas de calidad

• Prefiere alertas basadas en SLO y en síntomas en lugar de en causas, siempre que sea posible.
• Usa alertas de múltiples ventanas y múltiples tasas de consumo (multi-burn-rate) (por ejemplo, 14x en 5 minutos y 2x en 1 hora) para capturar consumos rápidos y lentos mientras se reduce el ruido.
• Añade ausencia de métrica para los watchdogs (p. ej., el latido de un trabajo de larga duración).
• Enruta por severidad; limita la tasa de notificaciones; proporciona enlaces a runbooks y dashboards.

Comprobaciones de estado y sondas (probes)

• Las comprobaciones de preparación (readiness checks) bloquean el tráfico hasta que las dependencias estén listas; las comprobaciones de actividad (liveness checks) provocan reinicios en procesos bloqueados; las sondas de inicio (startup probes) protegen a los servicios de arranque lento de reinicios prematuros.
• Para VM con balanceo de carga, permite los rangos de origen del comprobador de estado o el tráfico nunca llegará a los 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
• Ejemplo de Kubernetes: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
• Pruebas sintéticas. Usa comprobaciones de tiempo de actividad (uptime checks) y flujos de extremo a extremo personalizados a través de Cloud Scheduler + Cloud Run/Functions para validar el inicio de sesión, los pagos u otras rutas críticas.
• Monitorización de dependencias. Rastrea la saturación de conexiones de la base de datos, las tasas de error de RPC, los retrasos en las colas (backlogs), los errores de salida (egress) y los SLI de terceros. Configura reintentos con truncated exponential backoff para errores transitorios 429/5xx, con claves de idempotencia por seguridad.

Respuesta a incidentes, depuración consciente de la seguridad y causa raíz

Ciclo de vida de la respuesta a incidentes

• Triaje: clasificar la gravedad, asignar un comandante del incidente y avisar al personal de guardia a través de canales definidos.
• Contención: aplicar mitigaciones conocidas y controles de tráfico (reversión, canary, circuit breaker, limitadores de tasa).
• Comunicación: mantener una sala de crisis (war-room) interna, actualizar a las partes interesadas regularmente y publicar el estado de cara al usuario cuando sea necesario.
• Resolución y recuperación: verificar el estado a través de los SLI; evitar dar el visto bueno prematuramente.
• Postmortem: analizar sin culpas la cronología, las brechas de detección, los factores contribuyentes y los elementos de acción con responsables y fechas de entrega. Realizar seguimiento hasta el cierre.

Runbooks

• Incluir disparadores, contexto requerido, comandos de diagnóstico, mitigaciones seguras, pasos de reversión y rutas de escalamiento. Enlazar a dashboards, logs y playbooks para modos de fallo específicos.

Monitorización de cuotas y capacidad

• Monitorizar las cuotas de servicio a través de las métricas de Cloud Monitoring. Automatizar alertas al 70–80 % de utilización y solicitar aumentos por adelantado para pruebas de carga o lanzamientos planificados.
• Señales de capacidad a seguir: CPU, memoria, descriptores de archivo, pools de hilos, conexiones a la BD, límites del autoescalador y profundidad de la cola de solicitudes.

Depuración sin exponer información sensible

• Redactar secretos e IIP (Información de Identificación Personal) en el origen; centralizar los secretos en Secret Manager. Usar hashing o tokenización para los identificadores de usuario. Habilitar la redacción a nivel de campo en el middleware de logging.
• Limitar el acceso a logs, trazas y herramientas de depuración a través de IAM; usar CMEK y VPC Service Controls donde sea aplicable.
• En Debugger, deshabilitar la recolección de grafos de objetos grandes y añadir condiciones para evitar la captura de marcos (frames) sensibles.

Análisis de causa raíz a través de las capas

• Tiempo de ejecución (Runtime): correlacionar picos en GC, pools de hilos o CPU a través de Profiler con la latencia p99 en Trace.
• Red: inspeccionar los logs del balanceador de carga, VPC Flow Logs, logs del firewall y Connectivity Tests para validar las rutas. Los fallos en las comprobaciones de estado (health-checks) suelen deberse a reglas de firewall faltantes o puertos incorrectos.
• IAM: revisar Cloud Audit Logs en busca de denegaciones de permisos o cambios en las políticas; confirmar los roles de las cuentas de servicio y los ámbitos (scopes) de los tokens.
• Datos: usar Cloud SQL Insights, estadísticas de consulta de Spanner, CPU y tablets calientes de Bigtable, y tasas de error de Storage para encontrar puntos calientes (hotspots). Aplicar reintentos con backoff para fallos transitorios y reducir el fan-out que amplifica la latencia de cola (tail latency).
• Unificar todo con ID de traza correlacionados y métricas basadas en logs; exportar a BigQuery para ejecutar uniones (joins) de múltiples fuentes durante el análisis posterior al incidente.

Escenario de problema práctico

Fjord Retail migra un proceso de pago multiservicio a Google Cloud usando Cloud Run, Cloud SQL, Pub/Sub y una API de impuestos externa. Los usuarios reportan tiempos de espera intermitentes y tasas de error con picos durante las ventas flash, y el personal de guardia recibe alertas ruidosas y de baja señal.

Enfoque:

1. Instrumentar logging estructurado con correlación de trazas

• Añadir la propagación de traceparent de W3C entre servicios e incluir logging.googleapis.com/trace en todos los logs. Justificación: la correlación de extremo a extremo permite a los ingenieros pivotar desde una solicitud de usuario lenta hasta la RPC o consulta lenta exacta y sus logs.

2. Crear buckets, retención y exportaciones de Logging

• Aumentar la retención de _Default a 90 días y crear un bucket regional para cargas de trabajo de la UE. Añadir un receptor (sink) agregado a BigQuery para los logs de ERROR y WARNING:

undefined

Justificación: una retención en caliente (hot) suficiente ayuda a la depuración; BigQuery permite un análisis rápido de incidentes sin inflar los costos de almacenamiento en caliente. 3) Definir SLI/SLO y alertas basadas en SLO

• SLI de disponibilidad: solicitudes exitosas / total. SLI de latencia: duración p95 para POST /checkout.
• SLO: 99.9 % de disponibilidad mensual; 95 % de los pagos < 300 ms.
• Configurar alertas de tasa de consumo (burn-rate) de múltiples ventanas y una alerta de ausencia de métrica para el latido (heartbeat) del proceso de pago. Justificación: las alertas basadas en síntomas reducen el ruido y solo avisan cuando hay un impacto en el usuario.

4. Establecer sondas de estado y comprobaciones sintéticas

• Los servicios de Cloud Run exponen /ready y /healthz. Añadir una comprobación de tiempo de actividad (uptime check) global para /checkout y un trabajo sintético privado en la VPC que realice un proceso de pago completo con credenciales de prueba. Justificación: la preparación (readiness) evita que los backends fríos reciban tráfico; las comprobaciones sintéticas detectan problemas de extremo a extremo y regresiones de terceros.

5. Habilitar Cloud Trace y Profiler, y adoptar reintentos con backoff

• Instalar agentes de Trace/Profiler donde sea aplicable; habilitar la instrumentación automática del cliente HTTP y la anotación de spans de SQL. Implementar un backoff exponencial truncado con claves de idempotencia para las llamadas a la API de impuestos. Justificación: el trazado (tracing) aísla los contribuyentes a la latencia; el backoff reduce la amplificación de errores 429/5xx y protege los presupuestos de error.

6. Monitorizar la capacidad y las cuotas

• Añadir dashboards y alertas para las conexiones de Cloud SQL, CPU, el buffer pool de InnoDB, los mensajes no confirmados (unacked) de Pub/Sub, la concurrencia de Cloud Run y el uso de las cuotas de servicio. Justificación: la saturación de la capacidad es una causa oculta común de la latencia de cola; las alertas tempranas previenen interrupciones del servicio.

7. Reforzar la depuración para la privacidad

• Usar ID de usuario con hash y excluir la IIP de los mensajes de error. Restringir Debugger a producción solo con reglas de redacción y logpoints. Justificación: mantener la observabilidad mientras se cumple con la minimización de datos.

8. Construir monitores de dependencias y circuit breakers

• Seguir la tasa de éxito y la latencia de la API de impuestos externa a través de métricas personalizadas; activar un circuit breaker para usar tasas de impuestos cacheadas cuando los fallos superen un umbral. Justificación: aislar los fallos en dependencias de terceros y mantener la disponibilidad del proceso de pago principal.

9. Preparar runbooks y rutas de escalamiento

• Documentar los pasos: verificar los dashboards de SLO, revisar el mapa de servicios de Trace en busca de bordes calientes (hot edges), inspeccionar Cloud SQL Insights en busca de consultas lentas, verificar el firewall y las comprobaciones de estado, y evaluar el margen de cuota (headroom). Incluir procedimientos de reversión y canary. Justificación: una respuesta consistente y rápida reduce el MTTR y evita cambios arriesgados ad-hoc.

10. Pipeline de análisis post-incidente

• Usar las exportaciones de BigQuery para calcular las tasas de error por tenant y para correlacionar los logs con las trazas y los insights de Cloud SQL por ID de traza. Justificación: un historial duradero y consultable permite realizar análisis de causa raíz (RCA) precisos y tomar medidas de prevención.

Este plan eleva la calidad de la señal, acorta el tiempo de detección y resolución, protege la experiencia del usuario durante los picos de tráfico y garantiza la privacidad durante la depuración en producción.

← Entrega continua · Todos los dominios · Rendimiento →

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

Explorar Google →