A crise do monitoramento de microsserviços#

O monitoramento de uptime tradicional pergunta: "Seu site está respondendo?"

A arquitetura moderna de microsserviços pergunta: "Todos os 47 microsserviços estão respondendo, e estão respondendo uns aos outros corretamente?"

Uma plataforma de microsserviços é composta por dezenas de serviços interconectados:

API Gateway → Auth Service → User Service → Database
             → Payment Service → Stripe
             → Notification Service → SendGrid
             → Reporting Service → Data Warehouse
             → Search Service → Elasticsearch
             → Cache → Redis

Se QUALQUER um desses serviços falhar:

Auth Service fora do ar = ninguém consegue fazer login
Payment Service fora do ar = clientes não conseguem pagar
Search Service fora do ar = clientes não encontram produtos
Cache Redis fora do ar = o sistema fica lento (falha em cascata)

O monitoramento de uptime tradicional ignora completamente essa complexidade.

Por que monitorar microsserviços é diferente#

1. Falhas distribuídas

Em sistemas monolíticos, a falha é binária: up ou down.

Em microsserviços, as falhas são parciais e em cascata:

Cenário 1: Search Service lento
  - Requisições de search levam 10 segundos (normalmente 200ms)
  - Requisições do frontend dão timeout esperando os resultados
  - Latência das requisições da API sobe 10x
  - Usuários veem "página carregando lentamente"
  - Não detectado por checks de uptime simples (a API tecnicamente responde)

Cenário 2: Cache Service degradado
  - Taxa de acerto do cache Redis cai de 90% para 20%
  - Banco de dados recebe 4x mais queries
  - CPU do banco sobe para 100%
  - Todas as requisições ficam lentas (mesmo as não relacionadas)
  - Falha em cascata por todo o sistema

Cenário 3: Falha de comunicação entre serviços
  - Auth Service está up
  - User Service está up
  - Mas um problema de rede impede a comunicação Auth → User
  - Usuários não conseguem fazer login
  - Ambos os serviços aparecem como "up" no monitoramento

2. Falhas específicas do Kubernetes

O Kubernetes adiciona complexidade:

Ciclo de restart de Pod:
  - Pod travou por causa de memory leak
  - Kubernetes reinicia o pod automaticamente
  - O Pod está reiniciando, não respondendo ao tráfego
  - Aparece como "up" (o pod existe), mas não está atendendo requisições

Falha de Node:
  - Um node do Kubernetes cai
  - O scheduler move os pods para outros nodes
  - Os Pods estão ok, mas temporariamente indisponíveis durante a migração
  - Falhas breves de requisição durante a transição

Problema de Deployment:
  - Novo deployment tem bug na inicialização
  - Pods não conseguem subir
  - Pods existentes ainda atendem requisições
  - Sistema está degradado, mas não totalmente fora do ar

3. Complexidade do Service Mesh

Com service mesh (Istio, Linkerd):

O Service Mesh adiciona outra camada:
  - Service → Sidecar → Network → Sidecar → Service
  - O sidecar pode injetar falhas (rate limiting, timeouts)
  - Circuit breakers podem disparar (impedindo requisições)
  - Load balancing pode ficar desigual (algumas instâncias recebem mais tráfego)

O monitoramento precisa incluir:
  - Saúde do sidecar
  - Status do circuit breaker
  - Distribuição do load balancing
  - Saúde do control plane do service mesh

Arquitetura de monitoramento de microsserviços#

Nível 1: Disponibilidade do serviço#

Monitore cada serviço individualmente:

Auth Service:
  - O serviço está rodando? (pod count > 0)
  - Está respondendo aos health checks? (GET /health retorna 200)
  - Qual o tempo de resposta? (P95 &lt; 100ms)
  - Qual a taxa de erro? (&lt; 0,1%)

Payment Service:
  - O serviço está rodando?
  - Está respondendo? (GET /health)
  - Consegue se comunicar com a Stripe? (Stripe está respondendo)
  - Qual a latência? (P95 &lt; 500ms)

Nível 2: Comunicação entre serviços#

