Software Architect · Módulo 17
Observability responde una pregunta: ¿podemos entender qué está haciendo el sistema — sin deployar código nuevo y sin adivinar a partir de síntomas indirectos?
Logs · metrics · traces · correlation id · alerting
La observability se diseña junto con el sistema — no se atornilla después del primer gran incidente.
Las tres señales resuelven problemas distintos
El termómetro, el mapa y la cámara de tablero muestran cada uno una cara distinta del viaje. Con un solo instrumento no alcanza.
Las metrics muestran el estado agregado: latency, error rate, queue depth, memory, throughput. Los logs te dan eventos y contexto. Los traces muestran el recorrido de un request a través de los servicios.
El arquitecto tiene que decidir qué signals importan para los user journeys críticos. Para checkout: payment latency, failed authorizations, retry count, outbox lag, provider errors. Para un sitio de contenido: cache hit ratio, build failures, p95 page load, search freshness.
Un alert tiene que exigir acción
Una alarma que suena cada hora sin motivo termina siendo parte del ruido de fondo.
Los malos alerts generan fatiga. Un buen alert está atado al impacto en el usuario o a un acercamiento serio a un límite peligroso. Tiene owner, severity, runbook y una acción clara.
No todo tiene que despertar a alguien de noche. Los error logs sin impacto en el SLO pueden vivir en un dashboard o en un ticket. Una caída de los pagos exitosos tiene que llamar al on-call al instante.
Durante un incidente, la observability tiene que reducir el time-to-understanding — no agregar ruido.
Ejemplo: un correlation id a lo largo de todo el request path
El número de expediente en un juzgado te permite encontrar cada documento, testigo y fallo. Sin ese número, todos buscan de memoria.
Cada request entrante recibe un correlation id. Atraviesa la API, el worker, los broker messages y los downstream calls. Logs y traces lo llevan. Support saca el id del error del usuario y un ingeniero ve de un vistazo el recorrido completo del request.
Eso reduce drásticamente el MTTR: el equipo no busca "algo cerca de las 14:03" — mira una cadena concreta de eventos.
Antiejemplo: los logs como un río de texto
Un libro sin capítulos, sin números de página y sin índice contiene información — pero usarlo es casi imposible.
El servicio escribe something failed, bad request, payment error — sin user id, tenant id, order id, provider code, retry count ni severity. En el incident review, el equipo entiende que los datos estaban, pero que con eso no se puede investigar.
Los logs estructurados con contexto le ganan a las cadenas bonitas.
- ¿Qué SLO se ven en las metrics? - ¿Se puede seguir un único request a través de todos los servicios? - ¿Qué alerts exigen acción inmediata? - ¿Qué campos necesitan los logs para sostener una investigación?