Operación y resiliencia en Google Cloud

Operar en Google Cloud se parece mucho a operar en AWS: métricas, logs, trazas, chequeos sintéticos y SLO. Los nombres cambian y algunos detalles también. Lo importante en multinube es otra cosa: que la observabilidad no muera con el proveedor que vigila. Esta lección recorre las piezas de Google y termina en esa pregunta.

Las piezas, frente a frente

Criterio	En Google Cloud	En AWS
Métricas y paneles	Cloud Monitoring, con un metrics scope que reúne varios proyectos	CloudWatch metrics y dashboards, con observabilidad entre cuentas
Alertas	Alerting policies con canales de notificación	CloudWatch alarms, alarmas compuestas y SNS
Logs	Cloud Logging, con log buckets	CloudWatch Logs, con log groups
Enrutar y exportar logs	Log Router y sinks, también a nivel de carpeta u organización	Subscription filters, Firehose y centralización entre cuentas
Trazas	Cloud Trace, que recibe OTLP por la Telemetry API	X-Ray y Application Signals, con OpenTelemetry
Chequeos sintéticos	Uptime checks y synthetic monitors	CloudWatch Synthetics y health checks de Route 53
SLO	SLO de Cloud Monitoring con alertas de tasa de consumo	SLO de Application Signals
Salud del proveedor	Personalized Service Health	AWS Health Dashboard

Métricas, alertas y logs

Cloud Monitoring recoge métricas de los servicios de Google sin configurar nada; para tus aplicaciones usas métricas propias o Prometheus administrado. Un metrics scope permite ver varios proyectos desde uno solo, como la observabilidad entre cuentas de CloudWatch. Una alerting policy evalúa una condición y avisa por canales de notificación: correo, SMS, webhooks, Pub/Sub o herramientas de guardia.

En Cloud Logging, cada proyecto, carpeta y organización tiene su Log Router. Los sinks deciden a dónde va cada entrada según un filtro de inclusión y filtros de exclusión:

• _Required: recibe los logs de auditoría de actividad administrativa y de eventos del sistema. No se puede cambiar ni borrar.
• _Default: recibe todo lo demás. Se puede modificar o desactivar.
• Sinks propios: hacia un log bucket, otro proyecto (un solo salto), BigQuery, Cloud Storage o un tema de Pub/Sub para herramientas externas.
• Sinks agregados: a nivel de carpeta u organización, para centralizar auditoría de todos los proyectos sin depender de cada equipo.

# Copiar los logs de auditoría de toda la organización a un proyecto de seguridad
gcloud logging sinks create auditoria-org \
  logging.googleapis.com/projects/seguridad-logs/locations/global/buckets/auditoria \
  --organization=ID_ORG --include-children \
  --log-filter='logName:"cloudaudit.googleapis.com"'

# Enviar errores de la aplicación a Pub/Sub, de donde los toma el backend neutral
gcloud logging sinks create errores-a-otel \
  pubsub.googleapis.com/projects/observabilidad/topics/logs-export \
  --project=app-prod --log-filter='severity>=ERROR'

Un sink solo enruta lo que llega después de crearlo. El Log Router guarda las entradas un rato para soportar cortes breves, pero no te protege de un filtro mal escrito: prueba cada filtro antes de confiar en él.

Trazas con OpenTelemetry en las dos nubes

Las dos nubes convergen en OpenTelemetry. En Google, Cloud Trace recibe OTLP por la Telemetry API (telemetry.googleapis.com), directamente desde un exportador en el proceso o a través de un Collector. En AWS, los SDK y el daemon de X-Ray están en mantenimiento y la recomendación es la misma. Eso te permite instrumentar una sola vez y decidir el destino en la configuración del Collector.

Para que una traza cruce de una nube a otra, propaga el contexto W3C (traceparent) en cada llamada HTTP o gRPC y usa los mismos atributos de recurso en los dos lados: service.name, entorno, versión y proveedor. Un detalle de Google: si desactivas la API de Cloud Trace, lo que envíes a la Telemetry API se descarta.

