El mapa: 22 conceptos en siete grupos

Un mapa de metro: primero ves el conjunto de todas las líneas, luego recorres estación por estación.

Primero vienen tres fundamentos — por qué en producción vuelas por instrumentos, en qué se diferencia el monitoring de la observability y qué es una black box. Luego seis grupos, uno por capítulo: logs, metrics, traces, cómo trabajan los tres pilares juntos, alerting y cómo usarla bien.

Cada concepto de abajo sigue la misma forma: su nombre en inglés (apréndelo — es el término), una imagen de la vida, un diagrama y una ficha con campos: problema, idea, ejemplo, coste u ojo, cuándo usarlo y relaciones.

Flying by Instruments — 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.

Monitoring vs Observability — preguntas conocidas y 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 (a menudo escrita o11y) 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.

Black Box — 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.

Log — el diario del sistema

El cuaderno de bitácora de un barco: entradas con fecha y hora que anotan qué pasó y cuándo — «10:42, entramos al puerto» — para que cualquiera pueda reconstruir el viaje después.

Un log es un registro con fecha y hora de un evento: «el usuario 42 inició sesión», «el pago falló: tarjeta rechazada», «empezó a procesarse el pedido 91». Cada línea es una nota pequeña y detallada sobre algo que ocurrió, escrita mientras corre el código.

Los logs son la señal más rica porque llevan detalles — qué exactamente, cuándo exactamente, con los datos adjuntos. Cuando necesitas saber qué pasó de verdad en un caso concreto, miras los logs.

Structured Logging — logs en los que se puede buscar

La diferencia entre una caja de zapatos con 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 cada pago fallido de más de 500 ms hoy».

Esto convierte los logs de un muro de texto por el que haces scroll en una base de datos que puedes interrogar. La estructura es lo que hace usables los logs a escala de producción.

Log Levels — separar la señal del ruido

Un diario donde las entradas rutinarias van a lápiz y las emergencias en tinta roja — así, en una crisis, vas directo a lo rojo e ignoras el resto.

Cada log tiene un nivel que marca su importancia: DEBUG e INFO para detalle rutinario, WARN para algo raro, ERROR para un fallo real. Los niveles 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 niveles mantienen localizables las líneas importantes; ignorados, todos los logs parecen igual de urgentes y ninguno destaca.

Log Volume — demasiado log es tan inútil como muy poco

Un diario que anota cada respiración es tan ilegible como uno en blanco — la señal que necesitas queda enterrada en un ruido que nadie puede cribar.

Es tentador abusar de los logs, y el over-logging 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 lo que de verdad querrás más tarde — decisiones, fallos, eventos clave — con detalle suficiente para ser útil y no tanto como para ahogar la señal. Registra con intención, no por reflejo.

Metric — un número a lo largo del tiempo

La gráfica de un hospital que sigue el pulso durante la noche — no cada latido, solo el número muestreado de forma constante, así que una tendencia al alza salta a la vista.

Una metric es una medición seguida en el tiempo: solicitudes por segundo, tasa de errores, tiempo de respuesta, memoria usada. A diferencia de un log, no trata de un evento — es el agregado, muestreado de forma continua, así que ves tendencias y picos.

Las metrics son baratas de recolectar y guardar porque son solo números, lo que significa que puedes tenerlas para todo, todo el tiempo, y ver moverse la forma de tu sistema.

Counter vs Gauge — los counters suben, los gauges oscilan

Un cuentakilómetros solo sube, 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 solicitudes atendidas, total de errores — y lo que observas es su ritmo de cambio. Un gauge sube y baja para mostrar un valor actual — memoria en uso, conexiones activas, longitud de la cola.

Saber cuál tienes delante te dice cómo leerla: en un counter lo que cuenta es la pendiente; en un gauge, su altura actual.

Dashboard — hacer visibles las tendencias

Una pared de indicadores en una sala de control: de un vistazo el operador ve que todo está en verde y estable, o que una aguja sube hacia el rojo.

