La crisis del monitoring de microservicios#

El monitoring de uptime tradicional pregunta: "¿Tu web está respondiendo?"

La arquitectura moderna de microservicios pregunta: "¿Están respondiendo los 47 microservicios y se están comunicando correctamente entre sí?"

Una plataforma de microservicios consta de decenas de servicios interconectados:

API Gateway → Auth Service → User Service → Database
             → Payment Service → Stripe
             → Notification Service → SendGrid
             → Reporting Service → Data Warehouse
             → Search Service → Elasticsearch
             → Cache → Redis

Si CUALQUIERA de estos servicios falla:

Auth Service caído = nadie puede iniciar sesión
Payment Service caído = los clientes no pueden pagar
Search Service caído = los clientes no pueden encontrar productos
Caché Redis caída = el sistema se vuelve lento (fallo en cascada)

El monitoring de uptime tradicional pasa por alto toda esta complejidad.

Por qué el monitoring de microservicios es diferente#

1. Fallos distribuidos

En sistemas monolíticos, el fallo es binario: arriba o abajo.

En microservicios, los fallos son parciales y en cascada:

Escenario 1: Search Service lento
  - Las peticiones de búsqueda tardan 10 segundos (normalmente 200ms)
  - El frontend agota el tiempo esperando los resultados de búsqueda
  - La latencia de la API se dispara 10x
  - Los usuarios ven "página cargando lentamente"
  - No lo detectan los chequeos de uptime simples (la API técnicamente responde)

Escenario 2: Cache Service degradado
  - La tasa de aciertos de caché Redis baja del 90 % al 20 %
  - La base de datos recibe 4x más consultas
  - La CPU de la base de datos se dispara al 100 %
  - Todas las peticiones se ralentizan (incluso las no relacionadas)
  - Fallo en cascada en todo el sistema

Escenario 3: Fallo de comunicación entre servicios
  - Auth Service está arriba
  - User Service está arriba
  - Pero un problema de red impide la comunicación Auth → User
  - Los usuarios no pueden iniciar sesión
  - Ambos servicios aparecen como "up" en el monitoring

2. Fallos específicos de Kubernetes

Kubernetes añade complejidad:

Ciclo de reinicio de Pod:
  - El Pod se cae por una fuga de memoria
  - Kubernetes reinicia el Pod automáticamente
  - El Pod se está reiniciando, no responde al tráfico
  - Aparece "up" (el Pod existe) pero no atiende peticiones

Fallo de nodo:
  - Un nodo de Kubernetes se cae
  - El Scheduler mueve los Pods a otros nodos
  - Los Pods están bien pero temporalmente no disponibles durante la migración
  - Fallos breves de peticiones durante la transición

Problema de Deployment:
  - Un nuevo Deployment tiene un bug de arranque
  - Los Pods no consiguen iniciarse
  - Los Pods existentes siguen atendiendo peticiones
  - El sistema está degradado pero no totalmente caído

3. Complejidad del Service Mesh

Con service mesh (Istio, Linkerd):

El Service Mesh añade otra capa:
  - Service → Sidecar → Red → Sidecar → Service
  - El Sidecar puede inyectar fallos (rate limiting, timeouts)
  - Los circuit breakers pueden saltar (impidiendo peticiones)
  - El balanceo de carga puede ser desigual (algunas instancias reciben más tráfico)

El monitoring debe incluir:
  - Salud del Sidecar
  - Estado del circuit breaker
  - Distribución del balanceo de carga
  - Salud del control plane del service mesh

Arquitectura de monitoring de microservicios#

Nivel 1: Disponibilidad del servicio#

Monitoriza cada servicio individualmente:

Auth Service:
  - ¿El servicio está corriendo? (pod count > 0)
  - ¿Responde a los health checks? (GET /health devuelve 200)
  - ¿Cuál es el tiempo de respuesta? (P95 &lt; 100ms)
  - ¿Cuál es la tasa de errores? (&lt; 0,1 %)

Payment Service:
  - ¿El servicio está corriendo?
  - ¿Está respondiendo? (GET /health)
  - ¿Puede comunicarse con Stripe? (Stripe responde)
  - ¿Cuál es la latencia? (P95 &lt; 500ms)

