Curso exprés · No. 19
Cuando tu código corre en tu portátil puedes pausarlo y husmear por dentro. Cuando corre en producción sirviendo a usuarios reales, no puedes — solo sabes lo que ocurre por lo que el sistema te cuenta. La observability es el oficio de hacer que un sistema se explique a sí mismo, mediante logs, metrics y traces, para que cuando algo se rompa a las 3 de la madrugada puedas hacer preguntas y obtener respuestas en lugar de adivinar.
Solo lo esencial · Una imagen por idea · Aprende las palabras
Todo el campo existe por un hecho duro: no puedes depurar un sistema en producción vivo como depuras el código en tu máquina. Así que tienes que hacer que el sistema te cuente lo que está haciendo.
No puedes adjuntar un debugger a producción
Un piloto no puede salir e inspeccionar el motor en pleno vuelo — vuela enteramente por los instrumentos del panel, confiando en que las agujas le digan lo que está pasando.
En tu portátil pausas el código, inspeccionas variables, avanzas paso a paso. En producción — servidores reales, usuarios reales, ahora mismo — no puedes detenerlo para mirar. Solo puedes enterarte de lo que ocurre por las señales que el sistema emite mientras corre. Este es el cambio de fondo: en producción vuelas por instrumentos, y la observability consiste en tener los instrumentos correctos en el panel antes de necesitarlos.
El monitoring responde preguntas conocidas; la observability responde nuevas
El tablero de un coche muestra las pocas cosas que sabías que debías vigilar — velocidad, combustible, temperatura. Pero cuando empieza un ruido extraño y nuevo, necesitas poder investigar algo para lo que nadie puso una aguja.
El monitoring es vigilar problemas que anticipaste — dashboards y alertas para modos de fallo conocidos. La observability es la propiedad más profunda: ¿puedes responder preguntas que no previste, solo con los datos que el sistema produce? Las caídas reales suelen ser inéditas — «¿por qué los usuarios en Brasil ven checkouts lentos desde las 2 de la tarde?» — y la observability es si tu sistema emite lo suficiente para dejarte perseguir una pregunta que nunca planeaste.
Una black box es un sistema sobre el que solo puedes adivinar
Una máquina expendedora que se quedó con el dinero de alguien y no dio nada, sin pantalla y sin recibo — todo lo que puedes hacer es encogerte de hombros y adivinar, porque no te dice nada.
Un sistema que emite poco es una black box: cuando se porta mal, quedas reducido a adivinar y reiniciar. El coste aparece en el peor momento — un incidente en producción donde cada minuto cuenta y no tienes ni idea de dónde mirar. La observability se paga por adelantado, instrumentando el sistema mientras está en calma, para que cuando esté en llamas tengas luz para ver. El momento de añadirla es antes de necesitarla.
No puedes pausar producción para inspeccionarla. La observability es construir el sistema para que se explique a sí mismo — para que puedas responder preguntas que nunca previste, no solo vigilar las que sí.
La señal más antigua y detallada es el log: un diario continuo de lo que hizo el sistema. Es lo primero a lo que recurres y lo más fácil de usar mal.
Un log es el diario del sistema
El cuaderno de bitácora de un barco: entradas con marca de tiempo anotando qué pasó y cuándo — «10:42, entramos al puerto» — para que cualquiera pueda reconstruir la travesía después.
Un log es un registro con marca de tiempo de un evento: «el usuario 42 inició sesión», «el pago falló: tarjeta rechazada», «empezó a procesar el pedido 91». Cada línea es una nota pequeña y detallada sobre algo que ocurrió, escrita a medida que el código corre. Los logs son la señal más rica porque cargan con los detalles concretos — exactamente qué, exactamente cuándo, con la información adjunta. Cuando necesitas saber qué pasó de verdad en un caso, los logs son donde miras.
Los structured logs se pueden buscar
La diferencia entre una caja de zapatos llena de notas a mano y una hoja de cálculo — ambas guardan los hechos, pero solo una te deja filtrar al instante todo lo del cliente 42.
Una línea de texto libre es difícil de buscar entre millones de entradas. Los structured logs registran cada evento como datos — campos como user_id: 42, status: failed, duration_ms: 230 — para que puedas consultarlos: «muéstrame todos los pagos fallidos de más de 500ms de hoy». Esto convierte los logs de un muro de texto que recorres con scroll en una base de datos que puedes interrogar. La estructura es lo que hace que los logs sean utilizables a escala de producción.
Los levels separan la señal del ruido
Un diario donde las entradas rutinarias van a lápiz y las emergencias en tinta roja — para que en una crisis puedas saltar directo a lo rojo e ignorar el resto.
Cada log tiene un level que marca su importancia: DEBUG e INFO para el detalle rutinario, WARN para algo raro, ERROR para un fallo real. Los levels te dejan subir el volumen al investigar y bajarlo en la operación normal, y saltar directo a los errores en una avalancha de entradas. Bien usados, los levels son cómo mantienes localizables las líneas importantes; ignorados, todos los logs parecen igual de urgentes y ninguno destaca.
Demasiado log es tan inútil como demasiado poco
Un diario que registra cada respiración es tan ilegible como uno en blanco — la señal que necesitas queda enterrada en un ruido que nadie puede cribar.
Los logs son tentadores de sobreusar, y registrar en exceso tiene un coste real: es caro de almacenar, lento de buscar, y entierra las líneas que importan bajo el ruido. La habilidad está en registrar las cosas que de verdad querrás más tarde — decisiones, fallos, eventos clave — con suficiente detalle para ser útil y no tanto como para que la señal se ahogue. Registra con intención, no por reflejo.
Los logs son el diario detallado de lo que pasó. Hazlos estructurados para poder consultarlos, con level para poder filtrar, y centrados para que la señal no se pierda en el ruido.
Los logs te hablan de eventos individuales. Las metrics te hablan del todo, a lo largo del tiempo — los números que muestran, de un vistazo, si el sistema está sano o resbalando.
Una metric es un número a lo largo del tiempo
Una gráfica de hospital siguiendo la frecuencia cardíaca durante la noche — no cada latido, solo el número muestreado de forma constante, para que una tendencia al alza salte a la vista.
Una metric es una medición registrada a lo largo del tiempo: peticiones por segundo, tasa de errores, tiempo de respuesta, memoria usada. A diferencia de un log, no trata de un solo evento — es el agregado, muestreado continuamente, para que veas tendencias y picos. Las metrics son baratas de recoger y almacenar porque son solo números, lo que significa que puedes guardarlas para todo, todo el tiempo, y observar cómo se mueve la forma de tu sistema.
Los counters suben; los gauges suben y bajan
Un cuentakilómetros solo trepa, contando el total de kilómetros recorridos; un velocímetro sube y baja según lo rápido que vas ahora mismo.
Dos formas básicas cubren la mayoría de las metrics. Un counter solo aumenta — total de peticiones servidas, total de errores — y observas su tasa de cambio. Un gauge sube y baja para mostrar un valor actual — memoria en uso, conexiones activas, longitud de cola. Saber cuál estás mirando te dice cómo leerlo: en un counter la pendiente es la historia; en un gauge lo es su altura actual.
Los dashboards hacen visibles las tendencias
Una pared de indicadores en una sala de control: de un vistazo el operador ve que todo está verde y estable, o que una aguja trepa hacia el rojo.
Las metrics suelen verse en un dashboard — gráficas de los números clave a lo largo del tiempo, una al lado de otra. Un buen dashboard te deja ver la salud del sistema en segundos y detectar el momento en que una línea se torció en el sentido equivocado. Aquí es donde las metrics se ganan su sitio: no en ningún valor aislado, sino en la tendencia visible que dice «algo empezó a ir mal a las 2 de la tarde» antes de que los usuarios terminen de quejarse.
Los four golden signals
El chequeo rápido de signos vitales de un médico — pulso, temperatura, presión arterial, respiración — un conjunto diminuto que capta casi todo lo que va mal sin medirlo todo.
No necesitas mil metrics para empezar. Los four golden signals cubren la mayor parte de la salud de un sistema: latency (cuánto tardan las peticiones), traffic (cuánta demanda hay), errors (cuántas peticiones fallan) y saturation (cómo de llenos están tus recursos). Vigila estos cuatro y captarás temprano la gran mayoría de los problemas. Son los signos vitales de un servicio — las primeras agujas que poner en el panel.
Las metrics son números a lo largo del tiempo — counters que trepan, gauges que oscilan — mostrados en dashboards. Empieza con los four golden signals: latency, traffic, errors, saturation.
En un sistema de muchos servicios, una petición de usuario toca a muchos de ellos. Un trace sigue esa única petición de principio a fin — respondiendo la pregunta que los logs y las metrics no pueden: ¿dónde, en todo el conjunto, ocurrió el tiempo o el fallo?
Un trace sigue una petición a través de los servicios
El historial de seguimiento de un paquete: recogido aquí, clasificado allá, transportado en avión, entregado — el viaje completo de un paquete por cada mano que lo tocó.
En los sistemas modernos una sola petición salta por muchos servicios — el gateway llama al servicio de pedidos, que llama a pagos, que llama a una base de datos. Un trace registra ese viaje entero para una petición, cosido de modo que puedas ver cada salto que dio. Responde una pregunta que ni los logs ni las metrics pueden: no «qué pasó» ni «cuánto», sino «¿cuál fue el camino de esta petición concreta a través de todo el sistema?».
Los spans muestran adónde se fue el tiempo
Un itinerario de viaje desglosado en tramos, cada uno con su propia duración — y al instante ves que la escala de tres horas, no los vuelos, se comió el día.
Un trace está hecho de spans — uno por paso, cada uno midiendo cuánto tardó esa pieza. Dispuestos como una cascada, los spans muestran exactamente dónde gastó su tiempo una petición lenta: el span de la base de datos tardó 900ms mientras todo lo demás tardó 50. Sin esto, «la petición fue lenta» es un misterio repartido entre muchos servicios; con esto, apuntas directo al culpable. Los spans convierten una lentitud vaga en una ubicación precisa.
El tracing es cómo se depuran los sistemas distribuidos
Seguir un único testigo caído hacia atrás a lo largo de una carrera de relevos para encontrar exactamente qué entrega falló — imposible de ver solo desde el resultado final.
Cuando una petición falla o se arrastra y el trabajo está repartido entre servicios, un trace suele ser la única manera de encontrar dónde. Las metrics te dicen que el sistema está lento; los logs te dicen qué dijo cada servicio; el trace ata el camino de una petición y apunta al servicio y al paso exactos que se rompieron. Para cualquier cosa distribuida, el tracing es la herramienta que convierte «en algún punto de ahí salió mal» en «justo aquí».
Un trace sigue una petición a través de cada servicio, desglosado en spans cronometrados — para que puedas ver exactamente dónde, en un sistema distribuido, ocurrió en realidad el tiempo o el fallo.
A los logs, las metrics y los traces se les llama los tres pilares de la observability porque cada uno responde una pregunta distinta. La fuerza está en usarlos juntos, no en elegir uno.
Cada pilar responde una pregunta distinta
Investigar un problema con tres herramientas: una gráfica que muestra cuándo cambiaron las cosas, un mapa que muestra dónde, y un informe detallado que muestra exactamente qué — cada uno inútil por separado, decisivos juntos.
Los tres pilares reparten el trabajo. Las metrics responden «¿está algo mal, y cuál es la tendencia?» — la visión general barata y siempre activa. Los traces responden «¿dónde, entre todos los servicios, está el problema?» — estrechándolo a un paso. Los logs responden «¿qué exactamente pasó ahí?» — el detalle completo en la escena. Ninguno por sí solo basta; cada uno retoma donde los otros se detienen.
El flujo natural: notar, localizar, explicar
Un médico ve una fiebre en la gráfica, examina para hallar qué órgano, y luego hace la prueba específica que nombra la enfermedad — señal amplia, después estrecha, después exacta.
En la práctica los recorres en orden. Una metric o alerta te dice que algo está mal (la tasa de errores se disparó). Un trace te muestra dónde (el paso del servicio de pagos está fallando). Un log en ese punto te dice exactamente qué (el proveedor de pagos devolvió un timeout). De amplio a estrecho a exacto: la metric nota, el trace localiza, el log explica. Conocer este flujo es la mayor parte de saber cómo depurar producción.
La correlación los ata entre sí
Un número de caso escrito en cada documento, foto e informe — para que un investigador pueda reunir todo lo de un incidente en lugar de buscar en cada montón por separado.
Los pilares son mucho más fuertes cuando están enlazados. Adjuntar un request ID compartido (o trace ID) a las metrics, al trace y a cada línea de log de una petición te deja saltar de «esta petición falló» directo a su trace y a sus logs exactos. Sin correlación tienes tres pajares separados; con ella, un solo tirón reúne la historia entera de un incidente. Los enlaces entre los pilares son lo que los convierte en un sistema y no en tres herramientas.
Las metrics notan, los traces localizan, los logs explican — de amplio a estrecho a exacto. Correlaciónalos con request IDs compartidos y tres herramientas se vuelven una sola historia de qué salió mal.
La observability te deja investigar; el alerting te dice cuándo empezar. Lo difícil no es detectar problemas — es decidir cuáles merecen despertar a un humano.
Alerta sobre lo que los usuarios sienten
Una alarma de humo debería saltar por un incendio de verdad, no cada vez que alguien tuesta pan — o la gente arranca la pila y se pierde el real.
Un alert es una notificación automática cuando algo cruza una línea. El arte está en alertar sobre los síntomas que los usuarios sienten de verdad — checkouts que fallan, el sitio lento — no sobre cada tic interno. Un servidor al 80% de memoria no es un problema si los usuarios están bien; un pico de pedidos fallidos sí lo es, aunque cada servidor parezca sano. Alerta sobre el resultado que da la cara al usuario, y avisarás a humanos por cosas que de verdad importan.
SLI, SLO, SLA: definir lo suficientemente bueno
Una empresa de mensajería que promete «el 99% de los paquetes llega en dos días» — un listón claro y medible de lo que cuenta como servicio aceptable, acordado de antemano.
Tres siglas formalizan «cómo de bueno es suficientemente bueno». Un SLI es la medición (el porcentaje de peticiones servidas en menos de 300ms). Un SLO es el objetivo que le fijas (debería ser el 99,9%). Un SLA es una promesa contractual a un cliente, con consecuencias si se incumple. Fijar un SLO explícito convierte la fiabilidad de una sensación vaga en un número al que puedes obligar al sistema — y una línea clara de cuándo actuar.
La alert fatigue es el asesino silencioso
Un coche que pita constantemente por nimiedades entrena al conductor a ignorar todos los pitidos — así que el único aviso que importaba se descarta junto con el resto.
Demasiadas alertas son un fallo en sí mismo: cuando se avisa a la gente por cosas que no importan, empiezan a ignorar las alertas por completo, y la de verdad se pierde en el ruido — alert fatigue. Cada alerta debería ser accionable y digna de la atención de un humano ahora mismo; si no lo es, su sitio es un dashboard, no un pager. Pocas alertas afiladas le ganan a una avalancha, porque una alerta en la que nadie confía es peor que ninguna alerta.
Alerta sobre los síntomas que los usuarios sienten, define «lo suficientemente bueno» con un SLO, y protégete de la alert fatigue — porque una alerta en la que nadie confía es peor que ninguna.
La observability se construye dentro, no se atornilla encima. La habilidad está en instrumentar a medida que avanzas, mantener la señal limpia, y gastar tu atención en las pocas cosas que más revelan.
Instrumenta mientras construyes, no tras el incendio
Cablear los detectores de humo mientras construyes la casa — no quedarte de pie entre el humo deseando haberlo hecho.
El peor momento para añadir observability es durante una caída, cuando descubres que el sistema no te dice nada. Así que lo construyes dentro a medida que avanzas: emite una metric para la nueva funcionalidad, registra sus decisiones clave, asegúrate de que una petición pueda trazarse a través de ella. Un poco de instrumentación añadida mientras el código está fresco te ahorra horas de adivinanza a ciegas más tarde. Trata «¿cómo veré esto en producción?» como parte de construirlo, no como una idea de última hora.
Empieza con los golden signals y crece
El dueño de una tienda nueva primero vigila los pocos números que importan — ventas, afluencia, quejas — y añade un seguimiento más fino solo a medida que surgen preguntas concretas.
No necesitas cobertura total en el primer día. Empieza con los four golden signals y un puñado de logs en puntos de decisión clave, luego añade detalle donde los incidentes reales te muestren un punto ciego. Cada caída es una lección sobre lo que ojalá hubieras estado registrando — así que deja que tu observability crezca siguiendo los contornos de donde el sistema de verdad te sorprende, en lugar de instrumentarlo todo de antemano.
- Qué puede decirme en producción — ¿o es una black box cuando se rompe? - Los golden signals — ¿estoy siguiendo latency, traffic, errors y saturation? - Logs — ¿estructurados, con level, y centrados en las decisiones y fallos que importan? - Tracing — ¿puedo seguir una petición a través de los servicios que toca? - Correlación — ¿comparten las metrics, los logs y los traces un request ID? - Alertas y un SLO — ¿aviso por lo que los usuarios sienten, contra un objetivo definido?
- observability / monitoring — responder preguntas imprevistas, frente a vigilar las conocidas. - log / structured / level — el diario detallado, hecho consultable y filtrable. - metric / counter / gauge / dashboard — números a lo largo del tiempo, las dos formas, y cómo los ves. - trace / span — el camino de una petición a través de los servicios, desglosado en pasos cronometrados. - the four golden signals — latency, traffic, errors, saturation. - alert / SLI / SLO / SLA — la notificación, la medida, el objetivo, la promesa. - alert fatigue / correlación (request ID) — la trampa del ruido, y el hilo que lo ata todo.
- Cuando algo se rompe, el sistema te dice dónde mirar en lugar de dejarte adivinando. - Recorres metric → trace → log para pasar de notar a localizar a explicar. - Un request ID compartido ata entre sí las señales de un incidente. - Tus alertas saltan por síntomas que dan la cara al usuario y la gente aún confía en ellas. - Tienes SLOs explícitos, e instrumentaste mientras construías, no durante la caída.
La buena observability se construye dentro: golden signals desde el principio, structured logs, peticiones trazables, correlacionadas por ID, y unas pocas alertas fiables contra un SLO real.