Las metrics suelen verse en un dashboard — gráficas de los números clave a lo largo del tiempo, una junto a otra. Un buen dashboard te deja ver la salud del sistema en segundos y notar el momento en que una línea se torció.

Aquí las metrics se ganan el pan: no en un valor suelto, 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.

Four Golden Signals — las constantes vitales de un servicio

La revisión rápida de constantes vitales de un médico — pulso, temperatura, presión arterial, respiración — un conjunto diminuto que detecta casi todo lo que anda 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 solicitudes), traffic (cuánta demanda hay), errors (cuántas solicitudes fallan) y saturation (qué tan llenos están tus recursos).

Vigila estos cuatro y atraparás pronto la gran mayoría de los problemas. Son las constantes vitales de un servicio — las primeras agujas que poner en el panel.

Trace — el camino de una solicitud entre servicios

El historial de seguimiento de un paquete: recogido aquí, clasificado allá, enviado por avión, entregado — el viaje completo de un paquete por todas las manos que lo tocaron.

En los sistemas modernos una sola solicitud 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 de una solicitud, cosido para que veas cada salto que dio.

Responde algo que ni los logs ni las metrics pueden: no «qué pasó» ni «cuánto», sino «¿cuál fue el camino de esta solicitud concreta por todo el sistema?»

Span — dónde se fue el tiempo

Un itinerario de viaje dividido en tramos, cada uno con su duración — y de inmediato ves que la escala de tres horas, no los vuelos, se comió el día.

Un trace se compone de spans — uno por paso, cada uno midiendo cuánto tardó esa pieza. Dispuestos como una cascada (waterfall), los spans muestran exactamente dónde pasó su tiempo una solicitud lenta: el span de la base de datos tardó 900 ms mientras todo lo demás tardó 50.

Sin esto, «la solicitud fue lenta» es un misterio repartido entre muchos servicios; con esto, señalas directo al culpable. Los spans convierten una lentitud vaga en una ubicación precisa.

Distributed Tracing — cómo se depuran los sistemas distribuidos

Seguir un solo testigo caído hasta atrás en una carrera de relevos para encontrar exactamente qué traspaso falló — imposible de ver solo con el resultado final.

Cuando una solicitud falla o se arrastra y el trabajo está repartido entre servicios, un trace suele ser la única forma de encontrar dónde. Eso es el distributed tracing.

Las metrics te dicen que el sistema está lento; los logs te dicen lo que dijo cada servicio; el trace une el camino de una solicitud y señala el servicio y el paso exactos que fallaron. Para cualquier cosa distribuida, el tracing es la herramienta que convierte «en algún punto de ahí salió mal» en «justo aquí».

Three Pillars — cada uno 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é — inútiles por separado, decisivas juntas.

Los tres pilares de la observability se reparten el trabajo. Las metrics responden «¿hay algo mal y cuál es la tendencia?» — el panorama barato y siempre activo. Los traces responden «¿dónde, entre todos los servicios, está el problema?» — lo acotan a un paso. Los logs responden «¿qué exactamente pasó ahí?» — el detalle completo en la escena.

Ninguno basta por sí solo; cada uno recoge donde los demás se detienen.

Notice → Locate → Explain — el flujo natural

Un médico ve fiebre en la gráfica, explora para hallar qué órgano, y luego pide la prueba específica que nombra la enfermedad — señal amplia, luego estrecha, luego exacta.

En la práctica los recorres en orden. Una metric o alerta te dice que algo va mal (la tasa de errores saltó). 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 lo amplio a lo estrecho y a lo exacto: la metric nota, el trace localiza, el log explica. Conocer este flujo es casi todo lo que hay que saber para depurar producción.

Correlation ID — el hilo que lo une todo

Un número de caso escrito en cada documento, foto e informe — para que un investigador pueda reunir todo sobre un incidente en vez de buscar en cada montón por separado.

