¿Cómo diseñarías la monitorización de una aplicación desde cero?

Question

IT Interview Practice · Accepted Answer

Comienza **de arriba a abajo con enfoque en lo que sienten los usuarios**, no de abajo a arriba desde la infraestructura. La flota de hosts más confiable es inútil si las solicitudes fallan, así que comienza con **SLIs** orientadas al usuario — **latencia**, **tasa de errores**, **disponibilidad** — luego agrega las cuatro señales doradas, y finalmente métricas de infraestructura.

## La estratificación, del usuario hacia adentro

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

Si solo monitoreas CPU y disco (de abajo a arriba), puedes estar completamente verde mientras los usuarios reciben 500s. Monitorear SLIs primero (de arriba a abajo) significa que alertas sobre **síntomas que los usuarios realmente sienten**, luego profundizas en señales doradas e infraestructura para encontrar la causa.

## La tubería: instrumentar → recopilar → tablero → alertar

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## Un punto de partida concreto

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

Define un **SLO** en cada SLI (por ejemplo, disponibilidad del 99,9%, p99 < 300ms), ponlos en el tablero y alerta cuando el SLO está en riesgo — no en cada fluctuación.

## Por qué es importante

La monitorización construida de abajo a arriba te dice que un disco está al 80% lleno pero no que los clientes no pueden completar la compra. Comenzar desde SLIs orientadas al usuario vincula cada tablero y alerta al impacto real del usuario, mantiene el ruido bajo y proporciona un camino claro de profundización (síntoma → señal dorada → causa de infraestructura) cuando algo se rompe.

La estratificación, del usuario hacia adentro

La tubería: instrumentar → recopilar → tablero → alertar

Un punto de partida concreto

Por qué es importante

Preguntas relacionadas