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=trueMetricas 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
| Camada | Ferramenta | O que monitora |
|---|---|---|
| Gateway | CloudWatch / Prometheus | Trafego, throttling, cache, erros de gateway |
| Aplicacao | Nurbak Watch | Latencia server-side, taxas de erro, cold starts |
| Uptime | Ping 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.

