Observabilidad en microservicios: lecciones del campo

Los tres pilares, en la práctica

Todo el mundo conoce los tres pilares de la observabilidad: logs, métricas y trazas. Lo que la teoría no cuenta es que la inmensa mayoría de los equipos solo implementan el primero y medio. Tienen logs (muchos, desestructurados, dispersos en veinte consolas distintas), algunas métricas de infraestructura que nadie mira excepto cuando algo está en llamas, y cero trazas distribuidas.

En nuestra experiencia implementando observabilidad para clientes con arquitecturas de microservicios, el problema rara vez es tecnológico. Las herramientas existen y funcionan. El problema es de prioridad y de disciplina.

Logs son el pilar más accesible y el más abusado. El error clásico es tratar los logs como un sistema de depuración en producción: log.info para todo, sin estructura, sin contexto, sin correlación entre servicios. Un log útil tiene formato estructurado (JSON), incluye un correlation ID que conecte la petición a través de todos los servicios que toca, e incluye los campos de negocio relevantes (ID de pedido, ID de cliente, operación). La herramienta da igual (Loki, Elasticsearch, CloudWatch Logs), pero sin estructura, cualquier herramienta es un grep glorificado.

Métricas son donde está el valor operativo real. Una métrica bien definida te dice el estado del sistema en un vistazo. Las cuatro métricas doradas de Google SRE (latencia, tráfico, errores y saturación) son un punto de partida excelente. En la práctica, añadimos métricas de negocio: pedidos procesados por minuto, pagos completados, envíos generados. Prometheus es el estándar de facto para recogerlas, y su modelo de pull funciona bien hasta escalas considerables. Para equipos que ya usan Datadog o New Relic, la prioridad no es cambiar de herramienta sino definir qué métricas importan.

Trazas distribuidas son el pilar más poderoso y el menos implementado. Una traza te muestra el camino completo de una petición a través de todos los servicios: tiempos, dependencias, errores. Sin trazas, diagnosticar un problema en una arquitectura de microservicios es como buscar una aguja en un pajar de logs dispersos. El motivo por el que pocos equipos las implementan es que requieren instrumentación activa en cada servicio. Esto ha mejorado dramáticamente con OpenTelemetry.

Trazas distribuidas con OpenTelemetry

OpenTelemetry ha resuelto el problema de fragmentación que frenaba la adopción de trazas distribuidas. Antes tenías que elegir entre Jaeger, Zipkin, AWS X-Ray o la solución propietaria de tu vendor, y la instrumentación era diferente para cada uno. OpenTelemetry (OTel) proporciona un SDK único que exporta a cualquier backend.

La implementación práctica sigue estos pasos:

Instrumentación automática es el punto de partida. OTel ofrece auto-instrumentation para los frameworks más comunes: Express, Spring Boot, Django, Flask, gRPC. Instalas una librería, configuras un exporter y obtienes trazas básicas sin modificar código de aplicación. Cubre llamadas HTTP, consultas a base de datos, mensajes de cola y llamadas a servicios externos.

Propagación de contexto es lo que conecta las trazas entre servicios. El trace ID y el span ID se propagan en headers HTTP (W3C Trace Context es el estándar). Cada servicio que recibe una petición extrae el contexto, crea un span hijo y lo propaga al siguiente servicio. Si usas un API gateway o un service mesh como Istio, parte de esta propagación ocurre automáticamente.

Instrumentación manual es necesaria para capturar lógica de negocio. La auto-instrumentación sabe que hiciste una query SQL pero no sabe que esa query buscaba disponibilidad de stock para un pedido prioritario. Añade spans personalizados con atributos de negocio en los puntos críticos: procesamiento de pedidos, validación de pagos, cálculo de rutas. No instrumentes todo; instrumenta lo que necesitas para responder la pregunta “por qué este pedido tardó 8 segundos?”.

Para el backend de trazas, Grafana Tempo es nuestra elección actual. Almacena trazas en object storage (S3, GCS) sin necesidad de indexación, lo que reduce costes dramáticamente comparado con Jaeger con Elasticsearch. La integración con Grafana permite navegar de una métrica a los logs y las trazas correlacionadas, que es donde la observabilidad pasa de ser tres herramientas separadas a ser un sistema coherente.

Alerting que funciona

El alerting es donde más equipos fracasan. No por falta de herramientas, sino por exceso de alertas. Alert fatigue es un problema real y medible: cuando un equipo recibe más de 20 alertas diarias, empieza a ignorarlas. Y una alerta ignorada es peor que no tener alerta, porque crea una falsa sensación de seguridad.

La distinción fundamental es entre alertas basadas en síntomas y alertas basadas en causas:

• Síntoma: “El error rate del endpoint /api/orders supera el 5%.” Esto requiere acción inmediata.
• Causa: “El CPU del pod payment-service supera el 80%.” Esto puede o no ser un problema. Un CPU al 80% durante un pico de tráfico es normal.