Chequeos desde afuera

Los uptime checks públicos envían peticiones HTTP, HTTPS o TCP desde varias regiones del mundo que eliges, y también pings ICMP; los privados prueban direcciones internas. Los synthetic monitors van más lejos: recorren un flujo completo (iniciar sesión, buscar, pagar) con código Node.js que corre en una función de Cloud Run, con Mocha o como verificador de enlaces rotos. Son el equivalente de los canaries de CloudWatch Synthetics. Hay un límite de 100 de cada tipo por metrics scope.

Un límite que importa en multinube: estos chequeos corren en la infraestructura de Google. Sirven para probar AWS desde Google y al revés, pero un problema amplio de un proveedor puede afectar a sus propios chequeos.

SLO y alertas de presupuesto de error

Cloud Monitoring define SLO sobre un servicio. El indicador puede ser por peticiones (porcentaje de peticiones buenas) o por ventanas (porcentaje de intervalos buenos), con periodo móvil o de calendario. El presupuesto de error es lo que el objetivo permite fallar, igual que en SLI y SLO.

1. 1

   Elige el recorrido

   Un SLI por recorrido del usuario, medido lo más cerca del usuario posible: el balanceador o un chequeo sintético, no la CPU.
2. 2

   Define el SLO

   Por ejemplo, 99,9 % de peticiones de pago con respuesta correcta en menos de 800 ms, en 28 días móviles.
3. 3

   Alerta de consumo rápido

   Usa el selector select_slo_burn_rate. Google sugiere empezar con 10 veces la tasa base y una ventana de 1 o 2 horas: despierta a alguien.
4. 4

   Alerta de consumo lento

   Empieza con 2 veces la tasa base y una ventana de 24 horas: abre un ticket. Atrapa las fugas lentas que agotarían el presupuesto antes de fin de periodo.

La fiabilidad según Google

El Google Cloud Well-Architected Framework es el equivalente del AWS Well-Architected Framework. Su pilar de fiabilidad tiene nueve principios: definir la fiabilidad desde la experiencia del usuario, fijar objetivos realistas, redundancia de recursos, escalado horizontal, observabilidad para detectar fallas, degradación controlada, probar la recuperación de fallas, probar la recuperación de pérdida de datos y hacer postmortems a fondo.

Su guía de planificación de DR clasifica los patrones con una analogía de llantas. La correspondencia con los nombres de AWS es aproximada:

Para saber si el problema es tuyo o de Google, Personalized Service Health muestra los incidentes de Google que afectan a tus proyectos, con productos y ubicaciones. Tiene API, vista de organización, registro en Cloud Logging y alertas basadas en esos logs. Es el equivalente de AWS Health. Úsalo como entrada del paso de evaluación en el runbook, no como detector: suele publicar después de que tus propias alarmas sonaron.

Observabilidad que sobrevive a un proveedor

Si tus paneles, alertas y guardia viven en la nube primaria, el día que esa nube falla te quedas a ciegas justo cuando más lo necesitas. El diseño:

• Collectors de OpenTelemetry en cada nube que exportan a un backend neutral (un tercer proveedor o uno que operas en la nube secundaria), y en paralelo a la herramienta nativa de cada nube para el detalle fino.
• Chequeos sintéticos externos, desde un servicio que no corra en AWS ni en Google, contra los recorridos críticos de las dos nubes.
• Página de estado y guardia fuera de la nube primaria, con acceso que no dependa del inicio de sesión federado de esa nube. Cuentas de emergencia probadas en las dos.
• El retraso de replicación como SLI: el latido de la base, la cola de transferencias de objetos y la edad del último respaldo copiado a la otra nube, en el mismo panel que el SLO.
• Una alerta de silencio: el backend neutral avisa si deja de recibir datos de una nube. Silencio no es salud.

Qué hacer cuando la alarma suena está en runbooks y simulacros. El diseño completo entre proveedores se arma en diseño multinube AWS + Google Cloud.