Módulo 3: Observability As Sli Input
2. Los tres pilares, con el lente de SRE
Descripción
Métricas, logs y trazas son, casi con seguridad, tres palabras que ya escuchaste antes de esta guía —son, literalmente, "los tres pilares de la observabilidad", una frase repetida en casi cualquier conferencia técnica de la última década—. Esta lección no las presenta como conceptos nuevos. Las presenta con una restricción específica que la mayoría de esas conferencias no aplica: cada una, vista únicamente a través de la pregunta que este módulo existe para contestar —¿el SLI de process-shipment-manifest se está cumpliendo?. Esa restricción cambia qué de cada pilar importa y qué no, y es exactamente el lente que separa este módulo de un curso general de observabilidad.
Conexión con el módulo
La lección 1 prometió esta analogía; esta lección la desarrolla completa, y las lecciones 3, 4 y 5 la ejecutan de verdad, pilar por pilar, sobre el mismo batch fijo de 20 invocaciones que ya conoces del mapa del módulo. Todo lo que sigue en este módulo es una instancia concreta de la distinción que esta lección establece.
Analogía: tres formas de investigar por qué un tren llegó tarde
Un tren de pasajeros llega 40 minutos tarde a su destino. La empresa ferroviaria necesita saber qué pasó, y tiene tres fuentes de información completamente distintas, cada una útil para una pregunta distinta.
El tablero de puntualidad muestra, para cada tren de la red, la hora programada de llegada, la hora real, y la diferencia —un número por tren, agregado sobre toda la operación del día—. Con ese tablero, alguien puede contestar rápido: "¿cuántos trenes llegaron tarde hoy? ¿cuál es el porcentaje de puntualidad de la red esta semana?". Lo que el tablero no puede contestar es por qué un tren específico llegó tarde —solo dice que llegó tarde, y por cuánto—.
La bitácora del maquinista es el registro escrito, tren por tren, de cada evento relevante durante el viaje: "14:02 — parada no programada en el km 340 por señal roja", "14:15 — reanudada la marcha", "14:40 — velocidad reducida por obras en la vía". Con esa bitácora, alguien puede contestar la pregunta que el tablero dejó abierta: este tren específico llegó tarde por dos razones documentadas, con hora exacta cada una. La bitácora tiene el detalle que el tablero nunca tuvo —pero solo sirve si ya sabes de qué tren específico quieres la historia.
Seguir un vagón específico por toda la ruta —con una persona o un sensor dedicado a un solo vagón desde el origen hasta el destino— es la tercera forma, la más costosa y la más rara vez necesaria: no solo saber que hubo una parada no programada, sino ver exactamente en qué punto de la ruta, dentro de qué tramo, con qué otro vagón acoplado, ocurrió cada evento —una vista de extremo a extremo de un caso individual, útil cuando la bitácora sola no alcanza para entender la secuencia completa de un incidente específico—.
Estas tres formas de investigar son, exactamente, métricas, logs y trazas —y la razón por la que ninguna reemplaza a las otras dos es la misma razón por la que una empresa ferroviaria seria necesita las tres.
Métricas: el tablero de puntualidad de process-shipment-manifest
Una métrica es un número agregado sobre una ventana de tiempo —un conteo, una suma, un promedio— sin el detalle de ningún evento individual. AWS/Lambda/Invocations y AWS/Lambda/Errors, las dos métricas que la lección 3 va a leer con awslocal cloudwatch get-metric-statistics, son exactamente esto: cuántas invocaciones hubo en una ventana, cuántas de esas terminaron en error. Nada más, y nada menos.
La pregunta que contesta, cuando la pregunta central es "¿mi SLI se cumple?": las métricas son, literalmente, las dos entradas de compute_sli() —total_valid viene de Invocations, y total_good se deriva de Invocations menos Errors—. Ninguna otra fuente de datos de este módulo alimenta la fórmula del SLI de forma tan directa. Si tuvieras que elegir un solo pilar para calcular el SLI mensual de SLO.md, sería este.
Lo que no contesta: por qué las 3 invocaciones fallaron. AWS/Lambda/Errors con Sum: 3.0 te dice que algo falló tres veces —no te dice si fue el mismo error tres veces, tres errores distintos, ni en qué invocación específica ocurrió cada uno—. Ese "por qué" es, exactamente, la pregunta que el pilar siguiente contesta.
Logs: la bitácora del maquinista de cada invocación
Un log es un registro con detalle de un evento específico, casi siempre con una marca de tiempo y suficiente contexto para reconstruir qué pasó —en el caso de process-shipment-manifest, cada invocación escribe su propia secuencia de líneas en /aws/lambda/process-shipment-manifest: cuándo empezó (START RequestId: ...), qué hizo el código (print() de la función), cuándo terminó (END RequestId: ...), y un resumen de costo y estado (REPORT RequestId: ...)—.
La pregunta que contesta: de las 3 invocaciones que Errors marcó como fallidas, ¿cuáles, exactamente —con su requestId— y por qué, con el mensaje real que validate_manifest() produjo? La lección 4 extrae exactamente esto, con jq, sobre logs reales de las tres invocaciones fallidas del batch.
Lo que no contesta: en qué punto exacto de un flujo de varios pasos —subida a S3, procesamiento en Lambda, escritura en DynamoDB— ocurrió el corte, cuando ese flujo involucra más de un servicio. Un log de process-shipment-manifest te dice que la función falló; no te muestra, en una sola vista, la relación temporal entre la subida a S3 que la disparó y el intento de escritura a Shipments que nunca llegó a ocurrir. Ese "en qué punto del flujo" es la pregunta del tercer pilar.
Trazas: seguir una invocación específica por todo el flujo
Una traza es el registro de una operación individual, seguida a través de todos los servicios que participan en ella, con la relación temporal y jerárquica entre cada paso —en OpenTelemetry, cada paso es un span, y los spans relacionados de una misma operación forman una traza—. La lección 5 construye exactamente esto para process-shipment-manifest: una traza con tres spans —shipment-manifest-upload (la subida a S3), process-shipment-manifest (la invocación del Lambda), dynamodb-put-item (la escritura a Shipments)— para el camino exitoso, y una traza con dos spans —donde el tercero nunca llega a abrirse— para una invocación que falla.
La pregunta que contesta: para una invocación específica —la número 17 del batch, la misma que la lección 4 ya identificó por requestId con logs—, ¿en qué paso exacto del flujo se cortó, y qué pasos anteriores sí llegaron a completarse? La traza de error de la lección 5 muestra, con precisión, que el span shipment-manifest-upload sí ocurrió, que process-shipment-manifest terminó en estado ERROR, y que ningún span de DynamoDB llegó siquiera a abrirse —la prueba visual de que el flujo se detuvo exactamente en la validación, antes de cualquier intento de escritura—.
Lo que no contesta: cuántas invocaciones, en total, tuvieron el mismo problema. Una traza es, por diseño, la vista de una invocación —o de un puñado de invocaciones elegidas a mano—, nunca un agregado. Para eso, el ciclo vuelve al primer pilar: las métricas.
Los tres pilares, aplicados al mismo batch: la tabla completa
| Pilar | Pregunta que contesta (lente de SRE) | Herramienta en este módulo | Alimenta a compute_sli() |
|---|---|---|---|
| Métricas | ¿Cuántos eventos válidos hubo, y cuántos fueron buenos? | awslocal cloudwatch get-metric-statistics (lección 3) | Directamente — total_valid, total_good |
| Logs | ¿Cuáles, específicamente, fueron los eventos malos, y por qué? | awslocal logs filter-log-events + jq (lección 4) | Indirectamente — confirma y explica lo que las métricas ya contaron |
| Trazas | ¿En qué paso exacto del flujo se cortó una invocación específica? | OpenTelemetry + Jaeger (lección 5) | Indirectamente — diagnostica, no cuenta |
Fíjate en la última columna: solo las métricas alimentan la fórmula del SLI de forma directa. Logs y trazas son indispensables para entender un SLI que se está incumpliendo —pero el número que SLO.md cita, 99,9098% o el que sea, se calcula con métricas, no con logs ni con trazas. Esta jerarquía —métricas para medir, logs y trazas para diagnosticar— es la razón exacta por la que la lección 3 de este módulo va primero.
Por qué las tres, y no solo la primera
Una pregunta razonable, después de la tabla anterior: si solo las métricas alimentan directamente el SLI, ¿para qué construir logs y trazas en este módulo? La respuesta es la misma que ya viste en el Módulo 2, lección 2, al elegir errores sobre las otras tres señales doradas: un SLI te dice que algo está mal, nunca por qué. Un SLI de 85% en el batch de este módulo —el número exacto que la lección 7 va a calcular— es alarmante, pero por sí solo no dice si el problema es un bug real en validate_manifest(), un cambio no anunciado en el formato de los manifiestos que llegan, o tres casos aislados sin relación entre sí. Esa pregunta —el paso que separa "medir" de "actuar"— es exactamente la que logs y trazas contestan, y es exactamente la razón por la que un SRE nunca se conforma con un SLI sin la capacidad de investigar detrás de él.
Errores comunes
Tratar los tres pilares como si fueran intercambiables (de asumir que "más observabilidad" siempre es mejor). Qué pasa: alguien, después de esta lección, concluye que con trazas ya no hace falta ningún log, o que con métricas ya no hace falta ninguna traza. Cómo detectarlo: si tu plan es instrumentar un solo pilar "porque es el más completo". Cómo corregirlo: la tabla de esta lección es explícita en que cada pilar contesta una pregunta que los otros dos no contestan —agregado (métricas), detalle de un evento (logs), flujo completo de una operación (trazas)—. Ninguno sustituye a los otros dos; cada uno cubre una pregunta que los demás dejan sin respuesta.
Confundir "tener trazas" con "tener un SLI" (de sobrestimar lo que las trazas aportan a la fórmula). Qué pasa: alguien, después de ver una traza real en Jaeger en la lección 5, asume que ya tiene todo lo necesario para calcular el SLI del mes. Cómo detectarlo: si tu plan para la lección 7 es usar datos de Jaeger, en vez de datos de métricas, como entrada de compute_sli(). Cómo corregirlo: las trazas de este módulo cubren, deliberadamente, solo dos invocaciones del batch de 20 —una exitosa, una fallida—, elegidas a mano para ilustrar el flujo completo. Un SLI necesita el conteo total de eventos válidos y buenos, que solo las métricas agregadas dan sin tener que instrumentar (y pagar el costo de) una traza para cada una de las miles de invocaciones reales que process-shipment-manifest recibiría en producción.
Pensar que este módulo instrumenta los tres pilares "porque hay que hacerlo siempre" (de perder la pregunta que los justifica). Qué pasa: alguien instala este módulo como una checklist genérica —"todo sistema serio necesita métricas, logs y trazas"— sin conectar cada uno con la pregunta específica de SLI que este módulo persigue. Cómo detectarlo: si no puedes explicar, para cada uno de los tres pilares, qué pregunta de SRE específica contesta sobre process-shipment-manifest. Cómo corregirlo: la lección 1 ya lo dejó explícito —la pregunta única de este módulo es "¿esto me deja calcular un SLI de verdad?"—. Los tres pilares entran aquí porque, juntos, contestan esa pregunta completa (medir, y poder explicar lo que se midió), no porque una checklist genérica los exija.
Ejercicios
Ejercicio 1 — Aplica la analogía del tren a un escenario nuevo, sin usar los nombres técnicos todavía. Un cliente de Andes Cargo reporta que su envío 4473 nunca se registró en el sistema. ¿Qué pregunta, en el orden correcto, harías primero con el "tablero", después con la "bitácora", y por último "siguiendo el vagón"? Explica por qué ese orden, y no otro.
Ver solución
Primero, el tablero (métricas): "¿hubo algún error en process-shipment-manifest en la ventana de tiempo en que se subió el manifiesto del envío 4473?" —una pregunta agregada, rápida de contestar—. Si la respuesta es sí, segundo, la bitácora (logs): "¿cuál invocación específica falló, con qué requestId, y qué mensaje de error dejó?" —ahora ya sabes que hubo al menos un error, y necesitas el detalle de cuál—. Solo si el log no alcanza para entender la secuencia completa —por ejemplo, si el error ocurrió en la escritura a DynamoDB después de una validación exitosa, y necesitas ver la relación temporal entre los dos pasos—, el tercer paso, seguir el vagón (trazas): una vista de extremo a extremo de esa invocación específica. El orden importa porque cada paso es más costoso y más específico que el anterior —no tendría sentido abrir una traza de una invocación específica antes de confirmar, con la métrica agregada, que hubo algún error que investigar.
Ejercicio 2 — Explica por qué AWS/Lambda/Errors con Sum: 3.0, por sí sola, no te dice si los tres errores fueron el mismo problema o tres problemas distintos. ¿Qué pilar específico resuelve esa ambigüedad, y cómo?
Ver solución
Errors es un conteo agregado —una suma sobre una ventana de tiempo— sin ningún detalle de qué causó cada error individual; tres invocaciones fallidas con la métrica Errors: 3.0 podrían ser, en principio, tres instancias del mismo bug, tres bugs distintos, o cualquier combinación. Los logs resuelven esta ambigüedad exactamente porque cada línea de log de una invocación fallida (el print(f"Invalid manifest {key}: {errors}") real de validate_manifest()) trae el mensaje de error específico de esa invocación —la lección 4 de este módulo va a mostrar que, del batch de 20, las tres invocaciones fallidas tienen tres razones de validación distintas (campo weightKg faltante, campo carrier faltante, weightKg no numérico), información que ninguna métrica agregada podría haber revelado.
Ejercicio 3 — Defiende, frente a un compañero escéptico, por qué este módulo no se detiene después de construir solo las métricas de la lección 3. Tu compañero argumenta: "las métricas ya alimentan compute_sli() directamente, según la tabla de esta lección — ¿para qué gastar dos lecciones más en logs y trazas?".
Ver solución
Una respuesta completa: "Es cierto que solo las métricas alimentan compute_sli() de forma directa —esta misma lección lo dice—, pero un SLI que solo se mide, sin poder investigarse cuando se incumple, es una alarma sin ningún camino hacia una acción. Si el SLI de un mes cae por debajo del SLO, la pregunta inmediata del equipo va a ser '¿por qué, y qué hacemos?' —y esa pregunta no la contesta ningún número agregado, la contestan los logs (qué error específico, en qué invocación) y, cuando el log no alcanza, las trazas (en qué paso exacto del flujo). Detenerse en las métricas sería como instalar una alarma de humo sin ningún plan para lo que se hace cuando suena: mide el problema, pero no ayuda a resolverlo." La tabla de esta lección ya distingue "medir" (métricas) de "diagnosticar" (logs y trazas) — un sistema de observabilidad serio necesita ambas capacidades, no solo la primera.
Resumen y siguiente paso
Esta lección presentó los tres pilares de observabilidad —métricas, logs, trazas— con la analogía completa de este módulo: el tablero de puntualidad, la bitácora del maquinista, y seguir un vagón específico por toda la ruta. Viste, con precisión, qué pregunta contesta cada uno cuando la pregunta central es "¿mi SLI se cumple?": las métricas alimentan compute_sli() directamente (eventos válidos, eventos buenos); los logs explican, invocación por invocación, cuáles fallaron y por qué; las trazas muestran, para una invocación específica, en qué paso exacto del flujo upload → Lambda → DynamoDB se cortó.
Antes de avanzar deberías poder: recitar la analogía del tren completa, con los tres pilares correctamente asignados; explicar por qué solo las métricas alimentan la fórmula del SLI de forma directa; y argumentar por qué un SLI sin logs ni trazas detrás es una medición sin ningún camino hacia el diagnóstico.
La lección 3 ejecuta el primer pilar de verdad: el mismo batch de 20 invocaciones, leído como conteo agregado con awslocal cloudwatch get-metric-statistics sobre AWS/Lambda/Invocations y AWS/Lambda/Errors.
Recursos
- Google SRE Book, Capítulo 6 — Monitoring Distributed Systems — el marco de monitoreo de Google SRE que esta lección aplica con lente de SLI, ya citado en el Módulo 2 para las cuatro señales doradas.
- OpenTelemetry — Observability Primer — la definición oficial de los tres pilares (métricas, logs, trazas) que esta lección adapta con la analogía del tren.
- Este mismo repositorio, Módulo 2, lección 4 (
04-hands-on-the-error-budget-calculator.md) —compute_sli(), la función que las métricas de la lección 3 de este módulo alimentan directamente. aws-serverless-and-containers-guide(NIEVA), Módulo 2 —validate_manifest(), la fuente real de los tres mensajes de error distintos que la lección 4 de este módulo extrae conjq.