Software Architecture
Explica observabilidad como una capacidad diseñada mediante señales técnicas y de dominio, correlación, ownership, SLOs y preguntas operativas verificables.
Observabilidad es la capacidad de inferir qué ocurre dentro del sistema a partir de señales externas. No consiste en acumular logs: consiste en poder detectar impacto, formular preguntas nuevas, seguir causalidad y actuar con evidencia.
Un sistema observable permite responder preguntas que no fueron programadas como dashboards específicos:
La observabilidad debe diseñarse junto con límites, contratos y flujos. Si cada módulo usa identificadores y semánticas distintas, ninguna herramienta reconstruirá mágicamente la historia.
Supón que usuarios reportan pedidos confirmados que no llegan a preparación.
Logs aislados pueden mostrar:
200 POST /orders/confirm
published message
consumer startedPero todavía faltan respuestas:
La observabilidad conecta señales técnicas con el estado de negocio.
síntoma observable
→ alcance e impacto
→ flujo causal
→ recurso saturado o decisión fallida
→ acción
→ verificación de recuperaciónRecolectar datos sin este recorrido produce ruido. Una señal útil ayuda a decidir.
Comprueba condiciones conocidas:
Permite investigar situaciones no anticipadas combinando dimensiones, eventos y causalidad.
Ambas son necesarias. Monitoring detecta; observabilidad explica.
Series temporales numéricas agregadas.
Buenas para:
Ejemplos:
http_requests_total
request_duration_seconds
queue_lag_seconds
payment_pending_totalEventos discretos con contexto.
Buenos para:
Un log debe ser estructurado, no una frase difícil de consultar.
{
"level": "error",
"event": "stock_reservation_failed",
"order_id": "o-10",
"tenant_id": "t-2",
"trace_id": "abc",
"reason": "insufficient_stock"
}Representan causalidad y tiempo entre operaciones.
confirm order
├── validate membership
├── reserve stock
│ └── UPDATE inventory
├── save order
└── publish outboxAyudan a localizar latencia, fan-out y errores distribuidos.
Muestran dónde se consume CPU, memoria, locks o tiempo de ejecución.
Son esenciales cuando las métricas indican saturación, pero no qué código la causa.
Flujo típico:
Ninguna señal aislada resuelve todo.
El contexto debe cruzar HTTP, colas, jobs y procesos.
Campos útiles:
trace_id.span_id.correlation_id.causation_id.request_id.tenant_id.No todos pertenecen a métricas por cardinalidad. Pueden vivir en logs y trazas.
Agrupa spans de una ejecución técnica.
Relaciona operaciones de un proceso de negocio que puede durar horas o cruzar varias trazas.
Ejemplo: pedido, pago y entrega.
Indica qué evento o comando provocó otro.
OrderConfirmed event-10
→ NotificationRequested event-11
causation_id = event-10Permite reconstruir cadenas sin asumir orden temporal perfecto.
Una traza HTTP tradicional termina al publicar. Para continuar:
No conviertas el payload de negocio en contenedor de metadata técnica si el protocolo ofrece headers.
Cuánto tarda el trabajo, separando éxito y error.
Cuánto trabajo llega y se completa.
Fallos técnicos y resultados de negocio rechazados deben distinguirse.
Qué recurso se acerca a límite: CPU, memoria, pool, cola, locks, disco o conexiones.
Una tasa de errores baja puede coexistir con saturación creciente; el sistema todavía no cayó, pero ya está acumulando riesgo.
Combinarlas ayuda a conectar experiencia con infraestructura.
Las métricas técnicas no muestran todo.
Ejemplos DomiSys:
Una aplicación puede responder 200 mientras el negocio no avanza.
Service Level Indicator es la medición concreta de un comportamiento.
Ejemplo:
proporción de confirmaciones válidas
que terminan en estado confirmado
en menos de 2 segundosUn buen SLI se mide desde la perspectiva del usuario o consumidor, no solo desde una instancia.
Service Level Objective es el objetivo del SLI.
99,9 % de confirmaciones válidas
completan en menos de 2 s
durante 30 díasDebe definir:
Es un compromiso contractual con consecuencias. No debe confundirse con SLO interno.
El SLO puede ser más estricto para conservar margen antes de violar SLA.
Si el SLO permite 0,1 % de fallos, ese margen es el error budget.
Sirve para equilibrar:
Cuando se consume demasiado rápido, el equipo puede pausar cambios riesgosos y priorizar estabilidad.
No es permiso para fallar deliberadamente. Es una herramienta de decisión.
Mide qué tan rápido se consume el error budget.
Una alerta multi-window puede detectar:
Alertar por cada error individual produce ruido. Alertar por impacto sobre SLO conecta mejor con usuarios.
Una alerta debe indicar:
Una alerta que no requiere acción debería ser métrica o reporte, no despertar a alguien.
Prefiere alertar por síntomas de usuario:
Después usa alertas de causa para diagnóstico:
Alertar solo CPU puede no tener impacto; alertar solo errores sin recursos dificulta diagnóstico.
Cardinalidad es cantidad de combinaciones de labels.
Peligroso en métricas:
request_duration{user_id, order_id, trace_id}Millones de IDs crean millones de series y costos altos.
Úsalos en logs o trazas.
Medir cada tenant como label puede ser útil con pocos tenants y peligroso con miles.
Alternativas:
La necesidad de aislamiento no justifica destruir el sistema de métricas.
Para latencia, conserva histogramas o sketches adecuados.
Promedios no permiten reconstruir percentiles correctamente entre instancias.
Buckets mal elegidos pueden ocultar distribución. Deben alinearse con SLO y rango esperado.
Guardar todas las trazas puede ser costoso.
Decide al inicio. Es simple, pero puede descartar una traza que termina en error.
Decide después de conocer resultado. Puede conservar:
Requiere buffering y más infraestructura.
Flujos críticos, tenants o canaries pueden tener tasa mayor.
No uses sampling para auditoría obligatoria.
Buenas prácticas:
Ejemplo:
{
"level": "warn",
"event": "payment_reconciliation_required",
"payment_id": "p-10",
"order_id": "o-20",
"tenant_id": "t-2",
"provider": "x",
"state": "unknown",
"trace_id": "abc"
}Redacta en origen, no confíes solo en filtros del backend de logs.
Un audit log necesita garantías diferentes:
No debe depender de sampling ni perderse durante rotación normal.
Un span debe representar una operación con significado.
Atributos:
No crees spans por cada función trivial; aumenta ruido y costo.
Marca:
Una validación de negocio insufficient_stock puede no ser error del servicio. Clasificar todo como error distorsiona SLO.
Mide:
La profundidad sola puede ser engañosa. Una cola de 1.000 mensajes puede ser normal si se procesa en segundos; la edad revela impacto.
Conecta estas señales con pedidos o pagos afectados.
Evita registrar parámetros sensibles de consultas.
Síntoma:
pedido confirmado en UI
pero preparación no iniciaInvestigación:
Sin IDs y señales diseñadas, cada paso requiere adivinar.
Alerta: p95 de confirmación aumenta.
Segmentación muestra solo tenants con catálogo grande.
Trazas revelan query con muchas líneas; métricas de base muestran sort a disco.
La causa no es CPU general. Se necesita índice, paginación o límite de tamaño.
La observabilidad evita escalar instancias incorrectamente.
Un runbook útil contiene:
Debe probarse durante ejercicios y actualizarse después de incidentes.
Cada servicio o módulo necesita owner de:
Una plataforma puede ofrecer herramientas, pero el equipo del dominio define qué significa correcto.
Una nueva capacidad no está completa si no permite:
Incluye requisitos de observabilidad en definición de terminado.
La aplicación no debería caer por no poder exportar telemetría. Usa buffers acotados y drop controlado. Auditoría crítica puede necesitar canal más fuerte.
Sampling, batching y límites. La observabilidad no debe ser el cuello.
Trazas y logs parecen fuera de orden. Usa sincronización y relaciones causales, no solo timestamps.
La historia se rompe. Prueba propagación y establece headers estándar.
Un label usa URL completa o ID. Detecta series nuevas y aplica governance.
Cada capa registra la misma excepción. Define dónde se maneja y registra.
Un debug temporal filtra tokens. Usa defaults seguros y revisión.
Sin métricas, trazas, contexto y preguntas, solo existe almacenamiento de texto.
Genera fatiga. Conecta con SLO y negocio.
Explota cardinalidad.
Jobs, mensajes, cron y reconciliación quedan invisibles.
Aumenta costo y riesgo de privacidad.
Se vuelve obsoleto y no guía acción.
Puede ocultar un proceso de negocio fallido.
Una prueba de observabilidad pregunta: ¿podemos explicar y actuar?, no solo ¿se emitió un log?
200 no demuestra que el proceso de negocio terminó correctamente?order_id no debería ser label de una métrica general?Arquitectura de seguridad y threat modeling utiliza estos límites y señales para identificar amenazas, aplicar defensa en profundidad y detectar abuso o aislamiento roto.