Nivel 2: Comunicación entre servicios#

Monitoriza la comunicación servicio a servicio:

Auth Service → User Service:
  - ¿Auth Service puede llegar a User Service? (conectividad de red)
  - ¿Cuál es la latencia? (P95 &lt; 50ms)
  - ¿Cuál es la tasa de errores? (&lt; 0,01 %)

User Service → Database:
  - ¿User Service puede llegar a la base de datos? (salud del connection pool)
  - ¿Está agotado el connection pool? (esperando conexiones)
  - ¿Cuál es la latencia de las consultas? (P95 &lt; 100ms)

Nivel 3: Trazado distribuido de transacciones#

Monitoriza flujos de petición completos:

Flujo de inicio de sesión de usuario:
  1. El API Gateway recibe la petición de login
  2. Enruta a Auth Service (latencia: 10ms)
  3. Auth Service consulta a User Service (latencia: 15ms)
  4. User Service consulta a la base de datos (latencia: 20ms)
  5. Auth Service firma el token JWT (latencia: 5ms)
  6. El API Gateway devuelve la respuesta (latencia: 2ms)

Latencia total: 52ms (aceptable)

Si la consulta a User Service tarda 500ms en lugar de 20ms:
  - La latencia total salta a 532ms
  - El usuario ve un login lento
  - El rendimiento de la aplicación se degrada
  - El monitoring detecta la causa raíz (consulta lenta a User Service)

Nivel 4: Monitoring específico de Kubernetes#

Monitoriza la infraestructura de Kubernetes:

Salud de los Pods:
  - Número de reinicios del Pod (alerta si > 5 en 24h)
  - Uso de memoria del Pod (alerta si se acerca a los límites)
  - Uso de CPU del Pod (alerta si se mantiene > 80 %)

Salud de los nodos:
  - Estado del nodo (Ready, NotReady, Unknown)
  - Presión de disco del nodo (alerta si > 85 % lleno)
  - Presión de memoria del nodo (alerta si &lt; 10 % disponible)

Salud del Deployment:
  - Réplicas deseadas vs. réplicas listas (alerta si no coinciden)
  - Latencia de creación de Pods (alerta si > 30 segundos)
  - Errores de pull de imagen (alerta si los Pods no consiguen arrancar)

Fallo real de monitoring de microservicios#

Organización: plataforma FinTech con más de 30 microservicios y 50 Pods de Kubernetes

Arquitectura:

API Gateway (5 réplicas)
Auth Service (3 réplicas)
Payment Service (5 réplicas)
Notification Service (3 réplicas)
Data Pipeline (2 réplicas)
Caché (cluster Redis)
Base de datos (PostgreSQL)

El incidente: procesamiento de pagos lento

Cronología:

14:00: Los Pods de Notification Service se reinician (fuga de memoria)
14:05: Creación lenta de Pods de Notification Service (Kubernetes scheduler sobrecargado)
14:10: Las peticiones de Payment Service a Notification Service agotan el tiempo (el servicio no responde)
14:10: Payment Service implementa reintentos en cliente (exponential backoff)
14:15: La tormenta de reintentos se propaga al API Gateway
14:15: API Gateway sobrecargado, la cola de peticiones se acumula
14:20: Todas las peticiones de usuario agotan el tiempo
14:20: Se declara incidente, se avisa al ingeniero de guardia

Lo que el monitoring habría detectado:

14:01: Alerta "número de reinicios de Notification Service supera el umbral"
14:06: Alerta "latencia de creación de Pods de Notification Service > 30 segundos"
14:07: Alerta "health check de Notification Service fallando"
14:08: Alerta "pico de latencia Payment Service → Notification Service"
14:09: Alerta "pico de tasa de errores en Payment Service"

Las alertas tempranas podrían haber evitado la cascada: reiniciar Notification Service manualmente o ajustar la estrategia de reintentos en Payment Service.

Implementación del monitoring de microservicios#

Opción 1: DIY con Prometheus + Grafana#

Prometheus:
  - Hace scraping del endpoint /metrics de cada servicio
  - Almacena métricas en una base de datos de series temporales
  - Ejecuta reglas de alerta (si una métrica supera el umbral, alerta)

