Google ACE: Monitoreo, registro y solución de problemas operativos — Guía de estudio

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

Forma parte de la Google Associate Cloud 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 excelencia operativa en Google Cloud depende de convertir la telemetría en acción. La supervisión, el registro y la solución de problemas proporcionan en conjunto las señales, los mecanismos de protección y los flujos de trabajo que mantienen la confiabilidad de los servicios. Esta sección cubre los servicios de observabilidad principales, las herramientas de diagnóstico, las prácticas de confiabilidad y las operaciones de incidentes con la lógica de diseño, las compensaciones y los modos de falla comunes.

Fundamentos de supervisión y alertas

Cloud Monitoring ingiere series temporales de los servicios de Google Cloud, agentes y métricas personalizadas para proporcionar dashboards, verificaciones de tiempo de actividad, SLOs y alertas.

• Métricas y cardinalidad

  • Los tipos de recursos supervisados (por ejemplo, gce_instance, aws_ec2_instance, global) definen el alcance de las dimensiones como el proyecto, la región y el ID de la instancia.
  • Minimiza los valores de etiqueta no acotados (por ejemplo, user_id) para prevenir explosiones de alta cardinalidad que ralentizan las consultas y aumentan el costo.
  • Prefiere las métricas de distribución para la latencia (p50/p90/p99) y usa ventanas de alineación para acumulaciones consistentes.

• Dashboards

  • Usa los dashboards de servicio integrados para un inicio rápido. Crea dashboards personalizados para agrupar métricas de varios proyectos. Organiza los paneles por síntoma (latencia, errores, saturación) antes que por causa (CPU, memoria).
  • Evita los gráficos por instancia para las flotas; agrega por servicio, zona o MIG para reducir el ruido y aumentar la señal.

• Políticas de alertas

  • Diseña alertas basadas en síntomas vinculadas a la experiencia del usuario: consumo del SLO de disponibilidad, percentiles de latencia, tasas de error. Usa alertas de múltiples ventanas y múltiples tasas de consumo para detectar consumos rápidos y lentos (por ejemplo, 2 % en 1 hora y 5 % en 5 minutos).
  • Establece límites de frecuencia de notificación y comportamientos de cierre automático razonables. Usa anotaciones de mitigación automática de incidentes para documentar los runbooks.
  • Usa alertas de ausencia de métricas para trabajos por lotes críticos y canalizaciones de datos con cronogramas estrictos.
  • Las métricas basadas en registros admiten alertas para eventos de aplicación o seguridad (por ejemplo, permissionDenied repetidos).

• Canales de notificación

  • Configura los canales por severidad: notificaciones de guardia para SEV1 (on-call, SMS, teléfono), chat para SEV2/3, correo electrónico o webhooks para baja prioridad. Usa Pub/Sub para la integración con sistemas de tickets o automatización.
  • Prueba los canales periódicamente; los canales obsoletos son un modo de falla silencioso.

• Verificaciones de tiempo de actividad y supervisión sintética

  • Las verificaciones de HTTP(S) y TCP desde puntos de observación globales verifican la accesibilidad externa. Combina las verificaciones con la coincidencia de contenido para detectar fallas parciales.
  • Usa verificaciones de tiempo de actividad privadas a través de conectividad híbrida o Private Service Connect para servicios internos.
  • Modos de falla: las verificaciones pueden fallar debido a la latencia del TTL de DNS, problemas de rotación de certificados TLS o interrupciones a nivel de región; corrobora con las métricas antes de enviar una notificación de guardia.

• Supervisión de múltiples proyectos

  • Usa un único espacio de trabajo de Monitoring y vincula todos los proyectos para tener dashboards y alertas consolidados. Esto simplifica los SLOs de toda la flota y reduce la duplicación.

Registro, auditoría y diagnóstico de aplicaciones

Cloud Logging es el enrutador, el almacenamiento y el plano de consulta para los registros de la plataforma y de las aplicaciones. Las herramientas de APM complementarias (Error Reporting, Trace, Profiler) aceleran el aislamiento de la causa raíz.

• Enrutamiento de registros, buckets, receptores y retención

  • Enruta con receptores a buckets de registros (predeterminados o personalizados), BigQuery (análisis), Pub/Sub (procesamiento de flujos) o Cloud Storage (archivado).
  • Usa buckets de registros con alcance regional para la residencia de datos y el rendimiento. Aplica CMEK si lo exige el cumplimiento normativo.
  • Establece la retención por bucket (por ejemplo, 30–90 días para operaciones, varios años para auditoría). Una retención más larga aumenta el costo; filtra de forma agresiva para controlar el gasto.
  • Las exclusiones reducen la ingesta de registros detallados (por ejemplo, verificaciones de estado). Valida los filtros para evitar descartar registros críticos sin querer.

  Ejemplo: crear un receptor de BigQuery para los registros de auditoría