Monitore a comunicação serviço-a-serviço:

Auth Service → User Service:
  - O Auth Service consegue alcançar o User Service? (conectividade de rede)
  - Qual a latência? (P95 &lt; 50ms)
  - Qual a taxa de erro? (&lt; 0,01%)

User Service → Database:
  - O User Service consegue alcançar o banco? (saúde do connection pool)
  - O connection pool está esgotado? (esperando por conexões)
  - Qual a latência das queries? (P95 &lt; 100ms)

Nível 3: Tracing distribuído de transações#

Monitore fluxos completos de requisição:

Fluxo de Login do usuário:
  1. API Gateway recebe a requisição de login
  2. Roteia para Auth Service (latência: 10ms)
  3. Auth Service consulta o User Service (latência: 15ms)
  4. User Service consulta o banco de dados (latência: 20ms)
  5. Auth Service assina o token JWT (latência: 5ms)
  6. API Gateway retorna a resposta (latência: 2ms)

Latência total: 52ms (aceitável)

Se a query do User Service leva 500ms em vez de 20ms:
  - Latência total pula para 532ms
  - Usuário vê login lento
  - Performance da aplicação se degrada
  - O monitoramento captura a causa raiz (query lenta no User Service)

Nível 4: Monitoramento específico do Kubernetes#

Monitore a infraestrutura do Kubernetes:

Saúde do Pod:
  - Contagem de restarts do Pod (alerta se > 5 em 24h)
  - Uso de memória do Pod (alerta se chegando perto do limite)
  - Uso de CPU do Pod (alerta se sustentado > 80%)

Saúde do Node:
  - Status do Node (Ready, NotReady, Unknown)
  - Pressão de disco do Node (alerta se > 85% cheio)
  - Pressão de memória do Node (alerta se &lt; 10% disponível)

Saúde do Deployment:
  - Replicas desejadas vs. replicas prontas (alerta se houver discrepância)
  - Latência de criação de Pod (alerta se > 30 segundos)
  - Erros de pull de imagem (alerta se os pods não conseguem subir)

Falha real de monitoramento de microsserviços#

Organização: Plataforma FinTech com mais de 30 microsserviços, 50 pods Kubernetes

Arquitetura:

API Gateway (5 réplicas)
Auth Service (3 réplicas)
Payment Service (5 réplicas)
Notification Service (3 réplicas)
Data Pipeline (2 réplicas)
Cache (Redis cluster)
Banco de dados (PostgreSQL)

O incidente: Processamento de pagamento lento

Linha do tempo:

14h00: Pods do Notification Service reiniciam (memory leak)
14h05: Criação de pods do Notification Service lenta (scheduler do Kubernetes sobrecarregado)
14h10: Requisições do Payment Service para o Notification Service dão timeout (serviço não está respondendo)
14h10: Payment Service implementa retry no client-side (exponential backoff)
14h15: Tempestade de retries cascateia para o API Gateway
14h15: API Gateway sobrecarregado, fila de requisições enche
14h20: Todas as requisições dos usuários dão timeout
14h20: Incidente declarado, engenheiro on-call acionado

O que o monitoramento teria pego:

14h01: Alerta "Contagem de restarts do pod do Notification Service excedeu o limite"
14h06: Alerta "Latência de criação do pod do Notification Service > 30 segundos"
14h07: Alerta "Health check do Notification Service falhando"
14h08: Alerta "Pico de latência Payment Service → Notification Service"
14h09: Alerta "Pico de taxa de erro do Payment Service"

Alertas precoces poderiam ter evitado a cascata: reiniciar o Notification Service manualmente, ou ajustar a estratégia de retry no Payment Service.

Implementação de monitoramento de microsserviços#

Opção 1: DIY com Prometheus + Grafana#

Prometheus:
  - Faz scrape do endpoint /metrics de cada serviço
  - Armazena métricas em banco de dados time-series
  - Executa regras de alerta (se a métrica passa do limite, dispara alerta)

Grafana:
  - Visualiza métricas do Prometheus
  - Dashboards por serviço
  - Dashboards por serviço e cross-service