Grafana:
  - Visualiza métricas de Prometheus
  - Dashboards por servicio
  - Dashboards por servicio y entre servicios

Implementación: open-source, gratis, requiere conocimientos de infraestructura
Coste: bajo (solo infraestructura), alto (tiempo de ingeniería)
Adecuado para: equipos con experiencia en DevOps

Opción 2: Servicio gestionado (Datadog, New Relic)#

Agente de Datadog/New Relic:
  - Corre como sidecar en cada Pod
  - Recolecta métricas, logs y trazas
  - Envía a un servicio gestionado

Dashboard:
  - Dashboards prediseñados para Kubernetes
  - APM para comunicación entre servicios
  - Trazado distribuido integrado

Implementación: herramienta de proveedor, configuración compleja, potente
Coste: alto (precio por host/por GB), bajo (tiempo de ingeniería)
Adecuado para: equipos con presupuesto y menos experiencia en operaciones

Opción 3: Service Mesh con monitoring integrado#

Istio/Linkerd:
  - El proxy sidecar intercepta toda la comunicación entre servicios
  - Rastrea automáticamente latencia, errores y tráfico
  - Proporciona observabilidad sin cambios en el código

Monitoring:
  - Los dashboards del service mesh muestran las dependencias entre servicios
  - Estado del circuit breaker
  - Distribución de tráfico
  - Latencia de petición por ruta

Implementación: cambio a nivel de infraestructura, potente pero complejo
Coste: sobrecarga de infraestructura (CPU/memoria del sidecar)
Adecuado para: organizaciones grandes con muchos servicios

Checklist de monitoring de microservicios#

Por servicio#

☐ Endpoint de health check implementado (/health devuelve 200 cuando está sano)
☐ Endpoint de métricas expuesto (/metrics para scraping de Prometheus)
☐ Disponibilidad del servicio monitorizada (Pod corriendo, health check pasando)
☐ Tiempo de respuesta del servicio monitorizado (latencia P95 medida)
☐ Tasa de errores del servicio monitorizada (errores 4xx, 5xx medidos)
☐ Logs del servicio centralizados (ELK, Splunk o similar)

Por comunicación entre servicios#

☐ Latencia entre servicios monitorizada (servicio A → servicio B)
☐ Tasa de errores por comunicación entre servicios medida
☐ Estado del circuit breaker monitorizado (si aplica)
☐ Manejo de timeouts verificado (lógica de reintentos correcta)

Por cluster de Kubernetes#

☐ Salud de los Pods monitorizada (número de reinicios, memoria, CPU)
☐ Salud de los nodos monitorizada (estado, disco, memoria)
☐ Salud del Deployment monitorizada (réplicas deseadas vs. listas)
☐ Salud de los volúmenes persistentes monitorizada (espacio disponible, errores de I/O)
☐ Uso de recursos del namespace monitorizado (límites de CPU, memoria)

Trazado distribuido#

☐ Trazas de petición recolectadas (request ID propagado a través de los servicios)
☐ Visualización de trazas disponible (ver el flujo de la petición)
☐ Desglose de latencia por traza visible (¿qué servicio es lento?)
☐ Detección de errores en trazas (¿qué servicio falló?)

Buenas prácticas para el monitoring de microservicios#

1. Correlation IDs para trazado distribuido

Cada petición debe tener un ID único propagado por todos los servicios:

Petición de usuario:
  Header: X-Request-ID: 12345

Servicio A:
  logs: "Request 12345: Started"
  llama al Servicio B con header: X-Request-ID: 12345

Servicio B:
  logs: "Request 12345: Received from Service A"
  llama al Servicio C con header: X-Request-ID: 12345

Servicio C:
  logs: "Request 12345: Processing complete"

Más tarde, recupera todos los logs de la petición 12345 para ver el flujo completo

2. Logging estructurado

No loguees: "Error occurred" Loguea: JSON con contexto

{
  "timestamp": "2026-02-20T14:32:15Z",
  "request_id": "12345",
  "service": "payment-service",
  "level": "error",
  "message": "Payment authorization failed",
  "error_code": "STRIPE_AUTH_FAILED",
  "attempt": 1,
  "latency_ms": 2500,
  "status_code": 503
}

