13 indicadores de saúde de microsserviços para monitorar

A saúde de uma arquitetura de microsserviços não se resume a saber se o serviço está no ar. Para operar de forma confiável, precisamos de indicadores que revelem comportamento, tendências e gargalos. Baseados nos quatro sinais de ouro da engenharia de confiabilidade (latência, tráfego, erros e saturação), selecionamos 13 métricas que todo time deveria acompanhar. Cada uma responde a uma pergunta específica sobre o sistema, e juntas formam um painel de controle útil para decisões rápidas e planejamento de capacidade.

1. Disponibilidade (uptime)

É o percentual de tempo em que o serviço responde corretamente. Uma disponibilidade de 99,9% parece alta, mas em um mês isso representa quase 43 minutos de indisponibilidade. Acompanhe por serviço e por endpoint crítico.

2. Latência de requisições

Mede o tempo entre o envio da requisição e a resposta. Mais importante que a média é o percentil 95 ou 99, pois revela a experiência dos usuários mais afetados. Uma latência média baixa pode esconder picos pontuais.

3. Taxa de erros

Percentual de requisições que retornam status 5xx ou falham por timeout. Erros de 1% podem parecer baixos, mas em um serviço com 1 milhão de requisições diárias isso significa 10 mil falhas por dia.

4. Saturação de recursos

Mede o quão perto o serviço está do limite de CPU, memória, disco ou conexões. Quando a saturação passa de 80%, a latência tende a crescer exponencialmente. Esse indicador ajuda a planejar escala antes da degradação.

5. Throughput (requisições por segundo)

Número de requisições que o serviço processa em um intervalo. Queda repentina pode indicar problema de roteamento ou de dependência. Aumento sustentado pode sinalizar necessidade de escalar.

6. Saúde de dependências

Microsserviços raramente trabalham sozinhos. Monitore a latência e erros de cada chamada a outro serviço ou banco. Uma dependência lenta pode derrubar uma cadeia inteira de requisições.

7. Tamanho da fila de mensagens

Se o serviço usa mensageria, o acúmulo de mensagens na fila indica que o consumidor não está dando conta. Fila crescente sem aumento de produção é um sintoma clássico de gargalo.

8. Taxa de reinicialização de pods/containers

Número de vezes que um container reinicia em um período. Reinicializações frequentes podem indicar crash por falta de memória, health check mal configurado ou bug de inicialização.

9. Utilização de CPU e memória por instância

Acompanhe o consumo médio e máximo por instância. Picos constantes de memória podem causar OOM kill. CPU acima de 90% por longos períodos afeta a latência diretamente.

10. Acurácia dos health checks

Um health check que responde 200 mesmo com o serviço degradado é pior que nenhum. Valide se o endpoint de saúde realmente exercita dependências essenciais e se responde rápido.

11. Tempo de resposta do banco de dados

Consultas lentas no banco são causa comum de degradação em microsserviços. Monitore o tempo de query por serviço e o número de conexões abertas. Um índice ausente pode derrubar um serviço inteiro.

12. Rastreamento distribuído (trace)

Acompanhe o tempo gasto em cada etapa de uma requisição que atravessa vários serviços. Um trace mostra onde está o gargalo: se no serviço A, na chamada ao B ou no banco. Sem ele, é difícil provar qual serviço é o culpado.

13. Custo por requisição

Relacione o custo de infraestrutura com o volume de requisições processadas. Se o custo sobe mais que o tráfego, há ineficiência. Esse indicador conecta a saúde técnica com a saúde financeira do produto.

Como escolher os indicadores certos para o seu caso

Se o time está começando, priorize os quatro sinais de ouro: latência, erros, tráfego e saturação. Eles cobrem a maior parte dos incidentes. Depois, adicione indicadores específicos do seu domínio, como fila de mensagens e custo por requisição. O importante é começar com poucos indicadores bem compreendidos do que muitos que ninguém olha. Lembre-se: monitorar é uma maratona, não um tiro curto.

FAQ

O que é a saúde de um microsserviço?

Saúde de um microsserviço é a capacidade de processar requisições de forma correta e dentro do tempo esperado, sem degradação de performance. Envolve não apenas estar no ar, mas também ter latência aceitável, baixa taxa de erros e recursos suficientes para operar.

Qual a diferença entre health check e métricas de saúde?

Health check é um endpoint simples que indica se o serviço está vivo e pronto para receber tráfego. Métricas de saúde são dados contínuos de latência, erros, saturação e throughput, que permitem ver tendências e prever problemas.

Quantos indicadores devo monitorar por serviço?

Comece com 4 a 6 indicadores por serviço, priorizando os sinais de ouro. Adicionar métricas demais no início gera ruído e dificulta a interpretação. Aumente a cobertura conforme o time ganha maturidade em observabilidade.

Como saber se a latência está boa?

Não existe um valor universal. O ideal é comparar com o SLA do serviço e com o histórico da própria aplicação. Uma latência que dobra em relação à média da última semana é um sinal de alerta, mesmo que o número absoluto pareça aceitável.

O que fazer quando um indicador está fora do esperado?

Primeiro, verifique se é um pico pontual ou uma tendência. Se for tendência, investigue a causa raiz: dependências, banco de dados, deploy recente ou saturação. Depois, ajuste a capacidade ou o código, e monitore o efeito da mudança.

Ferramentas de monitoramento são obrigatórias?

Sim, para microsserviços em produção é inviável acompanhar indicadores manualmente. Ferramentas como Prometheus e Grafana, ou soluções gerenciadas, automatizam a coleta e exibição das métricas. Escolha uma que se integre bem ao seu ecossistema e que o time consiga operar.