Alerta sobre síntomas. Investiga causas. La regla práctica es: una alerta debe despertar a alguien a las 3 de la mañana solo si un usuario está experimentando degradación de servicio. Todo lo demás es una notificación informativa que puede esperar al horario laboral.

Cada alerta debe tener un runbook asociado. Un runbook no es documentación genérica; es un procedimiento paso a paso para diagnosticar y mitigar esa alerta específica. “El consumer lag de Kafka supera 10.000 mensajes” -> verificar si hay un despliegue en curso, revisar métricas de CPU del consumidor, escalar horizontalmente si la causa es volumen, investigar errores si la causa es procesamiento fallido. Sin runbooks, la respuesta a incidentes depende del conocimiento tribal del ingeniero de guardia.

En la práctica, configuramos alertas en dos niveles:

• P1 (paging): Afecta a usuarios. Error rate alto, latencia degradada, servicio caído. Notificación inmediata vía PagerDuty o OpsGenie.
• P2 (ticket): Indicadores de problemas futuros. Disco al 80%, certificados que expiran en 7 días, consumer lag creciente. Crean tickets automáticamente y se revisan en la próxima sesión de trabajo.

Dashboards: operaciones vs depuración

Un error común es construir un único dashboard que intente servir para todo. El resultado es un panel con 40 gráficas que nadie mira. Distinguimos dos tipos de dashboards con audiencias y propósitos diferentes.

Dashboards de operaciones son para el día a día. Muestran el estado del sistema en tiempo real: métricas doradas por servicio, error rates, latencia p50/p95/p99, y métricas de negocio clave. Deben caber en una pantalla. Si tienes que hacer scroll, tienes demasiada información. Estos dashboards están en pantallas visibles en la oficina o son la primera página que abre el equipo de guardia. En Grafana, usamos variables de template para filtrar por servicio o entorno sin multiplicar dashboards.

Dashboards de depuración son para investigar incidentes. Son más detallados: métricas de recursos por pod, latencia por dependencia, queries lentas, throughput de colas. No necesitan ser bonitos ni estar siempre actualizados. Su función es proporcionar datos para root cause analysis. La clave es que estén conectados con los logs y las trazas. En Grafana, los links de tipo “Explore” permiten saltar de una métrica anómala al log o traza correspondiente.

El flujo durante un incidente debería ser: dashboard de operaciones detecta el síntoma -> alerta notifica al equipo -> dashboard de depuración muestra dónde está el problema -> trazas muestran qué servicio falla y por qué -> logs proporcionan el detalle del error.

Construir una cultura de observabilidad

La herramienta más cara del mercado no sirve de nada si nadie la usa. La observabilidad no es un proyecto que se implementa y se olvida; es una práctica que se integra en el ciclo de desarrollo.

Observabilidad como parte del definition of done. Un feature no está terminado hasta que tiene métricas, logs estructurados y trazas instrumentadas. Esto no significa instrumentar cada línea de código, sino los puntos críticos: endpoints nuevos, integraciones con servicios externos, operaciones de base de datos significativas.

Post-mortems sin culpa. Cuando un incidente ocurre, la pregunta no es “quién tuvo la culpa” sino “qué nos faltó ver y cómo mejoramos la detección”. Cada post-mortem debería producir al menos una mejora concreta en observabilidad: una nueva alerta, un dashboard mejorado, un log añadido.

Game days y chaos engineering. Probar la observabilidad antes de necesitarla. Inyecta latencia artificial en un servicio y verifica que las alertas se disparan, que los dashboards muestran el problema y que el runbook funciona. Herramientas como Gremlin o LitmusChaos permiten hacerlo de forma controlada. Hemos visto equipos descubrir en game days que sus alertas estaban configuradas con umbrales absurdos que nunca se dispararían en un incidente real.

Revisión periódica de alertas. Cada trimestre, revisa todas las alertas activas. Elimina las que nunca se disparan (umbrales demasiado altos) y las que se disparan constantemente sin acción (alert fatigue). Ajusta umbrales basándote en datos reales, no en intuiciones.

En abemon hemos implementado estos principios con equipos que pasaron de “apagar fuegos” como modo operativo normal a detectar el 90% de los problemas antes de que los usuarios los reportaran. El cambio no fue tecnológico; fue cultural. Las herramientas solo cambiaron de Elasticsearch a Grafana Stack. Lo que cambió fue como el equipo las usaba.

La observabilidad madura es una característica de las organizaciones que han alcanzado los estadios avanzados de adopción cloud. Si quieres entender en qué punto está tu organización y qué capacidades desarrollar a continuación, el modelo de madurez cloud 2026 ofrece un marco de evaluación por etapas.

La observabilidad no es un producto que compras. Es una disciplina que practicas.