# Si no puedes verlo, no puedes arreglarlo Curso exprés sobre observability. 22 conceptos — Observability, Structured Logging, los Four Golden Signals, Trace y Span, Correlation ID, SLI/SLO/SLA, Alert Fatigue y más — cada uno con su nombre en inglés, un diagrama, una ficha y sus vínculos con los demás. Solo lo esencial: en producción no puedes adjuntar un debugger, así que construyes el sistema para que se explique a sí mismo. Al final, una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intermediate - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/es/learn/observability-express --- ## 1. Por qué observability 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. ### 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_. _Diagram: Arriba, los fundamentos; abajo, seis grupos — los capítulos 2–7 los siguen._ ### 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. _Diagram: En un portátil miras por dentro con un debugger. En producción solo ves lo que el sistema emite: logs, metrics, traces._ #### Flying by Instruments (producción, trabajar con señales) - **Problema:** No puedes pausar la producción en vivo ni inspeccionarla con un debugger. - **Idea:** Enterarte de lo que pasa solo por las señales que el sistema emite mientras corre. - **Ejemplo:** En vez de un breakpoint en el código de pagos — una metric de errores, un trace de la solicitud y una línea de log. - **Consecuencia:** Los instrumentos tienen que estar en el panel de antemano, no añadirse durante la caída. - **Relaciones:** Los instrumentos son los tres pilares: **logs**, **metrics**, **traces**. ### 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. _Diagram: El monitoring responde preguntas preparadas de antemano. La observability te deja cortar datos ricos para una pregunta que ayer no existía._ #### Observability (o11y (frente al monitoring)) - **Problema:** Los dashboards y las alertas atrapan solo los fallos que previste; las caídas reales suelen ser nuevas. - **Idea:** El sistema emite datos suficientes para responder una pregunta que nadie planeó. - **Ejemplo:** «¿Por qué los checkouts van lentos en Brasil desde las 2 de la tarde?» — cortas los datos por región, hora y endpoint. - **Monitoring:** Vigilar lo conocido. Hace falta, pero no basta. - **Relaciones:** Te permite investigar; el **alerting** te dice cuándo empezar. ### 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. _Diagram: Arriba: una black box — ante un error solo puedes adivinar y reiniciar. Abajo: el mismo servicio, pero emite logs, metrics y traces._ #### Black Box (un sistema opaco) - **Qué es:** Un sistema que casi no emite nada sobre sí mismo. - **Por qué duele:** Durante un incidente adivinas y reinicias mientras cada minuto cuesta dinero. - **Ejemplo:** El servicio se cae, los logs están vacíos, no hay metrics — ¿dónde mirar? - **Remedio:** Instrumentar el sistema mientras está en calma. - **Relaciones:** Se cura con la práctica **Instrument as You Build**. > **La pregunta de fondo:** «Cuando esto se rompa en producción a las 3 de la madrugada, ¿qué podrá decirme realmente el sistema — o me quedaré adivinando en la oscuridad?» > No puedes pausar la producción para inspeccionarla. La observability es construir el sistema para que se explique a sí mismo — y así responder preguntas que nunca previste, no solo vigilar las que sí. ## 2. Logs 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. ### 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. _Diagram: Un flujo de logs: fecha y hora, nivel, evento. Una línea es un evento._ #### Log (registro de evento) - **Qué es:** Un registro de un evento, con fecha y hora y detalles. - **Responde:** «¿Qué pasó exactamente en este caso concreto?» - **Ejemplo:** `10:42:09 ERROR payment failed: card declined` - **Ojo:** Es fácil pasarse — ruido, factura de almacenamiento, búsquedas lentas. - **Relaciones:** Se vuelve útil con el **structured logging** y los **log levels**; se une al trace mediante un **correlation ID**. ### 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. _Diagram: El mismo registro como texto libre y como datos con campos. Los campos son lo que puedes consultar._ #### Structured Logging (logs como datos) - **Problema:** El texto libre no se puede encontrar ni filtrar entre millones de líneas. - **Idea:** Escribir cada evento como datos: campos con nombre en vez de una frase. - **Ejemplo:** `user_id: 42`, `status: failed`, `duration_ms: 230` → «cada pago fallido de más de 500 ms hoy». - **Coste:** Hay que acordar los nombres de los campos y mantenerlos consistentes. - **Cuándo usarlo:** Siempre, en cuanto hay más logs de los que puedes recorrer con la vista. - **Relaciones:** Un campo `request_id` en cada línea es la base de un **correlation ID**. ### 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. _Diagram: Cuatro niveles por importancia. En marcha normal dejas INFO y superiores; al investigar activas también DEBUG._ #### Log Levels (DEBUG, INFO, WARN, ERROR) - **Qué es:** Una etiqueta de importancia en cada línea de log. - **Cómo funciona:** `DEBUG`/`INFO` — rutina, `WARN` — algo raro, `ERROR` — un fallo real. - **Ejemplo:** Durante un incidente filtras por `ERROR` y ves los fallos de inmediato. - **Ojo:** Si todo se registra como `ERROR`, nada destaca. - **Relaciones:** La perilla de volumen frente al **log volume**. ### 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. _Diagram: Muy pocos logs — vas a ciegas. Demasiados — ruido y una factura de almacenamiento. El valor está en el medio: decisiones, fallos, eventos clave._ #### Log Volume (over-logging) - **Qué es:** Registrar cada paso «por si acaso». - **Por qué duele:** Caro de almacenar, lento de buscar, y lo que importa se ahoga en el ruido. - **Ejemplo:** Un diario que anota cada respiración es tan inútil de leer como uno en blanco. - **Remedio:** Registrar con intención: decisiones, fallos, eventos clave. - **Relaciones:** Se controla con los **log levels**; la misma trampa de ruido que la **alert fatigue**. > **La pregunta de los logs:** «Cuando depure esto más adelante, ¿tendrán los logs el detalle que necesito — estructurados, con niveles y centrados en lo que importa en vez de enterrarlo?» > Los logs son el diario detallado de lo que pasó. Hazlos estructurados para poder consultarlos, con niveles para poder filtrarlos y enfocados para que la señal no se pierda en el ruido. ## 3. Metrics Los logs te hablan de eventos individuales. Las metrics te hablan del conjunto, a lo largo del tiempo — los números que muestran, de un vistazo, si el sistema está sano o se está deteriorando. ### 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. _Diagram: Una metric es una serie de puntos en el tiempo. Ves la tendencia y el pico, no una solicitud concreta._ #### Metric (serie temporal) - **Qué es:** Una medición numérica muestreada de forma constante en el tiempo. - **Responde:** «¿Algo va mal y cuál es la tendencia?» - **Ejemplo:** Solicitudes por segundo, tasa de errores, tiempo de respuesta, memoria. - **Ventaja:** Barata de recolectar y guardar — tenla para todo, todo el tiempo. - **Desventaja:** No sabe nada de los detalles de una solicitud — para eso, ve a los traces y los logs. - **Relaciones:** Viene como **counter** o **gauge**; se ve en un **dashboard**; es la base de un **SLI**. ### 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. _Diagram: Un counter es un cuentakilómetros: lee la pendiente (el ritmo). Un gauge es un velocímetro: lee el valor actual._ #### Counter vs Gauge (las dos formas de una metric) - **Counter:** Solo sube: total de solicitudes, total de errores. Lee su ritmo. - **Gauge:** Sube y baja: memoria, conexiones activas, longitud de la cola. Lee su valor actual. - **Ejemplo:** «10.400 errores en total» dice poco; «los errores por minuto se triplicaron» dice mucho. - **Ojo:** Leer un counter como un gauge — mirar la altura, no la pendiente. - **Relaciones:** Las dos formas de cualquier **metric**. ### 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. _Diagram: Cuatro gráficas una junto a otra: tres están planas, los errores se doblan hacia arriba a las 2 de la tarde — visible de un vistazo._ #### Dashboard (metrics de un vistazo) - **Qué es:** Gráficas de las metrics clave a lo largo del tiempo, una junto a otra. - **Por qué:** Ver la salud del sistema en segundos, y el momento en que una línea se dobló. - **Ejemplo:** Los errores empezaron a subir a las 2 de la tarde — visible antes de que lleguen las quejas. - **Ojo:** Un dashboard no despierta a nadie — alguien tiene que mirarlo. Lo urgente va a las **alertas**. - **Relaciones:** Muestra **metrics**; las primeras gráficas son los **four golden signals**. ### 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. _Diagram: Los cuatro golden signals alrededor de un servicio: latency, traffic, errors, saturation._ #### Four Golden Signals (latency, traffic, errors, saturation) - **Problema:** No está claro con qué metrics empezar, y mil metrics son ruido. - **Idea:** Cuatro números cubren la mayor parte de la salud de un sistema: latency, traffic, errors, saturation. - **Ejemplo:** Un servicio de pagos: tiempo de respuesta, solicitudes por segundo, proporción de fallos, uso del pool de conexiones. - **Cuándo usarlo:** Las primeras gráficas de cualquier servicio nuevo. - **Relaciones:** Van en un **dashboard**; de ellos se sacan los **SLIs**; el comienzo de **Start Small and Grow**. > **La pregunta de las metrics:** «¿Estoy siguiendo las constantes vitales — latency, traffic, errors, saturation — para ver el problema como una tendencia, antes de que se vuelva una caída?» > Las metrics son números a lo largo del tiempo — counters que suben, gauges que oscilan — mostrados en dashboards. Empieza con los four golden signals: latency, traffic, errors, saturation. ## 4. Traces En un sistema de muchos servicios, una solicitud de usuario toca muchos de ellos. Un trace sigue esa única solicitud de punta a punta — y responde lo que los logs y las metrics no pueden: ¿dónde, entre todo, se fue el tiempo o ocurrió el fallo? ### 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?» _Diagram: Un trace es una solicitud: usuario → gateway → pedidos → pagos → base de datos, cada salto cosido bajo un mismo ID._ #### Trace (camino de la solicitud) - **Qué es:** Un registro del camino completo de una solicitud por cada servicio. - **Responde:** «¿En qué punto del camino de esta solicitud está el problema?» - **Ejemplo:** Gateway → pedidos → pagos → base de datos, todo bajo un mismo trace ID. - **Coste:** Cada servicio tiene que pasar el ID, o el camino se rompe. - **Relaciones:** Se compone de **spans**; su ID es el **correlation ID**. ### 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. _Diagram: Una cascada de spans: de una solicitud de 950 ms, una sola consulta a la base de datos se comió 900 ms._ #### Span (un paso de un trace) - **Qué es:** Un paso medido dentro de un trace: inicio, fin, duración. - **Cómo funciona:** Los spans se anidan y se disponen en el tiempo como una cascada. - **Ejemplo:** El span de la base de datos tardó 900 ms, todo lo demás junto 50 ms. El culpable es obvio. - **Por qué:** Convierte «lento en algún sitio» en una ubicación precisa. - **Relaciones:** El bloque de construcción de un **trace**. ### 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í». _Diagram: Las metrics dicen «lento en algún sitio», los logs dicen lo que dijo cada servicio, y el trace señala el paso roto exacto._ #### Distributed Tracing (tracing entre servicios) - **Problema:** El trabajo está repartido entre servicios; el resultado final no muestra qué paso falló. - **Idea:** Seguir cada solicitud por todos los servicios como un solo trace. - **Ejemplo:** El checkout falla: el trace muestra que el paso del servicio de pagos es el que falla. - **Cuándo usarlo:** En cuanto una solicitud pasa por más de un servicio. - **Relaciones:** Se construye con **trace** y **span**; el segundo paso de **notice → locate → explain**. > **La pregunta de los traces:** «Cuando una solicitud es lenta o falla entre varios servicios, ¿puedo seguir su camino completo y ver exactamente qué paso tiene la culpa?» > Un trace sigue una solicitud por todos los servicios, dividida en spans medidos — para que veas exactamente dónde, en un sistema distribuido, se fue el tiempo o ocurrió el fallo. ## 5. Los tres pilares juntos Logs, metrics y traces se llaman los tres pilares de la observability porque cada uno responde una pregunta distinta. La fuerza está en usarlos juntos, no en elegir uno. ### 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. _Diagram: Tres pilares: metrics — hay un problema, traces — dónde, logs — qué exactamente. Juntos sostienen la observability._ #### Three Pillars of Observability (metrics, traces, logs) - **Problema:** Ninguna señal sola responde todas las preguntas de un incidente. - **Idea:** Metrics — «¿hay un problema?», traces — «¿dónde?», logs — «¿qué exactamente?». - **Ejemplo:** Solo metrics: sabes que va mal pero no dónde. Solo logs: te ahogas en detalle sin un mapa. - **Cuándo usarlo:** Para cada servicio en producción. - **Relaciones:** Se recorren en orden como **notice → locate → explain**; unidos por un **correlation ID**. ### 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. _Diagram: El embudo de la investigación: la metric nota, el trace localiza, el log explica._ #### Notice → Locate → Explain (metric → trace → log) - **Problema:** En un incidente no está claro con qué señal empezar. - **Idea:** Ir de lo amplio a lo exacto: metric, luego trace, luego log. - **Ejemplo:** La tasa de errores saltó → trace: el paso de pagos está fallando → log: el proveedor devolvió un timeout. - **Ojo:** Empezar con un grep por los logs — buscar una aguja sin mapa. - **Relaciones:** Es rápido solo cuando las señales están unidas por un **correlation ID**. ### 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. _Diagram: Un solo request_id en la metric, el trace y los logs de cada servicio — la historia completa de una solicitud en un paso._ #### Correlation ID (request ID, trace ID) - **Problema:** Metrics, traces y logs están en tres pajares separados. - **Idea:** Un ID compartido por solicitud — en el trace y en cada línea de log. - **Ejemplo:** Buscas `request_id=abc123` y obtienes el trace más los logs del gateway y de pagos de esa solicitud. - **Coste:** El ID tiene que pasar por cada servicio y escribirse en cada log. - **Relaciones:** Pega los **three pillars**; lo más fácil es llevarlo como un campo en el **structured logging**. > **La pregunta de los pilares:** «¿Puedo pasar de una metric que nota un problema, a un trace que lo localiza, a los logs que lo explican — con IDs compartidos que atan los tres a la misma solicitud?» > Las metrics notan, los traces localizan, los logs explican — de lo amplio a lo estrecho y a lo exacto. Correlaciónalos con request IDs compartidos y tres herramientas se vuelven una sola historia de lo que salió mal. ## 6. Alerting y SLOs 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 una persona. ### 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. _Diagram: Una señal interna que no perjudica a los usuarios va a un dashboard. Un síntoma que los usuarios sienten vale despertar a una persona._ #### Symptom-based Alerting (alertar sobre síntomas de cara al usuario) - **Problema:** Alertar sobre cada espasmo interno despierta a la gente por cosas que no importan. - **Idea:** Avisar solo por resultados que los usuarios realmente sienten. - **Ejemplo:** 80 % de memoria con usuarios contentos — sin alerta. Un pico de pedidos fallidos — alerta, aunque los servidores se vean en verde. - **Cuándo usarlo:** Para todo lo que envía una notificación a una persona. - **Relaciones:** La línea la fija un **SLO**; te salva de la **alert fatigue**. ### 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. _Diagram: SLI — lo que mides, SLO — la meta, SLA — lo que el contrato promete al cliente._ #### SLI / SLO / SLA (indicador, objetivo, acuerdo) - **SLI:** La medición: proporción de solicitudes atendidas en menos de 300 ms. - **SLO:** La meta para el SLI: debería ser 99,9 %. - **SLA:** Una promesa contractual a un cliente, con consecuencias si se incumple. - **Por qué:** «Suficientemente fiable» se vuelve un número — y una línea clara de cuándo actuar. - **Relaciones:** Los SLIs se construyen con **metrics** y los **golden signals**; el SLO es la línea para las **alertas**. ### 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. _Diagram: Una avalancha de alertas ruidosas enseña a todos a ignorarlas todas — y la real se ahoga. Unas pocas alertas afiladas conservan la confianza._ #### Alert Fatigue (ruido del pager) - **Qué es:** La gente deja de reaccionar a las alertas porque son demasiadas. - **Por qué duele:** La alerta real se ignora junto con el ruido. - **Ejemplo:** El pager pita por tonterías cada hora — nadie se levanta por la que importa. - **Remedio:** Cada alerta accionable y urgente; todo lo demás va a un dashboard. - **Relaciones:** Se cura con el **symptom-based alerting** y los SLOs; prima del **log volume**. > **La pregunta del alerting:** «¿Esta alerta salta por algo que un usuario realmente siente y que una persona debe atender ya — o es ruido que enseñará a todos a ignorar el pager?» > Alerta sobre los síntomas que sienten los usuarios, define «suficientemente bueno» con un SLO y cuídate de la alert fatigue — porque una alerta en la que nadie confía es peor que ninguna. ## 7. Usarla bien La observability se construye desde dentro, no se pega después. La habilidad está en instrumentar sobre la marcha, mantener limpia la señal y gastar tu atención en las pocas cosas que más revelan. ### 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. _Diagram: Arriba: señales incorporadas al construir — el incidente se responde solo. Abajo: sin señales — durante el incidente te quedas adivinando._ #### Instrument as You Build (incorporada, no pegada después) - **Problema:** Descubres los huecos en tus señales durante la caída — demasiado tarde. - **Idea:** Una metric, logs clave y tracing son parte de cada función nueva. - **Ejemplo:** Una función nueva de pagos sale con una metric de errores, registra sus decisiones y pasa el trace ID adelante. - **Coste:** Un poco de trabajo mientras el código está fresco — en vez de horas de adivinar después. - **Relaciones:** El antídoto de una **black box**. ### 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. _Diagram: Empieza con los golden signals y luego repite el ciclo: un incidente muestra un punto ciego → añades detalle → la cobertura crece._ #### Start Small and Grow (hacer crecer la cobertura con los incidentes) - **Problema:** Instrumentarlo todo de entrada es lento, caro y ruidoso. - **Idea:** Empezar con los golden signals; añadir detalle donde un fallo real te sorprendió. - **Ejemplo:** Un incidente mostró que los timeouts del proveedor eran invisibles — añades una metric y un log justo ahí. - **Cuándo usarlo:** Desde el primer día de cualquier servicio. - **Relaciones:** Parte de los **four golden signals**; mantiene a raya el **log volume**. ### 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. _Diagram: El sistema emite tres señales; el flujo es metric → trace → log; un correlation ID las pega; las metrics alimentan los SLOs y las alertas._ #### Antes de lanzar un servicio - **¿Qué puede decirme** en producción — o es una black box cuando se rompe? - **Los golden signals** — ¿sigo latency, traffic, errors y saturation? - **Logs** — ¿estructurados, con niveles y centrados en las decisiones y fallos que importan? - **Tracing** — ¿puedo seguir una solicitud por los servicios que toca? - **Correlation** — ¿comparten un request ID las metrics, los logs y los traces? - **Alertas y un SLO** — ¿aviso por lo que sienten los usuarios, frente a una meta definida? #### Señales de que observas bien - Cuando algo se rompe, el sistema **te dice dónde mirar** en vez de dejarte adivinando. - Vas **metric → trace → log** para pasar de notar a localizar y a explicar. - Un **request ID** compartido une las señales de un incidente. - Tus **alertas** saltan por síntomas de cara al usuario y la gente aún confía en ellas. - Tienes **SLOs** explícitos, e instrumentaste **al construir**, no durante la caída. ## Hoja de referencia: los 22 conceptos ### Fundamentos - **Flying by Instruments** (producción): No puedes pausar la producción — solo ves lo que el sistema emite. - **Observability** (o11y): Responder preguntas imprevistas con los datos del sistema. El monitoring vigila lo conocido. - **Black Box** (sistema opaco): Un sistema que no emite nada: ante un fallo, solo puedes adivinar. ### Logs - **Log** (registro de evento): Un registro de un evento con fecha y hora. Responde «qué pasó exactamente». - **Structured Logging** (logs como datos): Eventos como campos de datos — logs que puedes consultar. - **Log Levels** (DEBUG · INFO · WARN · ERROR): Una etiqueta de importancia: volumen arriba para investigar, abajo en marcha normal. - **Log Volume** (over-logging): Demasiados logs son ruido y una factura. Registra con intención. ### Metrics - **Metric** (serie temporal): Un número a lo largo del tiempo. Barata, siempre activa, muestra la tendencia. - **Counter vs Gauge** (las dos formas): Un counter solo sube (lee la pendiente); un gauge oscila (lee el valor). - **Dashboard** (metrics de un vistazo): Metrics clave una junto a otra: la salud en segundos. - **Four Golden Signals** (constantes vitales): Latency, traffic, errors, saturation — las constantes vitales de un servicio. ### Traces - **Trace** (camino de la solicitud): El camino de una solicitud por todos los servicios. Responde «dónde». - **Span** (paso medido): Un paso medido de un trace; la cascada de spans muestra dónde se fue el tiempo. - **Distributed Tracing** (tracing entre servicios): Depurar un sistema distribuido: «en algún sitio» se vuelve «justo aquí». ### Juntos - **Three Pillars** (metrics, traces, logs): Metrics — hay un problema, traces — dónde, logs — qué exactamente. - **Notice → Locate → Explain** (metric → trace → log): El flujo de la investigación, de lo amplio a lo exacto. - **Correlation ID** (request ID, trace ID): Un ID en todas las señales de una solicitud — la historia completa en un paso. ### Alerting - **Symptom-based Alerting** (avisar por el dolor del usuario): Despierta a la gente por lo que sienten los usuarios, no por espasmos internos. - **SLI / SLO / SLA** (medir, meta, promesa): La medición, la meta para ella y la promesa contractual a un cliente. - **Alert Fatigue** (ruido del pager): Demasiadas alertas y nadie escucha. Menos y más afiladas. ### Usarla bien - **Instrument as You Build** (incorporada, no pegada después): Las señales son parte de construir una función, no una reacción a un incendio. - **Start Small and Grow** (crecer con los incidentes): Empieza con los golden signals; añade detalle donde un fallo real te sorprendió. > Una buena observability se construye desde dentro: golden signals desde el principio, logs estructurados, solicitudes trazables, correlacionadas por ID, y unas pocas alertas confiables frente a un SLO real. Fin del curso exprés · 7 capítulos · 22 conceptos Ahora toca practicar: toma un servicio y añade los cuatro golden signals a un dashboard, pon una línea de log estructurado en sus decisiones clave y asegúrate de que una solicitud lleve un ID que puedas seguir. Luego rómpelo a propósito e intenta diagnosticarlo usando solo lo que emite. El valor llega en el instante en que arreglas algo solo con las señales, sin adjuntar nunca un debugger. Pero quédate con una idea por encima de las demás: en producción vuelas por instrumentos. Construye el sistema para que se explique a sí mismo — logs para el qué, metrics para el cuánto, traces para el dónde — y una caída a las 3 de la madrugada se vuelve una pregunta que puedes responder en vez de un misterio que adivinas.