Los pilares son mucho más fuertes cuando están enlazados. Adjuntar un request ID (o trace ID) compartido a las metrics, al trace y a cada línea de log de una solicitud te deja saltar de «esta solicitud falló» directo a su trace y a sus logs exactos. Eso es la correlation.

Sin correlation tienes tres pajares separados; con ella, un solo tirón reúne la historia completa de un incidente. Los enlaces entre los pilares son lo que los hace un sistema y no tres herramientas.

Symptom-based Alerting — alerta sobre lo que sienten los usuarios

Una alarma de humo debe sonar ante un incendio de verdad, no cada vez que alguien hace una tostada — o la gente le arranca la pila y se pierde la alarma real.

Una alerta es una notificación automática cuando algo cruza una línea. El arte está en alertar sobre los síntomas que los usuarios realmente sienten — checkouts que fallan, el sitio lento — no sobre cada espasmo 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 todos los servidores parezcan sanos. Alerta sobre el resultado de cara al usuario y despertarás a las personas solo por lo que de verdad importa.

SLI / SLO / SLA — definir qué es suficientemente bueno

Una empresa de reparto que promete «el 99 % de los paquetes llega en dos días» — una vara clara y medible de lo que cuenta como servicio aceptable, acordada de antemano.

Tres siglas formalizan «qué tan bueno es suficientemente bueno». Un SLI (service level indicator) es la medición (el porcentaje de solicitudes atendidas en menos de 300 ms). Un SLO (service level objective) es la meta que fijas para él (debería ser 99,9 %). Un SLA (service level agreement) 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 exigirle al sistema — y en una línea clara de cuándo actuar.

Alert Fatigue — el asesino silencioso

Un coche que pita sin parar por tonterías enseña al conductor a ignorar todos los pitidos — y la única advertencia que importaba se descarta con el resto.

Demasiadas alertas es un fallo en sí mismo: cuando avisan a la gente por cosas que no importan, empiezan a ignorar las alertas por completo, y la real se pierde en el ruido — eso es la alert fatigue.

Cada alerta debe ser accionable y merecer la atención de una persona ahora mismo; si no, su sitio es un dashboard, no un pager. Menos alertas, más afiladas, ganan a una avalancha, porque una alerta en la que nadie confía es peor que ninguna.

Instrument as You Build — no después del incendio

Instalar los detectores de humo mientras construyes la casa — no estar 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 incorporas la instrumentación sobre la marcha: emite una metric para la función nueva, registra sus decisiones clave, asegúrate de que una solicitud pueda trazarse a través de ella.

Un poco de instrumentación añadida mientras el código está fresco ahorra horas de adivinar a ciegas más tarde. Trata «¿cómo voy a ver esto en producción?» como parte de construirlo, no como una ocurrencia tardía.

Start Small and Grow — empieza por los golden signals

El dueño de una tienda nueva vigila primero los pocos números que importan — ventas, visitas, quejas — y añade un seguimiento más fino solo cuando surgen preguntas concretas.

No necesitas cobertura total el primer día. Empieza con los four golden signals y un puñado de logs en los puntos clave de decisión, y luego añade detalle donde los incidentes reales te muestren un blind spot (punto ciego).

Cada caída es una lección sobre lo que desearías haber estado registrando — así que deja que tu observability crezca siguiendo los contornos de donde el sistema de verdad te sorprende, en vez de instrumentarlo todo de entrada.

Cómo se conectan los conceptos

Un panel de instrumentos de avión: una docena de indicadores, pero todos sobre un solo vuelo — y el piloto los lee juntos.

Todo en este curso es parte de un solo panel. Un sistema en marcha emite tres señales: las metrics notan, los traces localizan, los logs explican. Un correlation ID ata las tres a una solicitud. Las metrics y los golden signals alimentan los SLIs y SLOs, y estos mueven las alertas basadas en síntomas — pocas y afiladas, así que no hay alert fatigue. Y el panel mismo crece cuando instrumentas al construir y añades detalle tras los incidentes reales.