CDL
Deep Dive
Cloud Monitoring, Cloud Logging, Cloud Trace, Cloud Profiler, Error Reporting y el framework de SLI/SLO/SLA para gestionar la confiabilidad de servicios.
Google Cloud Observability (antes Cloud Operations Suite y, antes aún, Stackdriver) es la plataforma integrada de observabilidad de Google Cloud. Cubre los tres pilares de observabilidad: métricas, logs y trazas.
| Servicio | Qué hace | Cuándo usar |
|---|---|---|
| Cloud Monitoring | Recopila métricas de recursos GCP, AWS y apps propias. Crea dashboards, alertas y uptime checks. | Monitorear CPU de VMs, latencia de APIs, disponibilidad de endpoints. Alertas cuando métricas superan umbrales. |
| Cloud Logging | Centraliza logs de todos los servicios GCP y apps propias. Búsqueda, análisis y exportación de logs. | Diagnosticar errores en producción, auditoría de accesos, compliance. Exportar a BigQuery para análisis. |
| Cloud Trace | Tracing distribuido para APIs y microservicios. Muestra el tiempo de cada componente en una petición. | Identificar cuellos de botella de latencia en apps de microservicios o apps con múltiples llamadas a APIs. |
| Cloud Profiler | Análisis de rendimiento de código en producción. Identifica funciones que consumen más CPU o memoria. | Optimizar código en producción sin afectar el rendimiento. Detectar memory leaks. |
| Error Reporting | Agrupa y cuenta automáticamente los errores de las apps. Notificación en tiempo real de errores nuevos. | Detectar rápidamente nuevos tipos de errores tras un despliegue. Priorizar qué bugs afectan más usuarios. |
Métricas y alertas
• Métricas GCP: CPU, memoria, disco, red, latencia de APIs — automáticas sin configuración
• Métricas custom: tus propias métricas de negocio (pedidos/minuto, revenue, usuarios activos)
• Alerting policies: notifica por email, PagerDuty, Slack, o Pub/Sub cuando una métrica supera un umbral
• Uptime checks: verifica disponibilidad de URLs desde múltiples ubicaciones globales
Cloud Logging: retención y exportación
• Retención: 30 días por defecto para la mayoría de logs. Configurable hasta 3650 días.
• Log Router: exporta logs a BigQuery (análisis), Cloud Storage (archivo), Pub/Sub (tiempo real)
• Log-based metrics: crea métricas a partir de patrones en logs (ej: contar errores 500)
• Audit Logs: Admin Activity (quién cambió qué), Data Access (quién leyó qué), System Events
Este framework, originado en el equipo de SRE (Site Reliability Engineering) de Google, define cómo medir y gestionar la confiabilidad de servicios en producción.
SLI — Service Level Indicator
La métrica real que mides. La forma cuantificable de evaluar el rendimiento del servicio.
Ejemplo
"El 99.2% de las requests HTTP devolvieron respuesta en menos de 200ms en los últimos 30 días."
SLO — Service Level Objective
El objetivo interno de rendimiento. Acuerdo interno del equipo sobre qué nivel de SLI es aceptable.
Ejemplo
"El 99.5% de las requests deben responder en menos de 200ms." — Si el SLI está por debajo del SLO, hay un problema a resolver.
SLA — Service Level Agreement
Compromiso contractual con el cliente. Si se incumple, hay consecuencias (créditos, penalizaciones).
Ejemplo
"Google garantiza 99.9% de disponibilidad mensual para GKE. Si no se cumple, créditos de servicio."
Relación clave: SLO más estricto que el SLA
El SLO interno debe ser más estricto que el SLA comprometido con clientes. Si el SLA es 99.9%, el SLO interno debería ser 99.95%. El buffer es el "error budget" — margen para deployments, mantenimiento e incidentes sin violar el SLA.
| Concepto | Definición | En GCP |
|---|---|---|
| Alta disponibilidad (HA) | Sistema diseñado para minimizar downtime. Redundancia en múltiples zonas o regiones. | Managed Instance Groups multi-zona + Cloud Load Balancing + Cloud SQL con failover automático. |
| Tolerancia a fallos | El sistema sigue funcionando aunque fallen algunos componentes, sin intervención manual. | GKE auto-healing pods. Cloud Spanner multi-región con 99.999% SLA. |
| Recuperación ante desastres (DR) | Plan y capacidad de restaurar servicios tras un fallo mayor (región completa caída, corrupción de datos). | Backups en Cloud Storage multi-región. Cloud SQL automated backups. Snapshot de discos Persistent Disk. |
| RTO (Recovery Time Objective) | Tiempo máximo aceptable para restaurar el servicio tras un desastre. | Define cuánto puedes esperar. Multi-región activo-activo = RTO de segundos. Backup y restore = horas. |
| RPO (Recovery Point Objective) | Cuánta pérdida de datos es aceptable. "¿Hasta cuándo atrás podemos volver?" | Cloud SQL con PITR (Point-In-Time Recovery). Backups frecuentes = menor RPO. |
| Escalado (Autoscaling) | Ajustar automáticamente los recursos según la carga. Horizontal (más instancias) o vertical (más CPU/RAM). | MIG Autoscaler, GKE HPA, Cloud Run scale-to-zero, BigQuery escala automática. |
DevOps
Cultura y prácticas que unen los equipos de Desarrollo (Dev) y Operaciones (Ops) para acelerar la entrega de software con mayor calidad y confiabilidad.
SRE (Site Reliability Engineering)
Práctica creada por Google: ingenieros de software aplicando principios de ingeniería a las operaciones. El objetivo es maximizar la confiabilidad y disponibilidad de sistemas a escala.
Google Cloud ofrece diferentes planes de soporte según las necesidades del negocio. El soporte es parte de la experiencia operacional y puede ser decisivo para minimizar el impacto de incidentes.
| Plan | Qué incluye | Para quién |
|---|---|---|
| Basic | Documentación, foros de comunidad, acceso a Google Cloud Status Dashboard. | Proyectos de exploración, desarrollo, startups en fase temprana. |
| Standard | Soporte técnico ilimitado por email en horas hábiles. Respuesta para P2 en 4 horas. | Workloads de producción no críticos que admiten interrupciones cortas. |
| Enhanced | Soporte 24/7 para incidentes críticos. Respuesta para P1 en 1 hora. Technical Account Manager (TAM) disponible. | Apps de producción críticas. Negocios donde el downtime tiene impacto directo en ingresos. |
| Premium | Respuesta para P1 en 15 minutos. TAM dedicado. Revisiones de arquitectura proactivas. Event management. | Grandes empresas con cargas de misión crítica. SLAs de negocio muy estrictos. |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
El equipo de una app de e-commerce quiere ser notificado automáticamente cuando la tasa de errores HTTP 500 supera el 1% durante 5 minutos. ¿Qué servicio de Google Cloud deben usar?
Pon a prueba lo que aprendiste con preguntas originales del examen CDL.
Iniciar simulacro CDLSin límite de simulacros con plan Pro
Inicia sesión para llevar tu progreso.