La observabilidad descansa en tres pilares — logs, métricas y traces — y el objetivo es responder "qué está mal y por qué" para un sistema demasiado grande para inspeccionar manualmente. A escala, la estrategia es sobre correlación, muestreo y costo.
| Pillar | Responde | Herramientas |
|---|
| Metrics | ¿Hay algo mal? (rates, latency) | Prometheus, Grafana |
| Traces | ¿Dónde en el flujo? | OpenTelemetry, Jaeger |
| Logs | ¿Qué pasó exactamente? | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
El ID de trace/correlación debe atravesar las etiquetas de métricas, las líneas de log y los spans, para que puedas cambiar entre ellos.
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
Registrar todo al 100% es inasequible y ahoga la señal. En su lugar, muestrea, estructura y alerta sobre SLOs.
Con cientos de servicios, no puedes SSH y mirar — la observabilidad es la única manera de entender el comportamiento en producción.
La estrategia ganadora es correlacionada, muestreada y dirigida por SLO: expone problemas reales rápidamente sin arruinarte en almacenamiento de telemetría o enterrar on-call en ruido.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar