Métricas customizadas com Micrometer no SpringBoot

Artigo escrito por Gabriel Prestes e Thamires Tissot

Dividimos um pouco sobre nossa experiência como dois ilegranos, das áreas de infraestrutura e desenvolvimento, inseridos no dia a dia do mercado varejista e de um time de site reliability engineer (SRE). Implantamos métricas customizadas para monitorar o ciclo de vida de um pedido, atendendo às necessidades de negócio e utilizando padrões para manter a solução sustentável aos times de desenvolvimento.

A história

Com o uso mais frequente de microsserviços, e a arquitetura baseada em eventos (mensageria), métricas de aplicações são importantes para que saibamos status básicos dos componentes. Tais componentes, por vezes, encontram-se distribuídos em vários clusters, orquestrados em contêineres, que dificultam e alteram o modelo tradicional de monitoramento de indicadores operacionais das aplicações. 

Assim, perguntamos a seguir : Métricas básicas de aplicações, tais como threads, requests, tempo de resposta, são suficientes para atender a necessidade de negócio? Esse é o tema que vamos aprofundar, mostrando como gerar métricas customizadas em uma aplicação SpringBoot 2.x. 

O monitoramento básico de componentes computacionais e de aplicação não são suficientes, e não será o nosso alvo. Reconhecemos que alguns indicadores ainda são relevantes ao time de infraestrutura, mas apresentar ao business owner (BO) tais indicadores não agrega valor e são tratados como commodity.

Necessidade

Fazemos parte de um time site reliability engineer (SRE), que orienta soluções aderentes aos times de desenvolvimento. A demanda recebida baseava-se em apresentarmos dashboards de negócio com o ciclo do pedido, um monitoramento capaz de produzir alertas quando um determinado pedido não evoluísse de estado em um determinado intervalo de tempo. 

Não podemos considerar sempre a criação de novos modelos, ou como se diz, reinventar a roda, até mesmo pela importância de estabelecermos e após mantermos um padrão independente da stack de telemetria/monitoramento em uso. Com isto, ao decorrer do tempo, observamos que em um módulo de negócio dos quais atendemos com diversos microsserviços, uma stack de telemetria se destacava pelo uso de um padrão como procurávamos, em sua estabilidade e simplicidade de implementação. 

Deixamos aqui os méritos ao Marco Pokorski Stefani que implantou o padrão, ao Douglas Rossi o qual estendeu em métricas customizadas de negócio, e ao César Mesquita responsável pela concepção de arquitetura de telemetria do módulo.

Stack  

  Componentes: 

Fluxo de funcionamento

Utilizamos soluções de continuous integration (CI), continuous deployment (CD) do cloud provider[1], onde durante o processo de publicação descritores, testes e dependências são satisfeitas em uma esteira[2]. Veja que em um ambiente distribuído não podemos concentrar o monitoramento no modelo tradicional, pois hora estaremos com 1 réplica da aplicação ativa, e outrora com mais, valores que são controlados pelo horizontal pod autoscaler (HPA)[3]. 

Dessa forma, cada réplica enviará suas métricas ao InfluxDB[4], e por fim estes dados serão consolidados com o uso do Grafana[5], este responsável pela apresentação, agregação e produção de alertas para os times.

Atualmente, para envio de algumas métricas ainda não customizadas diretamente na aplicação, utilizamos coletores externos que coletam os dados de origens distintas, tais como message broker, data lakes. Esses coletores implementam mesma stack citada. Segue exemplo de funcionamento do e gatilhos para os alertas: o coletor analisa um grupo de dados, onde há uma atualização para cada evento de compra. Para cada compra, será incrementado o contador do estado atual correspondente. Quando o coletor analisar todas as atualizações de compras, fará o download de mais X atualizações de compras.

No Grafana, alertas são gerados quando:

• O número de pedidos que estão ou já estiveram  no estado “solicitado” for menor do que o número de pedidos que estão ou já estiveram no estado “computado”;
• O número de pedidos que estão ou já estiveram  no estado “embrulhado” for menor do que o número de pedidos que estão ou já estiveram no estado “pago”;
• A somatória de pedidos que estão ou já estiveram no estado “pago” e “embrulhado” for menor que o número de pedidos que estão ou já estiveram no estado “disponível”;
• O número de pedidos que estão ou já estiveram no estado “disponível” for menor que o número de pedidos que estão ou já estiveram no estado “entregue”.

Implementação

Iniciamos pela descrição breve do Actuator, uma simples que satisfaz o que precisamos aqui é de uma publicação no Medium que segue: 

“É uma biblioteca do próprio Spring para coletar métricas, entender o tráfego e o estado da aplicação.” 

Assim como o Actuator, o envio de métricas utilizando o Micrometer é gerenciado pelo SpringBoot, logo não precisamos nos preocupar com dependências para métricas padrão do Actuator. Para implantarmos o Actuator, devemos adicionar a dependência ‘spring-boot-starter-actuator’ ao projeto, seja ele Maven ou Grandle. Após, inclua no bootstrap, config-server o seguinte em seu YAML:

Properties config-server ou bootstrap:

Classe de exemplo de métrica customizada:

O uso da classe, deve ser realizado por interação na implementação dos estados do pedido. Com isto, poderemos gerar alertas do total de pedidos e pedidos inválidos tanto por razões de negócio, quanto no caso de alguma ordem que não alterou seu estado em determinado tempo.  

O framework permite o uso de outros tipos de métricas, tais como gauge, histogram, entre outros. Permite também, enviar métricas para outras soluções como Elastic, Datadog e Dynatrace. O importante para métricas customizadas é saber o tipo de dado e métrica que irá expor. 

Para maiores detalhes acesse: https://micrometer.io/docs/concepts#_meters

Conclusão e atualidade

Conforme citado anteriormente, nem todas as aplicações geram métricas customizadas em tempo de execução. Por isso, ainda não recebemos as alterações de estado no tempo em que ocorrem, precisando assim fazer uso de outros coletores com delay (atraso), consultando também dados analíticos, e observando a interação de eventos em um message broker. 

Ainda assim, o product owner (PO) responsável pelos módulos está vinculado às novas entregas do produto stories, que incluem a implementação de métricas customizadas como critério de aceitação, para que futuramente os coletores não sejam necessários. 

Fontes

• https://medium.com/projuristech/monitorando-uma-aplicação-spring-boot-2-x-cef826ae793c
• https://medium.com/projuristech/monitorando-uma-aplica%C3%A7%C3%A3o-spring-boot-2-x-fc939257db8e?
• https://www.baeldung.com/micrometer
• https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

Sobre os autores

Gabriel Prestes, formado em Gestão da Tecnologia da Informação, DevOps Engineer da ilegra, é um entusiasta de carros antigos que cultiva em sua garagem um Gurgel Supermini funcionando.

Thamires Tissot, estudante de Analise e Desenvolvimento de Sistemas, Desenvolvedora na ilegra e ceramista nas horas vagas.