Todo ingeniero que opera infraestructura en la nube termina enfrentando la misma pregunta: ¿mi sistema realmente está funcionando bien ahora mismo? Responder esa pregunta exige un sistema para recolectar y analizar tres tipos de señales — métricas, logs y trazas — que en conjunto forman lo que la industria llama un stack de observabilidad. En Google Cloud, Cloud Monitoring y Cloud Logging ocupan el centro de ese stack.
---
Qué significa operar la nube sin observabilidad
En un entorno donde decenas de VMs y servicios gestionados están estrechamente acoplados, ir físicamente a revisar un servidor simplemente no es una opción. Cuando algo falla, no saber dónde ocurrió, cuándo empezó o por qué sucedió se denomina operación de caja negra. La observabilidad es la capacidad de inferir qué ocurre dentro de un sistema a partir de señales observables desde el exterior.
Los tres pilares de la observabilidad se mapean directamente a herramientas de GCP:
| Señal | Qué te dice | Herramienta GCP | |-------|-------------|------------------| | Métricas | Estado numérico del sistema — CPU al 80%, latencia de solicitud 200ms | Cloud Monitoring | | Logs | Qué ocurrió en un momento específico — mensajes de error, eventos de auditoría | Cloud Logging | | Trazas | Cómo fluyó una solicitud entre servicios — identificar cuellos de botella | Cloud Trace |
Las métricas responden "¿cuál es el estado actual?", los logs responden "¿qué ocurrió?" y las trazas responden "¿por qué es lento?". Los escenarios de examen frecuentemente requieren distinguir qué tipo de señal — y qué herramienta — corresponde a cada situación. Tener estos tres conceptos bien definidos desde el principio facilita todos los escenarios de operaciones que encontrarás.
---
Componentes principales de Cloud Monitoring
Cloud Monitoring fue anteriormente conocido como Stackdriver Monitoring. Ingesta miles de métricas automáticamente desde los recursos de GCP, las almacena en una base de datos de series de tiempo, y proporciona dashboards y Alerting Policy para que los equipos de operaciones evalúen el estado del sistema de un vistazo.
Arquitectura de recolección de métricas
Para VMs en Compute Engine, instalar el Ops Agent habilita la recolección de métricas a nivel de sistema — CPU, memoria, disco, red — junto con los logs de aplicaciones del mismo host. Los servicios gestionados como Cloud SQL, GKE y Cloud Run emiten métricas automáticamente sin necesidad de agente. Las métricas personalizadas de aplicaciones pueden enviarse mediante el SDK de OpenTelemetry o Prometheus. En entornos GKE, Managed Service for Prometheus ingesta métricas de Prometheus de forma nativa sin requerir cambios en la instrumentación existente.
Dashboards y Alerting Policy
Las dos funciones principales de Cloud Monitoring son los dashboards para visualización de métricas y el Alerting Policy para notificaciones automáticas. Una Alerting Policy tiene tres componentes: una condición que define qué métrica y umbral activa la alerta, un canal de notificación que especifica quién recibe la notificación y cómo, y documentación que proporciona orientación de runbook junto con la notificación de alerta.
| Componente | Función | Ejemplo | |------------|---------|--------| | Condición | Qué métrica, qué umbral, por cuánto tiempo | disk/read_latencies > 100ms durante 5 min | | Canal de notificación | Quién recibe la alerta y cómo | Email, Slack, PagerDuty, Webhook, Pub/Sub | | Duración | Ignorar picos transitorios, activar solo en violaciones sostenidas | 1 min, 5 min, 10 min | | Documentación | Runbook o mensaje de orientación adjunto a la alerta | "Si esto se activa, revisa X primero" |
La ventana de duración es fundamental para reducir la fatiga de alertas. Sin ella, un pico de CPU que se resuelve en segundos igual genera una notificación. Configurar una duración de cinco minutos filtra el ruido transitorio y asegura que solo los problemas genuinos y sostenidos generen notificaciones. Este único detalle de configuración es la diferencia entre un equipo de guardia que confía en sus alertas y uno que las ignora.
---
Cómo funcionan Cloud Logging y el Log Router
Cloud Logging es el servicio centralizado de gestión de logs de GCP. Dos categorías de logs de auditoría son especialmente importantes para el examen. Los logs de auditoría de Admin Activity registran la creación, eliminación y modificación de recursos — incluidos cambios en IAM y alteraciones de esquemas — automáticamente y no pueden deshabilitarse. Los logs de auditoría de Data Access registran operaciones del plano de datos como consultas de BigQuery y lecturas de Cloud Storage. Están deshabilitados por defecto y deben habilitarse explícitamente por servicio.
Log Router y Sinks
El núcleo arquitectónico de Cloud Logging es el Log Router y sus sinks. El Log Router inspecciona cada entrada de log a medida que llega y la evalúa contra todos los filtros de sink configurados. Las entradas que coinciden con un filtro se exportan al destino del sink. El flujo es: fuente de log → ingesta en Cloud Logging → Log Router → coincidencia con filtro de sink → destino.
Elegir el destino de sink correcto es el concepto de Log Router que se evalúa con mayor frecuencia. La siguiente tabla relaciona palabras clave de escenario con la respuesta correcta:
| Destino del Sink | Caso de uso | Palabras clave | |-----------------|-------------|----------------| | Cloud Storage | Retención a largo plazo, archivado para cumplimiento, preservación de logs de auditoría | "largo plazo", "archivo", "cumplimiento" | | BigQuery | Análisis basado en logs, consultas SQL, integración con dashboards de BI | "analizar", "consulta SQL", "BigQuery" | | Pub/Sub | Procesamiento en tiempo real, integración con sistemas externos, pipelines de streaming | "tiempo real", "sistema externo", "streaming" | | Splunk | Integración con herramientas SIEM existentes | "Splunk", "SIEM" | | Otro Cloud Logging | Centralizar logs entre organizaciones, enrutar logs de auditoría a un proyecto de seguridad | "centralizar", "otro proyecto" |
---
Métricas basadas en logs y alertas basadas en SLO
Log-based Metrics
Una de las funciones más potentes de Cloud Logging es la capacidad de derivar métricas directamente de los datos de log. Una métrica contador que cuenta entradas de log que contienen la cadena "ERROR" se convierte en una serie de tiempo sobre la cual Cloud Monitoring puede alertar, igual que cualquier métrica de infraestructura. Hay dos tipos de métricas disponibles: métricas contador (recuento de entradas de log que coinciden con un filtro) y métricas de distribución (distribución estadística de un valor numérico extraído de las entradas de log). Cuando un escenario de examen describe alertar cuando un patrón de log específico supera un umbral, la respuesta son las Log-based Metrics combinadas con una Alerting Policy.
Alertas basadas en SLO
Un Service Level Objective define un objetivo de confiabilidad para un servicio. Cloud Monitoring puede definir SLOs directamente y alertar basándose en la tasa de consumo del error budget en lugar de umbrales brutos de métricas. Para un SLO de disponibilidad mensual del 99.9%, una alerta se activa inmediatamente cuando el 10% del error budget se consume en una hora, y se envía por un canal más lento cuando el 1% se consume en 24 horas. Este es el enfoque idiomático de SRE para las alertas — expone el impacto real sobre el usuario en lugar del ruido transitorio de infraestructura.
| Enfoque de alerta | Características | Mejor usado para | |-------------------|-----------------|------------------| | Basado en umbral | Se activa cuando una métrica supera un valor numérico | Métricas de infraestructura que requieren respuesta inmediata | | Alerta de Log-based Metric | Se activa cuando la frecuencia de un patrón de log supera un umbral | Picos de logs de error, detección de eventos de seguridad | | Alerta basada en SLO | Se activa según la tasa de consumo del error budget | Servicios gestionados con SLO, minimización de fatiga de alertas |
---
Medición de disponibilidad con Uptime Check
Uptime Check es el mecanismo de Cloud Monitoring para sondear la disponibilidad del servicio desde el exterior. Cloud Monitoring envía solicitudes HTTP, HTTPS o TCP desde múltiples regiones globales a una URL o IP especificada, luego inspecciona el código de respuesta, el cuerpo de la respuesta y el tiempo de respuesta.
| Componente | Descripción | |------------|-------------| | Objetivo | URL, dirección IP o endpoint de recurso GCP (ej. https://example.com/health) | | Protocolo | HTTP, HTTPS, TCP | | Intervalo de verificación | 1 a 15 minutos (se recomienda 1 minuto) | | Verificador de contenido | El cuerpo de la respuesta debe contener una cadena específica (ej. "OK", "healthy") para considerarse exitosa | | Ubicaciones de verificación | Múltiples regiones simultáneamente — us-east1, europe-west1, asia-east1 y más |
Cuando un Uptime Check falla, se integra con la Alerting Policy para enviar notificaciones inmediatas. Esta es la forma más rápida de detectar que los usuarios reales no pueden acceder a un servicio. Una restricción importante: las VMs con IPs exclusivamente internas no pueden verificarse por defecto. Uptime Check aplica solo a endpoints accesibles externamente.
---
Cloud Trace, Error Reporting y Cloud Profiler — Resúmenes en una línea
Más allá de Cloud Monitoring y Cloud Logging, el stack de observabilidad de GCP incluye tres herramientas adicionales. Comprender el rol distintivo de cada una previene confusión en preguntas de examen basadas en escenarios.
| Servicio | Función | Cuándo usarlo | |---------|---------|---------------| | Cloud Trace | Trazado distribuido — sigue una solicitud mientras se mueve entre servicios | Latencia alta de API, identificar el servicio cuello de botella | | Error Reporting | Agrega y agrupa errores automáticamente, alerta sobre nuevos tipos de error | Detect