Implementação: Open-source, grátis, exige conhecimento de infraestrutura
Custo: Baixo (só infraestrutura), Alto (tempo de engenharia)
Indicado para: Times com expertise em DevOps

Opção 2: Serviço gerenciado (Datadog, New Relic)#

Agente Datadog/New Relic:
  - Roda como sidecar em cada pod
  - Coleta métricas, logs, traces
  - Envia para o serviço gerenciado

Dashboard:
  - Dashboards prontos para Kubernetes
  - APM para comunicação entre serviços
  - Tracing distribuído nativo

Implementação: Ferramenta de fornecedor, configuração complexa, poderosa
Custo: Alto (preço por host/por GB), Baixo (tempo de engenharia)
Indicado para: Times com orçamento, menos expertise em ops

Opção 3: Service Mesh com monitoramento nativo#

Istio/Linkerd:
  - O proxy sidecar intercepta toda a comunicação entre serviços
  - Rastreia automaticamente latência, erros, tráfego
  - Oferece observabilidade sem mudanças de código

Monitoramento:
  - Dashboards do service mesh mostram dependências entre serviços
  - Status do circuit breaker
  - Distribuição de tráfego
  - Latência de requisição por rota

Implementação: Mudança a nível de infraestrutura, poderoso mas complexo
Custo: Overhead de infraestrutura (CPU/memória do sidecar)
Indicado para: Grandes organizações com muitos serviços

Checklist de monitoramento de microsserviços#

Por serviço#

☐ Endpoint de health check implementado (/health retorna 200 quando saudável)
☐ Endpoint de métricas exposto (/metrics para scraping do Prometheus)
☐ Disponibilidade do serviço monitorada (pod rodando, health check passando)
☐ Tempo de resposta do serviço monitorado (latência P95 rastreada)
☐ Taxa de erro do serviço monitorada (erros 4xx, 5xx rastreados)
☐ Logs do serviço centralizados (ELK, Splunk ou similar)

Por comunicação entre serviços#

☐ Latência entre serviços monitorada (serviço A → serviço B)
☐ Taxa de erro por comunicação entre serviços rastreada
☐ Status do circuit breaker monitorado (se aplicável)
☐ Tratamento de timeout verificado (lógica de retry adequada)

Por cluster Kubernetes#

☐ Saúde dos Pods monitorada (contagem de restarts, memória, CPU)
☐ Saúde dos Nodes monitorada (status, disco, memória)
☐ Saúde dos Deployments monitorada (replicas desejadas vs. prontas)
☐ Saúde dos Persistent Volumes monitorada (espaço disponível, erros de I/O)
☐ Uso de recursos por namespace monitorado (limites de CPU, memória)

Tracing distribuído#

☐ Traces de requisições coletados (request ID propagado entre serviços)
☐ Visualização de traces disponível (ver fluxo da requisição)
☐ Decomposição de latência do trace visível (qual serviço está lento?)
☐ Detecção de erros no trace (qual serviço falhou?)

Boas práticas de monitoramento de microsserviços#

1. Correlation IDs para tracing distribuído

Toda requisição deve ter um ID único propagado por todos os serviços:

Requisição do usuário:
  Header: X-Request-ID: 12345

Service A:
  logs: "Request 12345: Iniciado"
  chama Service B com header: X-Request-ID: 12345

Service B:
  logs: "Request 12345: Recebido do Service A"
  chama Service C com header: X-Request-ID: 12345

Service C:
  logs: "Request 12345: Processamento concluído"

Depois, recupere todos os logs da request 12345 para ver o fluxo completo

2. Logging estruturado

Não logue: "Erro ocorreu" Logue: JSON com contexto

{
  "timestamp": "2026-02-20T14:32:15Z",
  "request_id": "12345",
  "service": "payment-service",
  "level": "error",
  "message": "Falha na autorização do pagamento",
  "error_code": "STRIPE_AUTH_FAILED",
  "attempt": 1,
  "latency_ms": 2500,
  "status_code": 503
}