undefined

Ejemplo: crear una exclusión

undefined

• Consultas y Explorador de registros

  • Usa filtros avanzados en resource.type, severity, etiquetas y cargas útiles JSON. Guarda las consultas para las rutas de triaje comunes (fallas de inicio, permissionDenied, quotaExceeded).
  • Crea métricas basadas en registros de tipo distribución y contador para alertas y dashboards.

• Registros de auditoría de Cloud

  • Registros de actividad del administrador: siempre activos, sin costo de ingesta; registran las operaciones de escritura administrativas (por ejemplo, createInstance).
  • Registros de acceso a los datos: registran las operaciones del plano de datos de lectura y escritura (por ejemplo, storage.objects.get). Deshabilitados por defecto para muchos servicios; habilítalos selectivamente porque el volumen y el costo pueden ser altos.
  • Registros de eventos del sistema: acciones del sistema de Google (por ejemplo, autoscaler, migración en vivo por mantenimiento).
  • Registros de políticas denegadas: registros explícitos de denegaciones de políticas de IAM y de la organización. Críticos para la solución de problemas de acceso y las revisiones de seguridad.
  • Enruta los registros de auditoría a BigQuery para su retención e investigación; indexa etiquetas como authenticationInfo.principalEmail para las atribuciones.

• Error Reporting, Trace y Profiler

  • Error Reporting agrupa automáticamente los seguimientos de pila por servicio y versión; intégralo con los canales de notificación para nuevos grupos de errores y picos repentinos.
  • Cloud Trace recopila distribuciones de latencia de solicitudes y tramos (spans); establece el muestreo para equilibrar la sobrecarga y la fidelidad (por ejemplo, 1 de cada 1000 para servicios con altas QPS, con muestreo basado en la cola si se usan colectores de OpenTelemetry).
  • Profiler proporciona un perfilado continuo de CPU/memoria (heap) de baja sobrecarga en producción. Limítalo a las rutas críticas (hot paths) o a cargas de trabajo representativas para controlar el volumen de datos y la sobrecarga. Usa el mapeo de código fuente para obtener grafos de llamadas legibles.
  • Compensaciones: un muestreo más alto mejora el diagnóstico pero aumenta el costo y la posible exposición de PII; depura los campos sensibles y usa la tokenización.

Solución de problemas de servicios, recursos y redes

La solución de problemas eficiente va de los síntomas a los límites del sistema, y luego a los recursos y dependencias.

• Estado de los servicios administrados, estado del servicio, cuotas e incidentes regionales

  • Valida si un incidente es ascendente (upstream): comprueba el estado del servicio y los avisos regionales recientes. Busca ráfagas de errores, latencia elevada o errores de cuota.
  • Las cuotas son por proyecto y, a menudo, por región; quotaExceeded y rateLimitExceeded en los registros indican una limitación (throttling). Solicita aumentos antes de los eventos de máxima carga.
  • Modo de fallo: las interrupciones regionales parciales pueden aparecer como errores intermitentes; configura la conmutación por error multirregional (failover) siempre que sea posible.

• Estado de los recursos y diagnósticos de VM

  • Utiliza las operaciones de instancia, los eventos de mantenimiento y las comprobaciones de estado (health checks). Para los MIGs, inspecciona los reinicios de autorreparación (autohealing) y los fallos en las comprobaciones de estado para aislar imágenes o configuraciones defectuosas.

  • Consola serie de la VM para mensajes de arranque y del kernel:

undefined

- Causas comunes: *kernel panics*, entradas incorrectas en `fstab` que bloquean el arranque, configuraciones de red incorrectas, mala configuración de OS Login que causa fallos de SSH.

• Asegura el uso de OS Login con claves SSH por usuario y roles de IAM (compute.osLogin o compute.osAdminLogin) para un acceso atribuible.

• Explorador de registros para el análisis de fallos

  • Comienza con los registros de síntomas (5xx, deadlineExceeded), pivota por etiquetas de recursos y luego correlaciona con los cambios en las implementaciones y los registros de cuotas. Utiliza las vistas de histograma para localizar los puntos de cambio.

• Observabilidad de la red

  • VPC Flow Logs: muestreo por VNIC del tráfico de 5 tuplas; habilítalo en las subredes. Ajusta el muestreo (por ejemplo, 0.5) y las opciones de metadatos para equilibrar rendimiento y detalle.

undefined

• Registro del firewall: captura las decisiones de permitir/denegar (allow/deny) en reglas críticas para diagnosticar bloqueos inesperados o solapamiento de reglas (shadowing).

undefined

