Monitoramento de API Gateway: AWS, Kong e Melhores Praticas

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 4xxMudanca do lado do cliente: deploy de frontend quebrado, API keys expiradas
• Spike de 5xxO gateway ou backend esta falhando
• 429 (Too Many Requests)Rate limiting ativo
• 502/504Backend 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 monitoramento a nivel de aplicacao

Para aplicacoes Next.js atras de um API gateway, a forma padrao de ganhar visibilidade a nivel de aplicacao e instrumentar o servidor, por exemplo com OpenTelemetry registrado no hook instrumentation.ts, e exportar os dados para o backend que voce ja usa (Prometheus e Grafana, CloudWatch ou um APM):

// instrumentation.ts, runs inside your Next.js server
import { registerOTel } from '@vercel/otel'

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

Roda dentro do seu servidor, downstream do gateway. Ve cada request apos auth, rate limiting e cache. Te da latencia server-side por rota, taxas de erro reais, visibilidade de cold starts e a base para alertas por rota.

Stack recomendado

Nao deixe o gateway ser sua unica camada de auth

Um gateway que aplica auth e rate limiting nao garante que cada rota atras dele verifique quem esta chamando: rotas internas, endpoints novos fora da config do gateway ou checagens de acesso por objeto vivem no seu codigo. O pentester com IA da Nurbak escaneia seu repositorio em busca de checagens de auth faltando e outros bugs exploraveis, e pode abrir um PR com a correcao. Seu primeiro scan e gratis.