A nova geração de softwares adquiriu responsabilidades importantíssimas que estão presentes no nosso cotidiano desde sistemas financeiros à saúde. Para falarmos de confiabilidade, antes, precisamos entender se a aplicação está “saudável” e sua capacidade de operação.

Os sistemas atuais precisam ser confiáveis tanto em código quanto em operação. Para melhorarmos cada vez mais a confiabilidade em nossos sistemas começamos a buscar soluções, estratégias e inspirações já consolidadas.

Levamos em consideração a indústria aeronáutica e a automotiva de competição como a Fórmula 1. Mas, por que essas escolhas?

A preocupação com a confiabilidade está no sangue de qualquer fabricante de aviões. Afinal, é preciso garantir a segurança de todos os passageiros que embarcarem em suas aeronaves. O mesmo acontece na Fórmula 1. Mecânicos e engenheiros precisam se preocupar tanto com a segurança dos pilotos quanto com a confiabilidade e desempenho dos carros.

Começamos a trazer essa preocupação para o nosso time de desenvolvimento. Foi nesse momento que precisávamos entender que o software não termina ao fazer uma entrega para um ambiente produtivo. Devemos sempre considerar toda a operação que acontece durante o uso de software.

Esta operação nos ajuda cada vez mais a entender e acompanhar a operação do produto e a tomar decisões rápidas.

Para nosso time, a confiabilidade começa na hora de escrever os algoritmos que compõem a aplicação, testes unitários e integrados eficientes, um sistema de CI e CD, logs eficientes e uma boa estratégia de coleta e visualização de métricas.

monitoria em outras indústrias

Exemplo de monitoria em outras indústrias

 

Exemplo de monitoria em outras indústrias

 

Com testes unitários e integrados eficientes, nós conseguimos ter uma confiança maior na versão do produto que irá para produção. Com uma monitoria eficiente em tempo real da solução, nós temos confiança na utilização do software por milhares de clientes. Através da telemetria, nós conseguimos visualizar pontos de falhas e de otimizações do produto, e assim, deixamos nosso sistema melhor e mais confiável.

Para começarmos a montar uma stack de monitoria, nós tínhamos uma única premissa: todas as ferramentas deveriam ser open source. A partir disso, selecionamos algumas ferramentas:

  • InfluxDB: Usamos o InfluxDB como base de dados temporal para armazenar métricas.
  • Telegraf: O Telegraf atuou como agente de coleta de métricas da máquina de modo geral.
  • Grafana: Foi a ferramenta de visualização e criação de dashboards e ela se integra diretamente com o InfluxDB. Também utilizamos o Grafana como nossa stack de telemetria para nosso projeto piloto.

 

Além dessas, criamos uma pequena ferramenta de coleta de métricas para aplicações em Go, também disponibilizada de forma open source, que se integra ao InfluxDB.

Com a chegada da Black Friday, os sistemas de e-commerce são levados ao extremo de sua operação devido ao grande volume de transações. Isso pode ocasionar em aplicações pouco robustas, lentidão ou até mesmo na queda do serviço.

A preparação para grandes eventos como este começa na análise do status da aplicação “em vôo” e na saúde do software durante a operação contínua através do acompanhamento das métricas de operação.

Conhecendo bem como sua aplicação opera, é possível dimensionar, caso necessário, o hardware para suportar maior volume de transações.

Nossa Stack de Telemetria

A base da nossa stack é o InfluxDB, ele é o banco de dados responsável por armazenar todas as leituras da aplicação que foram coletadas. Esta base de dados foi construída para suportar grande volume de leitura e escrita de dados, especificamente para dados temporais. É ideal para monitoramento de infra-estrutura, métricas, dados de sensores e análises em tempo real.

A vantagem do InfluxDB é política de retenção de dados que nos permite manter o armazenamento de apenas informações relevantes. Isso evita o desperdício de recursos de máquina.

Para a coleta de informações da máquina, onde a aplicação fica hospedada, nós usamos o Telegraf. Nesse caso, usamos o Telegraf como um agente para coletar e reportar informações básicas para o InfluxDB.

Para a visualização de dados usamos o Grafana, que possui diversos plug-ins e gráficos que facilitam a visualização de todos os nossos indicadores. Todas essas ferramentas foram configuradas para serem executadas a partir de containers no Docker.

