Monitoreo de REST API: Que Trackear y Que Herramientas Usar

Tu REST API esta "arriba." Felicitaciones. Eso no te dice casi nada.

Uptime significa que el servidor responde. No te dice que /api/checkout tarda 4 segundos en vez de 400 milisegundos. No te dice que el 3% de los requests a /api/users devuelven 500. No te dice que tu endpoint mas critico es 10x mas lento en horas pico.

Metrica 1: Uptime: Pero medido bien

Lo que hacen la mayoria: Un servicio externo pinga /api/health cada 60 segundos. Si devuelve 200, la API esta "arriba."

Lo que deberias hacer: Calcular uptime desde datos de requests reales. Si serviste 1,000,000 de requests y 2,000 devolvieron 5xx, tu uptime efectivo es 99.8%.

Metrica 2: Percentiles de latencia: P50, P95, P99

El tiempo de respuesta promedio es mentira. Si 99 requests tardan 50ms y 1 tarda 10 segundos, el promedio es 149ms. Ese numero esconde que el 1% de tus usuarios tiene una experiencia terrible.

• P50 (mediana)La experiencia tipica. Si tu P50 es 80ms, la mayoria de usuarios esta bien.
• P95El 5% mas lento. Captura queries lentas, cold starts y problemas n+1.
• P99El 1% peor. Un usuario que hace 100 llamadas tiene 63% de probabilidad de experimentar el P99 al menos una vez.

Targets: P50 bajo 100ms, P95 bajo 500ms, P99 bajo 2 segundos.

Metrica 3: Error rate por endpoint

Un error rate global de 0.5% parece bien. Pero que pasa si todos los errores vienen de un solo endpoint?

// Vista global: 0.5% error rate, parece bien
// Vista por endpoint:
// GET  /api/users     → 0.01% errores 
// POST /api/checkout  → 12.4% errores   ← Aca estan todos los errores

Que trackear: 4xx rate (errores de cliente, spikes en 400/422 suelen significar un deploy de frontend roto) y 5xx rate (errores de servidor, siempre tu culpa).

Metrica 4: Throughput: Requests por minuto

Throughput combinado con latencia y errores se vuelve diagnostico:

• Throughput sube + latencia sube = Te acercas al limite de capacidad
• Throughput sube + errores suben = Ya pasaste el limite
• Throughput baja + latencia sube = Una dependencia esta lenta

Metrica 5: Deteccion de endpoints lentos

Los umbrales estaticos ("alertar si respuesta > 2 segundos") no funcionan cuando tenes 30 endpoints con rangos normales distintos. La deteccion de endpoints lentos identifica automaticamente que rutas se estan degradando relativo a su propia baseline.

Comparacion de herramientas

Setup en Next.js con OpenTelemetry

Una forma neutral respecto del vendor es registrar OpenTelemetry en el hook instrumentation.ts (con @vercel/otel y sus dependencias) y apuntar el exporter a tu backend con OTEL_EXPORTER_OTLP_ENDPOINT:

// instrumentation.ts
import { registerOTel } from '@vercel/otel'

export function register() {
  registerOTel({ serviceName: 'my-api' })
}

Con los datos llegando, armá en tu backend dashboards y alertas de P50/P95/P99, error rates, throughput y endpoints lentos respecto de su baseline. Sumá un chequeo externo de uptime para las caídas totales.

Que hacer despues del setup

1. Semana 1: Observar. No poner umbrales todavia. Dejar que la herramienta establezca baselines.
2. Semana 2: Poner umbrales de P95 por endpoint (2x la baseline es buen punto de inicio).
3. Semana 3: Poner umbrales de error rate. 0.5% para endpoints criticos, 2% para el resto.
4. Continuo: Revisar semanalmente. Buscar tendencias lentas, un P95 que sube 10% por semana va a ser problema en un mes.