Seu API gateway fica na frente de cada request. Lida com autenticacao, rate limiting, routing e as vezes caching. E o ponto unico por onde cada chamada de API passa.

O que o torna o ponto unico onde coisas podem dar errado sem ninguem perceber.

Metricas de API Gateway que importam

1. Latencia de request (total vs integracao)

Latencia total e o round-trip completo. Latencia de integracao e so o tempo que seu backend leva para processar. A diferenca e overhead do gateway — auth, transformacoes, logging.

Se a latencia de integracao e baixa mas a total e alta, o problema esta no gateway, nao no seu backend.

2. Taxas de erro — 4xx vs 5xx

  • Spike de 4xx — Mudanca do lado do cliente: deploy de frontend quebrado, API keys expiradas
  • Spike de 5xx — O gateway ou backend esta falhando
  • 429 (Too Many Requests) — Rate limiting ativo
  • 502/504 — Backend inalcancavel ou lento demais

3. Taxa de throttling

Quantos requests estao sendo rejeitados por rate limits. Algum throttling e intencional. Demais significa que voce esta bloqueando usuarios reais.

4. Cache hit rate

  • Acima de 80%: Caching efetivo
  • 50-80%: Decente, revisar TTL e cache keys
  • Abaixo de 50%: Algo esta errado

5. Request count por rota e metodo

A distribuicao de trafego diz onde focar otimizacao. O endpoint com 3% do trafego pode gerar 80% da sua receita.

Monitoramento de AWS API Gateway

AWS API Gateway publica metricas no CloudWatch automaticamente. Habilite metricas detalhadas para breakdowns por rota:

aws apigateway update-stage \
  --rest-api-id your-api-id \
  --stage-name prod \
  --patch-operations \
op=replace,path=/~1*/metrics/enabled,value=true

Metricas chave do CloudWatch: Count, Latency, IntegrationLatency, 4XXError, 5XXError, CacheHitCount.

Monitoramento de Kong Gateway

Kong expoe metricas via plugin 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 uteis de PromQL para Grafana:

# Taxa de erro por servico
sum(rate(kong_http_requests_total{code=~"5.."}[5m])) by (service)
/
sum(rate(kong_http_requests_total[5m])) by (service)

# P95 latencia por rota
histogram_quantile(0.95,
  sum(rate(kong_request_latency_ms_bucket[5m])) by (le, route)
)

O gap: o que os gateways nao monitoram

Metricas do gateway dizem o que aconteceu na borda da rede. Nao dizem o que aconteceu dentro da sua aplicacao:

  • O gateway ve latencia total — nao ve onde dentro do app o tempo foi gasto
  • O gateway ve status codes HTTP — nao ve erros de logica de negocio retornados como 200
  • O gateway ve health binario (no ar/fora) — nao ve degradacao parcial

Monitoramento de gateway diz o sintoma. Monitoramento a nivel de aplicacao diz a causa.

Preenchendo o gap com Nurbak Watch

Para aplicacoes Next.js atras de um API gateway, Nurbak Watch fornece visibilidade a nivel de aplicacao:

// instrumentation.ts
import { initWatch } from '@nurbak/watch'

export function register() {
  initWatch({
apiKey: process.env.NURBAK_WATCH_KEY,
  })
}

Roda dentro do seu servidor — downstream do gateway. Ve cada request apos auth, rate limiting e cache. Adiciona latencia server-side por rota, taxas de erro reais, tracking de cold starts e alertas por Slack, email ou WhatsApp em menos de 10 segundos.

Stack recomendado

CamadaFerramentaO que monitora
GatewayCloudWatch / PrometheusTrafego, throttling, cache, erros de gateway
AplicacaoNurbak WatchLatencia server-side, taxas de erro, cold starts
UptimePing externo (UptimeRobot)Deteccao de queda total

Comece gratis

Nurbak Watch esta em beta e e gratis durante o lancamento. Complementa seu monitoramento de gateway com as metricas a nivel de aplicacao que voce nao tem hoje.