Temos basicamente dois “cockpits”:

  • O primeiro serve para métricas de infraestrutura que contém informações sobre processador, memória geral da máquina, uso de disco, entre outros;
  • O outro serve para métricas exclusivas da aplicação em execução.

A primeira é importante para sabermos como está a situação de uma máquina que pode hospedar uma ou mais aplicações. A segunda está ligada diretamente com as variáveis de tempo de execução da aplicação e de negócio, tais como:

  • O primeiro serve para métricas de infraestrutura que contém informações sobre processador, memória geral da máquina, uso de disco, entre outros;
  • O outro serve para métricas exclusivas da aplicação em execução.

A primeira é importante para sabermos como está a situação de uma máquina que pode hospedar uma ou mais aplicações. A segunda está ligada diretamente com as variáveis de tempo de execução da aplicação e de negócio, tais como:

Memória que está sendo usada pela aplicação

Este indicador é importante para dimensionarmos o volume de transações que podemos ter ou esperar em situações adversas e até mesmo identificar possíveis problemas de “memory leak” na aplicação analisando o consumo em relação ao tempo que a aplicação esteja rodando.

Número total de Goroutines

Esta é uma boa métrica para sabermos o nível de esforço da aplicação já que cada requisição é executada por uma goroutine. Além disso, podemos saber se a aplicação está liberando recursos conforme planejado.

Número de transações realizadas com sucesso em um determinado período de tempo

Monitorar o número de transações realizadas lhe dará uma visão sobre o funcionamento da sua aplicação e se os clientes estão conseguindo usar a aplicação com sucesso. Isso é importante principalmente nos instantes após a realização de um deploy em produção. Este número é discriminado, no nosso caso, por banco onde fazemos o registro de boletos.

Número de transações de erro

Monitorar quantas transações de erro estão ocorrendo em um determinado período de tempo ajuda a descobrir algum bug que não foi pego na etapa de testes integrados ou se alguma dependência externa está com falha ou intermitência nos serviços. Discriminar o tipo de erro da aplicação, se é um erro de entrada do usuário ou um erro mais grave na aplicação ou de integração também é importante para evitar falsos positivos.

Tempo de resposta da aplicação

O tempo de resposta também é muito importante pois além de estar atrelada diretamente com a experiência do usuário na sua aplicação, ela pode também ser um indicador da saúde de sua aplicação, tanto do ponto de visto de código e qualidade de algoritmos, quanto do ponto de vista de processo do sistema operacional. Se sua aplicação se integra com outras aplicações externas, também é interessante discriminar o tempo de resposta total e o tempo de resposta de serviços externos. Tempos externos influenciam diretamente o tempo de resposta geral da sua aplicação e podem ser responsáveis por gargalos de performance. Na nossa solução de registro de boleto online, o tempo de resposta médio de cada integração é contabilizado de forma independente e, com isso, nós conseguimos saber qual é a integração que mais impacta no tempo total de resposta.

Handshake da aplicação

O Handshake é um processo contínuo que roda junto com a aplicação que testa de tempos em tempos se todas as dependências externas e internas da aplicação estão respondendo. Caso alguma dependência apresente um problema podemos agir rápido na resolução do mesmo.

Cockpit da aplicação executando em ambiente simulado usando o Grafana.

 

Conclusão

O processo de telemetria usando a stack InfluxDB + Grafana vem se mostrando promissora tanto do ponto de vista de implantação, que é muito simples usando o Docker, quanto da visibilidade do estado da aplicação em execução. Saber o comportamento de sua aplicação em tempo real, ajuda a responder rápido a problemas bem como nos orienta em melhorias e otimizações de código. A monitoria nem sempre é levada em consideração quando se está montando uma aplicação, porém com esse artigo queremos mostrar que ela pode ser essencial para a qualidade e disponibilidade de seu produto.

Paulo Lima e Philippe Moneda

Paulo Lima e Philippe Moneda

Paulo e Philippe trabalham juntos na MundiPagg:

Paulo é desenvolvedor C# e Golang e formado em análise e desenvolvimento de sistemas e apaixonado por tecnologia.

Philippe é desenvolvedor backend e trabalha com desenvolvimento de software atualmente nas linguagens C# e Go, gosta de contribuir com projetos no GitHub e não dispensa uma jogatina no PS4.
Paulo Lima e Philippe Moneda

Últimos posts por Paulo Lima e Philippe Moneda (exibir todos)

Quer receber as novidades de e-commerce em primeira mão?

x