terça-feira, 7 de janeiro de 2020

SpringBoot - Métricas customizadas com Micrometer






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ásico 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 suficiente 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 agregam valor e são tratados como comodity.


Necessidade:


Fazemos parte de um time site reliability engineer (SRE), o qual orienta soluções aderentes aos times de desenvolvimento, e a demanda por nós recebida foi de 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, sua estabilidade e simplicidade de implementação. 


Deixamos aqui os méritos ao Marco Pokorski Stefani (https://www.linkedin.com/in/marcops) que implantou o padrão, ao Douglas Rossi (https://www.linkedin.com/in/douglasrossi) o qual estendeu em métricas customizadas de negócio, e ao César Mesquita (https://www.linkedin.com/in/cmesquita00) responsável pela concepção de arquitetura de telemetria do módulo.

Stack:  





  Componentes: 
Infraestrutura
Aplicação
SpringBoot (https://spring.io/)


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. Tais coletores implementam a mesma stack citada: Segue exemplo de funcionamento do e gatilhos para os alertas:


O coletor analisa um grupo de dados, em que para cada evento há uma atualização 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 (https://medium.com/projuristech/monitorando-uma-aplica%C3%A7%C3%A3o-spring-boot-2-x-cef826ae793c) 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ões do Actuator. 


Para implantarmos o Actuator devemos adicionar a dependência ‘spring-boot-starter-actuator’ ao projeto. Seja ele Maven ou Grandle. Após isto inclua no bootstrap, config-server o seguinte em seu YAML:


Properties config-server ou bootstrap:

management:
  metrics:
    export:
      influx:
        db: db_dev (aqui é a database onde serão persistidas as métricas do Actuator)
        uri: http://127.0.0.1:8086 (coloque aqui a URL do InfluxDB do seu ambiente)
        step: 1m (intervalo de envio)
        enabled: true


Classe de exemplo de métrica customizada:
package org.athome.example.metrics;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import org.athome.example.model.Order;
import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;

@Component
public class OrdersCustomMetrics {

@Autowired
private MeterRegistry registry;
public void CounterOrder(Order order, String reason) {
Counter.builder("Orders")
  .description("counter of orders")
  .tag("orderType", order.getOrder.Type())
  .tag("reason", reason)
  .tag("Id", order.getOrderId())
  .register(registry)
  .increment(1);
}
}





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



O framework também 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, Dynatrace. O importante para métricas customizadas é saber o tipo de dado e tipo de 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 isto, ainda não conseguimos receber as alterações de estados no tempo em que ocorrem, precisando assim fazer uso de outros coletores com certo 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á vinculando às novas entregas do produto stories que incluem a implementação de métricas customizadas como critério de aceitação para que não sejam necessários futuramente os coletores. 






Fontes







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.

Nenhum comentário:

Postar um comentário