• Connectivity Tests: modela y verifica la alcanzabilidad a través de VPCs, peering, Cloud VPN, Cloud Interconnect y reglas de firewall. Es útil para la validación previa a los cambios y la clasificación de incidentes (triage).

undefined

• Señales complementarias: registros de Cloud NAT y del balanceador de carga para problemas de salida (egress) y de borde (edge). Los modos de fallo incluyen enrutamiento asimétrico, rutas faltantes, reglas de firewall mal ordenadas y restricciones de políticas.

Confiabilidad, SLO y Operaciones de Incidentes

La disciplina operativa vincula la telemetría con los objetivos de impacto en el usuario y una ejecución de incidentes consistente.

• SLO, presupuestos de error y líneas de base

  • Definir SLO sobre SLI centrados en el usuario (disponibilidad, latencia, corrección). Ejemplo: el 99.9% de las solicitudes de lectura se completan en menos de 200 ms durante 30 días.
  • Realizar seguimiento de los presupuestos de error y diseñar paneles de control consolidados por servicio y versión de lanzamiento. Condicionar los despliegues al consumo del presupuesto.
  • Establecer líneas de base de rendimiento antes de que el tráfico aumente; las regresiones se detectan por desviación, no por valores absolutos.

• Reducción del ruido de las alertas

  • Preferir alertas a nivel de servicio en lugar de a nivel de instancia. Usar condiciones basadas en la tasa de cambio y en percentiles. Aplicar limitación de notificaciones, cierre automático de incidentes y silenciamiento de alertas para las ventanas de mantenimiento.
  • Deduplicar alertas mediante etiquetas y políticas comunes; usar enrutamiento consciente de las dependencias para evitar notificar (paging) tanto a la base de datos como a la aplicación por el mismo incidente.

• Flujo de trabajo de respuesta a incidentes

  • Clasificar y declarar la severidad; asignar roles (comandante del incidente, operaciones, comunicaciones, escriba).
  • Rutas de escalamiento: rotaciones de guardia (on-call), expertos en la materia y soporte del proveedor (incluir ID del proyecto, ID de solicitudes, marcas de tiempo y regiones en los tickets de soporte).
  • Comunicación: mantener una única fuente de verdad (canal de chat y documento del incidente). Proporcionar actualizaciones periódicas a los interesados con el impacto, la mitigación y los tiempos estimados de resolución (ETA).
  • Guías de mitigación (playbooks): reversión (rollback), conmutación por error (failover), desactivación de feature flags o adición de capacidad. Preferir cambios reversibles con un radio de impacto (blast radius) corto.

• Revisión post-incidente y RCA (Análisis de Causa Raíz)

  • Basado en evidencia: correlacionar métricas, registros (logs), trazas y eventos de cambio. Incluir qué señales de detección se activaron, por qué sí o por qué no, y el tiempo para detectar/mitigar.
  • Identificar los factores contribuyentes, no solo la causa próxima. Capturar elementos de acción concretos con responsables y fechas límite; actualizar las guías operativas (runbooks) y las alertas en consecuencia.
  • Una cultura sin culpas (blameless) fomenta la divulgación completa y las soluciones sistémicas.

• Guías operativas (runbooks)

  • Estructura: disparador y detección, árbol de diagnóstico rápido, mitigaciones seguras, pasos de reversión/restauración, verificación y criterios de salida.
  • Mantener los comandos y filtros listos para copiar y pegar; verificar el IAM de mínimo privilegio para los respondedores (por ejemplo, storage.objectCreator para copias de seguridad de solo escritura; cuentas de servicio dedicadas para la identidad de la carga de trabajo).
  • Versionar las guías operativas con gestión de cambios; probarlas durante los game days.

Escenario de Problema Práctico

Northwind Outfitters opera una plataforma regional de comercio electrónico en Google Cloud. Tras un reciente pico de tráfico, los usuarios reportan intermitentemente tiempos de espera agotados en el proceso de pago (checkout) y búsquedas de productos lentas. El equipo de operaciones necesita restaurar rápidamente la confiabilidad, reducir el ruido de las alertas y fortalecer los diagnósticos en múltiples proyectos.

Enfoque:

1. Consolidar el monitoreo entre proyectos

• Acción: Crear un único espacio de trabajo de Monitoring y vincular los proyectos de producción, pagos y búsqueda. Construir un panel de control de “Recorrido del Usuario” que muestre la disponibilidad, la latencia y las tasas de error para el pago y la búsqueda.
• Justificación: La visibilidad centralizada apoya la clasificación a nivel de servicio y correlaciona problemas entre servicios (por ejemplo, la latencia de búsqueda que causa en cascada tiempos de espera agotados en el pago).

2. Implementar SLO y alertas de tasa de consumo (burn-rate)

