Observabilidad en microservicios: lecciones del campo

Los tres pilares, en la practica

Todo el mundo conoce los tres pilares de la observabilidad: logs, metricas y trazas. Lo que la teoria no cuenta es que la inmensa mayoria de los equipos solo implementan el primero y medio. Tienen logs (muchos, desestructurados, dispersos en veinte consolas distintas), algunas metricas de infraestructura que nadie mira excepto cuando algo esta en llamas, y cero trazas distribuidas.

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

Logs son el pilar mas accesible y el mas abusado. El error clasico es tratar los logs como un sistema de depuracion en produccion: log.info para todo, sin estructura, sin contexto, sin correlacion entre servicios. Un log util tiene formato estructurado (JSON), incluye un correlation ID que conecte la peticion a traves de todos los servicios que toca, e incluye los campos de negocio relevantes (ID de pedido, ID de cliente, operacion). La herramienta da igual (Loki, Elasticsearch, CloudWatch Logs), pero sin estructura, cualquier herramienta es un grep glorificado.

Metricas son donde esta el valor operativo real. Una metrica bien definida te dice el estado del sistema en un vistazo. Las cuatro metricas doradas de Google SRE (latencia, trafico, errores y saturacion) son un punto de partida excelente. En la practica, anadimos metricas de negocio: pedidos procesados por minuto, pagos completados, envios generados. Prometheus es el estandar 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 que metricas importan.

Trazas distribuidas son el pilar mas poderoso y el menos implementado. Una traza te muestra el camino completo de una peticion a traves 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 instrumentacion activa en cada servicio. Esto ha mejorado dramaticamente con OpenTelemetry.

Trazas distribuidas con OpenTelemetry

OpenTelemetry ha resuelto el problema de fragmentacion que frenaba la adopcion de trazas distribuidas. Antes tenias que elegir entre Jaeger, Zipkin, AWS X-Ray o la solucion propietaria de tu vendor, y la instrumentacion era diferente para cada uno. OpenTelemetry (OTel) proporciona un SDK unico que exporta a cualquier backend.

La implementacion practica sigue estos pasos:

Instrumentacion automatica es el punto de partida. OTel ofrece auto-instrumentation para los frameworks mas comunes: Express, Spring Boot, Django, Flask, gRPC. Instalas una libreria, configuras un exporter y obtienes trazas basicas sin modificar codigo de aplicacion. Cubre llamadas HTTP, consultas a base de datos, mensajes de cola y llamadas a servicios externos.

Propagacion 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 estandar). Cada servicio que recibe una peticion 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 propagacion ocurre automaticamente.

Instrumentacion manual es necesaria para capturar logica de negocio. La auto-instrumentacion sabe que hiciste una query SQL pero no sabe que esa query buscaba disponibilidad de stock para un pedido prioritario. Anade spans personalizados con atributos de negocio en los puntos criticos: procesamiento de pedidos, validacion de pagos, calculo de rutas. No instrumentes todo; instrumenta lo que necesitas para responder la pregunta “por que este pedido tardo 8 segundos?”.

Para el backend de trazas, Grafana Tempo es nuestra eleccion actual. Almacena trazas en object storage (S3, GCS) sin necesidad de indexacion, lo que reduce costes dramaticamente comparado con Jaeger con Elasticsearch. La integracion con Grafana permite navegar de una metrica 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 mas equipos fracasan. No por falta de herramientas, sino por exceso de alertas. Alert fatigue es un problema real y medible: cuando un equipo recibe mas de 20 alertas diarias, empieza a ignorarlas. Y una alerta ignorada es peor que no tener alerta, porque crea una falsa sensacion de seguridad.

La distincion fundamental es entre alertas basadas en sintomas y alertas basadas en causas:

• Sintoma: “El error rate del endpoint /api/orders supera el 5%.” Esto requiere accion 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 trafico es normal.

Alerta sobre sintomas. Investiga causas. La regla practica es: una alerta debe despertar a alguien a las 3 de la manana solo si un usuario esta experimentando degradacion de servicio. Todo lo demas es una notificacion informativa que puede esperar al horario laboral.

Cada alerta debe tener un runbook asociado. Un runbook no es documentacion generica; es un procedimiento paso a paso para diagnosticar y mitigar esa alerta especifica. “El consumer lag de Kafka supera 10.000 mensajes” -> verificar si hay un despliegue en curso, revisar metricas 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 practica, configuramos alertas en dos niveles:

• P1 (paging): Afecta a usuarios. Error rate alto, latencia degradada, servicio caido. Notificacion inmediata via PagerDuty o OpsGenie.
• P2 (ticket): Indicadores de problemas futuros. Disco al 80%, certificados que expiran en 7 dias, consumer lag creciente. Crean tickets automaticamente y se revisan en la proxima sesion de trabajo.

Dashboards: operaciones vs depuracion

Un error comun es construir un unico dashboard que intente servir para todo. El resultado es un panel con 40 graficas que nadie mira. Distinguimos dos tipos de dashboards con audiencias y propositos diferentes.

Dashboards de operaciones son para el dia a dia. Muestran el estado del sistema en tiempo real: metricas doradas por servicio, error rates, latencia p50/p95/p99, y metricas de negocio clave. Deben caber en una pantalla. Si tienes que hacer scroll, tienes demasiada informacion. Estos dashboards estan en pantallas visibles en la oficina o son la primera pagina que abre el equipo de guardia. En Grafana, usamos variables de template para filtrar por servicio o entorno sin multiplicar dashboards.

Dashboards de depuracion son para investigar incidentes. Son mas detallados: metricas de recursos por pod, latencia por dependencia, queries lentas, throughput de colas. No necesitan ser bonitos ni estar siempre actualizados. Su funcion es proporcionar datos para root cause analysis. La clave es que esten conectados con los logs y las trazas. En Grafana, los links de tipo “Explore” permiten saltar de una metrica anomala al log o traza correspondiente.

El flujo durante un incidente deberia ser: dashboard de operaciones detecta el sintoma -> alerta notifica al equipo -> dashboard de depuracion muestra donde esta el problema -> trazas muestran que servicio falla y por que -> logs proporcionan el detalle del error.

Construir una cultura de observabilidad

La herramienta mas 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 practica que se integra en el ciclo de desarrollo.

Observabilidad como parte del definition of done. Un feature no esta terminado hasta que tiene metricas, logs estructurados y trazas instrumentadas. Esto no significa instrumentar cada linea de codigo, sino los puntos criticos: endpoints nuevos, integraciones con servicios externos, operaciones de base de datos significativas.

Post-mortems sin culpa. Cuando un incidente ocurre, la pregunta no es “quien tuvo la culpa” sino “que nos falto ver y como mejoramos la deteccion”. Cada post-mortem deberia producir al menos una mejora concreta en observabilidad: una nueva alerta, un dashboard mejorado, un log anadido.

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 dispararian en un incidente real.

Revision periodica 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 accion (alert fatigue). Ajusta umbrales basandote 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 tecnologico; fue cultural. Las herramientas solo cambiaron de Elasticsearch a Grafana Stack. Lo que cambio fue como el equipo las usaba.

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