Tu API gateway esta delante de cada request. Maneja autenticacion, rate limiting, routing y a veces caching. Es el punto unico por el que pasa cada llamada a tu API.
Lo que lo convierte en el punto unico donde las cosas pueden fallar sin que nadie se de cuenta.
Metricas de API Gateway que importan
1. Latencia de request (total vs integracion)
Latencia total es el round-trip completo. Latencia de integracion es solo el tiempo que tu backend tarda en procesar. La diferencia es overhead del gateway, auth, transformaciones, logging.
Si la latencia de integracion es baja pero la total es alta, el problema esta en el gateway, no en tu backend.
2. Error rates, 4xx vs 5xx
- Spike de 4xxCambio del lado del cliente: deploy de frontend roto, API keys expiradas
- Spike de 5xxEl gateway o backend esta fallando
- 429 (Too Many Requests)Rate limiting activo. Puede ser proteccion legitima o limites mal configurados
- 502/504Backend inalcanzable o demasiado lento
3. Tasa de throttling
Cuantos requests estan siendo rechazados por rate limits. Algo de throttling es intencional. Demasiado significa que estas bloqueando usuarios reales.
4. Cache hit rate
- Arriba de 80%: Caching efectivo
- 50-80%: Decente, revisar TTL y cache keys
- Debajo de 50%: Algo anda mal
5. Request count por ruta y metodo
La distribucion de trafico te dice donde enfocar optimizacion. El endpoint con 3% del trafico puede generar el 80% de tus ingresos.
Monitoreo de AWS API Gateway
AWS API Gateway publica metricas a CloudWatch automaticamente. Habilita metricas detalladas para breakdowns por ruta:
aws apigateway update-stage \
--rest-api-id your-api-id \
--stage-name prod \
--patch-operations \
op=replace,path=/~1*/metrics/enabled,value=trueMetricas clave de CloudWatch: Count, Latency, IntegrationLatency, 4XXError, 5XXError, CacheHitCount.
Monitoreo de Kong Gateway
Kong expone metricas via el plugin de Prometheus:
curl -X POST http://localhost:8001/plugins \
--data "name=prometheus" \
--data "config.status_code_metrics=true" \
--data "config.latency_metrics=true" \
--data "config.bandwidth_metrics=true"Queries utiles de PromQL para Grafana:
# Error rate por servicio
sum(rate(kong_http_requests_total{code=~"5.."}[5m])) by (service)
/
sum(rate(kong_http_requests_total[5m])) by (service)
# P95 latencia por ruta
histogram_quantile(0.95,
sum(rate(kong_request_latency_ms_bucket[5m])) by (le, route)
)El gap: lo que los gateways no monitorean
Las metricas del gateway te dicen que paso en el borde de la red. No te dicen que paso dentro de tu aplicacion:
- El gateway ve latencia total, no ve donde dentro de la app se gasto el tiempo
- El gateway ve status codes HTTP, no ve errores de logica de negocio devueltos como 200
- El gateway ve health binario (arriba/abajo), no ve degradacion parcial
Monitoreo de gateway te dice el sintoma. Monitoreo a nivel de aplicacion te dice la causa.
Llenando el gap con monitoreo a nivel de aplicacion
Para aplicaciones Next.js detras de un API gateway, la forma estandar de sumar visibilidad a nivel de aplicacion es instrumentar el servidor, por ejemplo con OpenTelemetry registrado en el hook instrumentation.ts, y exportar los datos al backend que ya usás (Prometheus y Grafana, CloudWatch o un APM):
// instrumentation.ts, runs inside your Next.js server
import { registerOTel } from '@vercel/otel'
export function register() {
registerOTel({ serviceName: 'my-app' })
}Corre dentro de tu servidor, downstream del gateway. Ve cada request despues de auth, rate limiting y cache. Te da latencia server-side por ruta, error rates reales, visibilidad de cold starts y la base para alertas por ruta.
Stack recomendado
| Capa | Herramienta | Que monitorea |
|---|---|---|
| Gateway | CloudWatch / Prometheus | Trafico, throttling, cache, errores de gateway |
| Aplicacion | OpenTelemetry + tu backend de metricas o APM | Latencia server-side, error rates, cold starts |
| Uptime | Ping externo (UptimeRobot) | Deteccion de caida total |
Que el gateway no sea tu unica capa de auth
Un gateway que aplica auth y rate limiting no garantiza que cada ruta detras de el verifique quien llama: rutas internas, endpoints nuevos fuera de la config del gateway o chequeos de acceso por objeto viven en tu codigo. El pentester con IA de Nurbak escanea tu repo en busca de chequeos de auth faltantes y otros bugs explotables, y puede abrir un PR con el fix. Tu primer escaneo es gratis.
