Photo by Matt Collamer on Unsplash

Dando um novo uso ao healthCheck

Podemos usar os healthchecks muito além de simplesmente responder um 200 indicando que a aplicação está de pé. Podemos usá-los como uma fonte de informação e diagnóstico. Algo muito importante onde arquiteturas e sistemas são cada vez mais distribuídos.

O que é Healthcheck?

HealthCheck é um endpoint que geralmente criamos para indicar que a aplicação está “em pé” e funcionando.

Na maioria dos casos é ele responde com um HttpStatus 200 e um corpo com um texto simples (ex: WORKING, OK, etc).

Exemplo de uma chamada de healthcheck de uma aplicação minha

Para que serve

Essa urls são usadas, por exemplo, quando temos que fazer um balanceamento (distribuição das requisições por várias máquinas para aumentar a disponibilidade e vazão de atendimento). O servidor que faz o balanceamento usa o endpoint de healthcheck e sua resposta para determinar se aquela máquina está com o serviço disponível para receber requisições.

Exemplo de um balanceamento

A questão que levanto que com arquiteturas atuais onde várias serviços dependem de outros serviços e recursos, basta que o esse endpoint de healthcheck responda 200 para que tenhamos a garantia que está tudo funcionando?

Caso real

A uns dois dias atrás (contando da data que escrevi e publiquei esse post), um dos sistema que compõe o serviço de backend da empresa onde trabalho, começou a apresentar um tempo muito alta de resposta e com isso, em alguns casos, um “timeout” (tempo limite alcançado) e com isso muitos erros. O problema estava em outra aplicação que estava com um erro e lentidão.

Ao acionar o pessoal de operações, uma vez que esse serviço não faz parte do meu time — é um serviço externo — a resposta do suporte foi que estava tudo funcionando e que não tinha nenhum alarme. Levou mais de 4 horas e muitas trocas de e-mail para fazer com que entendessem que existia um problema e eles precisam atuar.

Depois, com mais calma, e graças eu conhecer e ter intimidade com o pessoal do outro sistema, fui querer entender o porque deles não terem nada avisando que tinha um problema — foi preciso um cliente avisar. Foi aí que descobri, que a resposta do suporte foi baseada no fato do healthcheck está respondendo.

Indo além do óbvio

A partir dessa história resolvi conversar com o meu time para entender se a gente não estaria cometendo o mesmo erro. De certa forma não, porque a gente acaba usando um serviço — New Relic — e ele nos dá uma visão muito mais ampla do nosso sistema e suas dependências.

Entretanto, com disse mais acima, os balanceadores, usam a url de healthcheck para decidir se mantem ou tiram uma máquina do pool. Com isso, caso algo falhe, mas o healthcheck esteja retornando sucesso, essa máquina irá continuar a receber request degrando a experiencia do nosso usuário, até que alguém veja o new relic e seus alarmes.

Foi aí que lendo alguns artigos, conversando com pessoas que conheço, vi que uma possibilidade era incrementar essa url de healthcheck e ir além do básico com ela: porque não usar essa chamada para analisar se tudo que preciso para aquele sistema está ok?

Vamos para a prática

Imagine que seu sistema seja algo que tenha um banco de dados. Seja ela qual for (NoSQL, SQL, grafos, etc). Considere também que esse sistema precisa também falar com outro sistema e por fim, tem ainda um busca que funciona em cima de alguma ferramenta de busca textual (solr, elasticsearch, e outros).

Note que para o seus sistema está 100%, ele precisa que o banco de dados esteja ok, o sistema externo esteja ok, o buscado esteja ok, etc.

Foi aí que mudamos um pouco a nossa logica de healthcheck.

Primeiro passo foi criar um novo endpoint: deixamos o healthcheck simples (status 200 OK com um working) e criamos um /info. Nessa chamada, a gente além de verificar algumas coisas do proprio sistema, a gente faz um teste simples em cada dependencia: no banco um query simples, uma chamada ao healthcheck do outro sistema, um ping no serviço de busca e por ai segue. Logo a resposta desse novo endpoint só seria ok, se tudo for ok.

Um bonus disso foi que quando tempos um problema, a gente consegue ver pelo endpoint criado, onde possivelmente pode ser o problema. Documentando, o operador de infra, pode até usar isso e evitar que seja acordado.

As possibilidades são enormes e a gente pensa em melhorar muito isso. Estamos pensado em colocar isso em todos os nossos sistemas e inclusive fazer com que periodicamente, esses dados sejam enviados para um serviço de alarme. Facilitando um acionamento antes mesmo que alguém esteja vendo o dashboard e evitando que nossos usuários sinta alguma indisponibilidade em nosso produto.

Gostou do conteúdo? Faça parte da lista que divulgo os posts e muitas mais conteúdo.