Observabilidad en DevOps: cómo empezar bien
La observabilidad en DevOps es la capacidad de entender por qué un sistema se comporta como lo hace, no solo si está arriba. Se apoya en tres pilares (métricas, logs y traces) y el primer paso real no es instalar una herramienta, sino definir qué vas a medir. Todo lo demás viene después.
Si alguna vez te tocó un incidente en producción donde el dashboard decía “todo verde” mientras los usuarios se quejaban, ya entendiste el problema que la observabilidad viene a resolver. El monitoreo tradicional te avisa que algo se rompió. La observabilidad te dice por qué.
Observabilidad es la práctica de instrumentar aplicaciones para que emitan datos de telemetría (métricas, logs y traces) que después se correlacionan para reconstruir el estado interno de un sistema distribuido. A diferencia del monitoreo, que responde “¿está funcionando?”, la observabilidad responde “¿por qué se comporta así?”. Es fundacional en arquitecturas de microservicios y cloud-native, donde las fallas son inevitables y las causas raíz quedan escondidas. Ya lo cubrimos antes en en tus flujos CI/CD.
En 30 segundos
- Monitoreo vs observabilidad: el primero pregunta “¿está arriba?”, el segundo “¿por qué se comporta así?”.
- Tres pilares: métricas, logs y traces. Solos no sirven de mucho, el valor está en correlacionarlos.
- OpenTelemetry es el estándar abierto para emitir telemetría; Prometheus es lo más usado para métricas.
- Definí SLIs primero: qué medís antes de elegir herramientas. Al revés no funciona.
- Empezá chico: una métrica crítica, una app instrumentada, un SLO. Iterá desde ahí.
¿Qué diferencia hay entre observabilidad y monitoreo?
El monitoreo pregunta una sola cosa: ¿está arriba? Chequea umbrales conocidos, te tira una alerta cuando el CPU pasa el 80% y listo. Sirve, pero se queda corto cuando el problema no lo viste venir.
La observabilidad va al análisis causal. En vez de gestionar síntomas, correlaciona métricas, logs y traces para reconstruir qué pasó por dentro. Según la guía de Maricode en dev.to, esta distinción es el corazón del asunto: pasás de administrar síntomas a entender la causa. Sin eso, estás adivinando en vez de trabajar con datos.
¿Por qué la observabilidad en DevOps es crítica en microservicios?
Acá viene lo bueno. Cuando tenés un monolito, rastrear un problema es medio directo. Pero en cloud-native, los servicios se comunican de forma asincrónica, las dependencias se multiplican y los dominios de falla se expanden.
Ponele el ejemplo clásico: un pico de latencia en tu servicio de pagos. Mirás el servicio de pagos y está impecable. ¿Y entonces? La causa real estaba en una query lenta de una base de datos, en un microservicio downstream tres saltos más abajo. Sin traces distribuidos que sigan la request de punta a punta, buscás eso a ciegas. Este tipo de arquitecturas, montadas sobre infraestructura cloud con decenas de servicios hablando entre sí, es justo donde la observabilidad deja de ser opcional.
Los tres pilares: métricas, logs y traces
Los tres pilares no compiten, se complementan. Cada uno te muestra una cara distinta del mismo sistema. Entre herramientas como Jenkins profundizamos sobre esto.
- Métricas: números agregados en el tiempo. Latencia, tasa de errores, requests por segundo. Livianas y baratas de guardar, pero no te dicen el detalle de una request puntual.
- Logs: eventos discretos con contexto. Lo que pasó, cuándo, con qué payload. Detallados, aunque en volumen alto se vuelven caros y ruidosos.
- Traces: el recorrido completo de una request a través de todos los servicios. Un trace individual te muestra dónde se gasta el tiempo en la cadena, salto por salto.
La magia está en cruzarlos. Una métrica te dice que la latencia subió, un trace te muestra en qué servicio, y el log de ese servicio te dice por qué. Los tres juntos.
OpenTelemetry: el estándar de instrumentación (y el riesgo del sampling)
OpenTelemetry es un estándar abierto para instrumentar aplicaciones y emitir telemetría sin quedar atado a un proveedor. Instrumentás una vez y exportás a donde quieras. Suena redondo, pero tiene una trampa.
El sampling. Si configurás mal el sampling rate, terminás con traces incompletos. ¿Y qué pasa cuando el trace que necesitás para debuggear justo es el que se descartó? Exacto, te quedaste sin data en el peor momento. La guía de dev.to marca esto como uno de los errores centrales: hay que calibrar el sampling según el patrón de tráfico, no dejarlo en el default y rezar. Podés consultar la documentación oficial de OpenTelemetry para las estrategias de sampling.
Prometheus para métricas: cuidado con los scrape intervals
Prometheus es la herramienta más usada para métricas en entornos cloud-native. Funciona con scraping: cada cierto intervalo va y recolecta las métricas de tus targets. El punto crítico es ese intervalo. Sobre eso tratamos en la guía de hreflang para audiencias globales.
Si el scrape interval es muy largo, te perdés picos de latencia que ocurren entre una lectura y la siguiente. El sistema tuvo un problema de 10 segundos, Prometheus scrapeó cada 60, y ese pico nunca existió para tus dashboards. Ojo con usar el mismo intervalo genérico para todas las métricas: las que cambian rápido necesitan lecturas más frecuentes que las estables.
SLIs, SLOs y SLAs: definí esto antes que nada
Tres siglas que se confunden todo el tiempo, pero son distintas:
| Concepto | Qué es | Ejemplo |
|---|---|---|
| SLI (Indicator) | Lo que medís, la métrica cruda | Latencia p95 del endpoint de checkout |
| SLO (Objective) | El objetivo interno sobre ese SLI | p95 por debajo de 300ms el 99% del tiempo |
| SLA (Agreement) | La promesa formal al cliente, con consecuencias | 99,9% de disponibilidad o hay crédito |
La lógica es de adentro hacia afuera. Los SLIs son lo que medís, los SLOs son tus metas internas (siempre más exigentes que el SLA), y los SLAs son lo que firmás con el cliente. Y algo que la mayoría hace al revés: definí los SLIs antes de elegir herramientas. Si primero comprás la plataforma y después pensás qué medir, terminás midiendo lo que la herramienta hace fácil, no lo que importa.
Cómo empiezo: primeros pasos concretos
No intentes instrumentar todo de una. Ese es el camino directo al abandono. Andá incremental:
- Elegí una métrica crítica: latencia o tasa de errores de tu servicio más importante. Una sola.
- Instrumentá una app con OpenTelemetry: empezá por el servicio que más te duele cuando falla.
- Configurá Prometheus: con un scrape interval acorde a esa métrica, no genérico.
- Definí un SLO inicial: un objetivo realista y medible. Después lo ajustás con datos reales.
- Iterá: cuando eso funciona, sumás el siguiente servicio. Y así.
Relacionado: ejecutar agentes locales sin API te abre caminos para experimentar con observabilidad descentralizada.
Errores comunes al arrancar con observabilidad
- Instalar herramientas sin definir SLIs: terminás con dashboards hermosos que no responden ninguna pregunta útil. Primero decidí qué medís.
- Sampling mal calibrado: un rate que descarta los traces que después necesitás. Ajustalo al patrón de tráfico real.
- Scrape intervals genéricos: el mismo intervalo para todo hace que se te escapen los picos en las métricas volátiles.
- No correlacionar logs con traces: tener los tres pilares pero mirarlos por separado es tener tres herramientas y ningún sistema. El valor está en cruzarlos.
Preguntas Frecuentes
¿Qué es observabilidad y en qué se diferencia del monitoreo?
La observabilidad es la capacidad de entender por qué un sistema se comporta como lo hace, correlacionando métricas, logs y traces. El monitoreo solo verifica si algo está funcionando contra umbrales conocidos; la observabilidad te deja diagnosticar problemas que no anticipaste.
¿Cuáles son las herramientas esenciales para empezar?
OpenTelemetry para instrumentar y emitir telemetría, y Prometheus para métricas, son la base más común en entornos cloud-native. OpenTelemetry es un estándar abierto que evita quedar atado a un proveedor, lo que te da flexibilidad para exportar la data a distintos backends.
¿Qué son SLIs, SLOs y SLAs?
Un SLI es la métrica que medís (por ejemplo, latencia), un SLO es tu objetivo interno sobre esa métrica, y un SLA es la promesa formal al cliente con consecuencias si no la cumplís. Los SLOs siempre deberían ser más exigentes que los SLAs para tener margen.
¿Por qué hay que definir SLIs antes de elegir herramientas?
Porque si elegís la herramienta primero, terminás midiendo lo que esa plataforma hace fácil en vez de lo que importa para tu negocio. Definir los SLIs antes te asegura que la instrumentación responda a preguntas reales sobre la experiencia del usuario.
¿Puedo implementar observabilidad de a poco?
Sí, y es lo recomendable. Empezá con una métrica crítica en un solo servicio, instrumentalo con OpenTelemetry, configurá Prometheus y definí un SLO inicial. Intentar cubrir todo de entrada suele terminar en proyectos abandonados por complejidad.
Conclusión
La observabilidad dejó de ser un lujo de equipos grandes. En cuanto tu arquitectura tiene más de un par de servicios hablando entre sí, sin traces distribuidos estás debuggeando a ciegas. Pero el error más caro no es técnico, es de orden: comprar la herramienta antes de saber qué querés medir.
Arrancá al revés de como la mayoría lo hace. Definí un SLI que le importe a tu usuario, instrumentá un solo servicio con OpenTelemetry, poné un SLO realista y recién ahí sumás complejidad. Menos herramientas, más criterio. El resto se construye iterando.