• Acción: Definir SLO: 99.9% de los pagos en menos de 400 ms, 99.95% de las búsquedas en menos de 250 ms. Crear alertas de consumo (burn) de múltiples ventanas (2% en 1 hora y 5% en 5 minutos) sobre los SLI de latencia y tasa de error. Notificar al personal de guardia (on-call) mediante paging y a los interesados a través del chat.
• Justificación: Las alertas de tasa de consumo (burn-rate) capturan regresiones rápidas y consumos lentos pero sostenidos sin generar notificaciones (paging) por variaciones normales.

3. Añadir verificaciones de tiempo de actividad sintéticas con coincidencia de contenido

• Acción: Configurar verificaciones de tiempo de actividad TCP y HTTPS para los puntos de entrada públicos y una verificación de tiempo de actividad privada para la API de pagos interna, validando que el cuerpo de la respuesta contenga “ok”.
• Justificación: Detecta la alcanzabilidad y fallos parciales como backends mal enrutados o servicios ascendentes (upstreams) degradados.

4. Ajustar las rutas y la retención de registros (logs)

• Acción: Crear buckets de registros dedicados: operaciones (90 días), auditoría de seguridad (2 años, CMEK). Enrutar los registros de Admin Activity, Data Access, System Event y Policy Denied a BigQuery a través de receptores (sinks) para análisis. Añadir exclusiones para las verificaciones de estado (health checks) que generan mucho ruido.
• Justificación: Una retención dimensionada correctamente controla los costos; BigQuery permite un análisis forense rápido. Las exclusiones reducen el ruido sin perder evidencia crítica.

5. Habilitar diagnósticos de aplicación

• Acción: Instrumentar los servicios con OpenTelemetry para Trace; habilitar Error Reporting para el backend y el frontend; desplegar Profiler en el servicio de pago con perfiles de CPU y heap con un muestreo conservador.
• Justificación: Las trazas identifican las rutas críticas de latencia; Error Reporting resalta nuevos grupos de errores; Profiler revela la contención de CPU y las fugas de memoria con una sobrecarga baja.

6. Fortalecer la observabilidad de la red

• Acción: Habilitar VPC Flow Logs en las subredes de producción (muestreo de 0.5, incluir todos los metadatos) y el registro del cortafuegos en las reglas de permitir/denegar para el tráfico de entrada a los servicios de búsqueda y pagos. Crear Connectivity Tests desde la capa web a la de búsqueda y desde la de pagos a Cloud SQL.
• Justificación: Los registros de flujo y del cortafuegos exponen paquetes descartados, retransmisiones y reglas ocultas (shadowed rules); los Connectivity Tests validan la alcanzabilidad e identifican configuraciones incorrectas.

7. Diagnósticos a nivel de recurso y acceso seguro

• Acción: Para VM inestables, inspeccionar problemas de arranque con la consola serie:

undefined

• Si se requiere SSH, forzar el uso de OS Login y otorgar el permiso compute.osAdminLogin al grupo “ops-admins”. Cada administrador usa su propia clave SSH.
• Justificación: Los registros de la consola serie revelan fallos del kernel y de init. OS Login con claves por usuario garantiza un acceso atribuible y de mínimo privilegio.

8. Verificación de cuotas y estado de salud regional

• Acción: Revisar eventos recientes de quotaExceeded en los registros; aumentar la cuota regional de API y de IP para el autoescalado del servicio de búsqueda. Comprobar los avisos de estado del servicio para la región afectada; desviar temporalmente el tráfico con la ponderación del balanceador de carga.
• Justificación: La limitación por cuotas y los incidentes regionales son fuentes comunes de fallos intermitentes; el escalado proactivo y el desvío de tráfico mitigan el impacto.

9. Reducción de ruido y actualización de guías operativas (runbooks)

• Acción: Reemplazar las alertas de CPU por instancia con alertas de saturación a nivel de servicio. Añadir ventanas de mantenimiento para silenciar alertas no accionables. Actualizar las guías operativas con nuevas consultas de clasificación, paneles de trazas y procedimientos de reversión.
• Justificación: Reduce la fatiga por notificaciones (paging) y acelera respuestas consistentes y seguras.

10. Revisión post-incidente y acciones

• Acción: Realizar una revisión sin culpas (blameless). Correlacionar los incidentes de tasa de consumo (burn-rate) con el aumento de la latencia de cola (tail latency) en las búsquedas y un despliegue reciente de un índice. Elementos de acción: añadir despliegues canary para la búsqueda, barreras de protección (guardrails) para el tamaño del índice y margen de maniobra (headroom) en el autoescalador; comprometerse a realizar pruebas periódicas del canal de alertas.
• Justificación: Un RCA basado en evidencia previene la recurrencia y mejora la detección, la mitigación y la resiliencia.

← Despliegue · Todos los dominios · Seguridad →

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

Explorar Google →