3. Patrón Circuit Breaker

Implementa circuit breakers para evitar fallos en cascada:

Normal:
  Payment Service → llama a la API de Stripe
  Stripe devuelve 200 (éxito)
  La petición continúa

Modo de fallo (Circuito abierto):
  La API de Stripe devuelve 503 (servicio caído)
  Tras 5 fallos, el circuit breaker se abre
  Las peticiones siguientes fallan rápido (sin intentar llamar a Stripe)
  La latencia de llamada a la API de Stripe baja de 2s a 50ms
  El sistema se degrada de forma elegante en lugar de fallar en cascada

Recuperación:
  Circuit breaker en half-open (prueba 1 petición)
  Si tiene éxito, aumenta poco a poco las peticiones a Stripe
  Si falla, el circuito vuelve a abierto

Trampas específicas de Kubernetes en monitoring#

Trampa 1: la IP del Pod cambia al reiniciarse#

Cuando un Pod se reinicia, su IP cambia. Los registros DNS deben actualizarse.

El monitoring debe tenerlo en cuenta:

Monitoriza por nombre de servicio, no por IP del Pod
Usa DNS de Kubernetes (service-name.namespace.svc.cluster.local)
Monitoriza los endpoints del servicio de Kubernetes (¿están registrados los Pods?)

Trampa 2: retrasos del init container#

Los init containers de Kubernetes se ejecutan antes que el contenedor principal. Si el init container es lento:

Estado del Pod: "Running" (técnicamente correcto)
Pero en realidad: el init container sigue corriendo, el servicio aún no está listo
Los health checks pueden fallar (el servicio aún no responde)

Soluciones:

No alertes por fallos de health check en los primeros 60 segundos
Usa startup probes (distintas de las liveness probes)
Monitoriza la latencia de finalización del init container

Trampa 3: los límites de recursos afectan al rendimiento#

Si el límite de CPU del Pod es demasiado bajo:

Estado del Pod: Running
Pero en realidad: CPU throttled, pico de latencia
El monitoring muestra un pico de latencia pero el uso de CPU muestra 100 % throttled

Solución: monitoriza tanto el uso de CPU COMO el throttling de CPU
Alerta si la CPU está throttled > 20 % del tiempo

Nova Uptime para monitoring de microservicios#

El plan gratis de Nova Uptime puede monitorizar microservicios:

Health checks de servicios: monitoriza endpoints de salud para cada servicio
Monitoring de API: rastrea tiempos de respuesta y tasas de error
Monitoring de webhooks: verifica la comunicación servicio a servicio
Monitoring de email: comprueba que el servicio de notificaciones entrega los emails
Monitoring de API pública: si los servicios exponen APIs públicas

Para un monitoring de microservicios completo, usa herramientas especializadas (Prometheus, Datadog, New Relic). Pero Nova Uptime puede complementarlas monitorizando la salud de servicios externos y las APIs de cara al cliente.

Resumen: monitoring de microservicios más allá del uptime simple#

Los microservicios requieren un monitoring más sofisticado que los sistemas tradicionales.

Tu plan de acción:

Implementa endpoints de health check en cada microservicio
Expón métricas (endpoint /metrics para Prometheus)
Añade correlation IDs a todos los flujos de petición
Implementa circuit breakers para evitar fallos en cascada
Usa logging estructurado con contexto de la petición
Monitoriza la comunicación entre servicios (latencia, errores)
Monitoriza la infraestructura de Kubernetes (Pods, nodos, Deployments)
Configura trazado distribuido (ver el flujo completo de la petición)
Crea dashboards por servicio (visibilidad de cada servicio)
Alerta ante la degradación (no solo ante fallos completos)

Empieza con Nova Uptime para monitorizar tus APIs de cara al cliente. Añade monitoring de health checks. Complementa con Prometheus/Grafana o un servicio gestionado para un monitoring de infraestructura más profundo.

Tus microservicios son complejos. Tu monitoring debería estar a la altura de esa complejidad.

Monitoring de microservicios y Kubernetes: más allá de los simples chequeos de uptime