3. Padrão Circuit Breaker

Implemente circuit breakers para evitar falhas em cascata:

Normal:
  Payment Service → chama API da Stripe
  Stripe retorna 200 (sucesso)
  Requisição continua

Modo de falha (Circuito Aberto):
  API da Stripe retorna 503 (serviço fora do ar)
  Após 5 falhas, o circuit breaker abre
  Requisições subsequentes falham rápido (sem tentativa de chamar a Stripe)
  Latência da chamada à API da Stripe cai de 2s para 50ms
  Sistema se degrada graciosamente em vez de falhar em cascata

Recuperação:
  Circuit breaker entra em half-open (testa 1 requisição)
  Se der certo, aumenta gradualmente as requisições para a Stripe
  Se falhar, o circuito volta a abrir

Pegadinhas específicas do Kubernetes no monitoramento#

Pegadinha 1: O IP do Pod muda no restart#

Quando um pod reinicia, o IP dele muda. Os registros DNS precisam ser atualizados.

O monitoramento precisa levar isso em conta:

Monitore por nome do serviço, não pelo IP do pod
Use o DNS do Kubernetes (service-name.namespace.svc.cluster.local)
Monitore os endpoints de service do Kubernetes (os pods estão registrados?)

Pegadinha 2: Atrasos do Init Container#

Os init containers do Kubernetes rodam antes do container principal. Se o init container está lento:

Status do Pod: "Running" (tecnicamente correto)
Mas, na prática: Init container ainda rodando, serviço ainda não está pronto
Health checks podem falhar (serviço ainda não responde)

Soluções:

Não dispare alertas em falhas de health check nos primeiros 60 segundos
Use startup probes (diferentes das liveness probes)
Monitore a latência de conclusão do init container

Pegadinha 3: Limites de recursos impactam a performance#

Se o limite de CPU do pod estiver muito baixo:

Status do Pod: Running
Mas, na prática: CPU em throttling, pico de latência
Monitoramento mostra pico de latência, mas o uso de CPU mostra 100% em throttling

Solução: Monitore tanto o uso de CPU QUANTO o throttling de CPU
Dispare alerta se a CPU ficar em throttling > 20% do tempo

Nova Uptime para monitoramento de microsserviços#

O plano grátis da Nova Uptime pode monitorar microsserviços:

Health checks de serviço: Monitore endpoints de health de cada serviço
Monitoramento de API: Acompanhe tempos de resposta e taxas de erro
Monitoramento de Webhook: Verifique a comunicação entre serviços
Monitoramento de e-mail: Verifique se o serviço de notificação está entregando os e-mails
Monitoramento de API pública: Se os serviços expõem APIs públicas

Para um monitoramento abrangente de microsserviços, use ferramentas especializadas (Prometheus, Datadog, New Relic). Mas a Nova Uptime pode complementar isso monitorando a saúde de serviços externos e APIs voltadas para o cliente.

Resumo: monitoramento de microsserviços além do uptime simples#

Microsserviços exigem um monitoramento mais sofisticado que sistemas tradicionais.

Seu plano de ação:

Implemente endpoints de health check em cada microsserviço
Exponha métricas (endpoint /metrics para o Prometheus)
Adicione correlation IDs em todos os fluxos de requisição
Implemente circuit breakers para evitar falhas em cascata
Use logging estruturado com contexto da requisição
Monitore a comunicação entre serviços (latência, erros)
Monitore a infraestrutura Kubernetes (pods, nodes, deployments)
Configure tracing distribuído (veja o fluxo completo da requisição)
Crie dashboards por serviço (visibilidade de cada serviço)
Dispare alertas em degradação (não só em falhas completas)

Comece com a Nova Uptime para monitorar suas APIs voltadas para o cliente. Adicione monitoramento de health check. Complemente com Prometheus/Grafana ou um serviço gerenciado para um monitoramento de infraestrutura mais profundo.

Seus microsserviços são complexos. Seu monitoramento deve estar à altura dessa complexidade.

Monitorando microsserviços e Kubernetes: além dos checks de uptime simples