Um dos principais problemas quando uma aplicação para de funcionar é encontrar e descobrir porque ela não está funcionando. Existem várias metodologias ou bibliotecas que fornecem ferramentas, nesse caso externas à aplicação, para verificar a saúde da aplicação e seus serviços.
Tentando resolver esse problema, alguns engenheiros do Google criaram uma metodologia chamada Healthz, onde a própria aplicação nos informa se ela está saudável ou não.
Esse <a href="https://vimeo.com/173610242">vídeo</a> do Kelsey Hightower fala bem sobre o assunto e eu recomendo bastante, mas vou citar brevemente o conceito e porque acho que seria uma prática interessante de se adotar. Vamos lá?
<h2>O que é Healthz?</h2>
Lembro de um dia na cozinha. Alguns colegas aqui da dti discutindo se a lâmpada deveria saber se trocar ou se outra classe precisaria implementar esse método.
O conceito de Healthz é semelhante. Deveríamos conectar &#8220;probes&#8221; para testar nossas aplicações ou as aplicações deveriam nos avisar se ela está saudável? Claro, essa pergunta visa levantar a curiosidade, podemos fazer os dois.
O que é o Healthz? Simples, um endpoint que existe na aplicação, que faz testes de sanidade, conexões ao banco de dados, serviços e etc. Ele nos retorna um status 200 caso tudo esteja ok, ou alguma outra &#8220;resposta&#8221; caso não esteja ok.
Esse endpoint pode ser desenvolvido dentro da aplicação ou ser encapsulado e publicado juntamente com ela.
O conceito é simples. O desenvolvimento vai desde simples testes com um status http 200 ou 500, até um JSON mais completo listando os erros encontrados, ou até mesmo uma interface, tudo depende da sua necessidade ou disponibilidade. O ponto aqui é que o simples status http 200 já valida a ideia e a torna de imensa utilidade.
<h2>Healthz 101</h2>
Um exemplo prático seria uma aplicação dti-wc. Um app maravilhoso que nos informa se o banheiro da empresa está vazio ou não. Essa aplicação possui um banco de dados SQL, um servidor Redis e dois serviços, o Alair e o Ademar. Alair e Ademar são serviços que informam se o banheiro está vazio ou não.
Além dos endpoints normais dessa aplicação, ela possui um endpoint healthz que se conecta ao banco e realiza um SELECT (só pra ver se está tudo ok), conecta-se ao Redis e faz um get, e realiza uma chamada ao Vanderlei e o Ademar para saber se a conexão com os serviços está ok. A aplicação retorna 200 ou um JSON informando se alguma dessas conexões falhar.
<img decoding="async" class="aligncenter size-full wp-image-2779" src="https://dtidigital.com.br/wp-content/uploads/2018/04/HiAppHere_com_toilet.samruston.com_.toilet.png" alt="" />
Em algum ponto no futuro algo na nossa aplicação para de funcionar e precisamos de informações para tentar entender por que. Nesse cenário, o primeiro teste seria chamar o endpoint healthz. Ao fazer isso, percebemos que por algum motivo recebemos a mensagem que o serviço do Ademar não está funcionando. Logo, não precisamos &#8220;perder tempo&#8221; verificando a aplicação em si e podemos validar o que aconteceu com o Ademar.
O mesmo acontece para o Banco, Redis ou o Alair, podemos verificar de maneira rápida a saúde da aplicação, e ter uma identificação, mesmo que simples, caso algum sistema esteja indisponível.
<h2>CI/CD com o Healthz</h2>
Uma outra vantagem do Healthz é que podemos incluí-lo no processo de CI/CD e impedir a publicação da aplicação caso o endpoint não retorne corretamente. Isso evita, por exemplo, que um dos ambientes fique fora do ar por um tempo até que o desenvolvedor responsável possa perceber que a aplicação não está saudável e realizar um rollback.
Olhando um caso específico do Kubernetes temos dois health checks disponíveis, livenessProbe e readinessProbe que podem ser utilizados com o Healthz. Ao configurar o readinessProbe para testar o healthz, caso o Kubernetes não receba uma mensagem de sucesso desse endpoint ele impede a publicação, mantendo o pod anterior online, tudo de forma automática e sem que o ambiente fique indisponível.
Da mesma forma, o livenessProbe pode ser utilizado para realizar testes com uma frequência X e testar se a aplicação está saudável.
Em breve vamos falar mais sobre Kubernetes, fique ligado!

Healthz, a sua aplicação está saudável?

Desbloqueie o futuro do seu negócio

Mais conteúdos como esse

Travessa Dona Zilda, 125, sala 203, São Gonçalo – Pelotas, RS. CEP: 96075-166

14841 Dallas Parkway, 8th Floor Addison, TX 75254

R. Levindo Lopes, 357, 5º e 12º Andar – Savassi, Belo Horizonte MG, 30112-010