Monitorar para quê?

Monitorar para que?

No dia a dia que é muito comum se deparar com a indisponibilidade de diversos sistemas como caixas eletrônicos, apps, sistemas de farmácias e sites. A consequência dessa indisponibilidade costuma ser uma venda não realizada, uma transação perdida, e o prejuízo decorrente de um software funcionar parcialmente ou não funcionar costuma ser bastante significativo para as empresas. Além disso, quanto mais indisponível um sistema for, menos confiável e aceito por seus usuários ele será. 

Diante deste cenário podemos refletir: se os sistemas podem ficar indisponíveis, será que não poderíamos atenuar ou, pelo menos, prever quando isso estivesse prestes a acontecer? Ao se deparar com essa problemática, quais seriam os passos e medidas que deveríamos trilhar para evoluir os sistemas?  

 

Monitoramento versus observabilidade

Da mesma forma que um médico examina um paciente, assim temos que examinar um software. Por meio de uma consulta/exame, o médico consegue avaliar se os dados obtidos estão dentro do valor esperado. Em uma fórmula análoga, também podemos medir um software e identificar sinais de que ele “ficará doente”. Para isso, podemos monitorar/observar o que o software “fala” (suas saídas). 

O monitoramento é a forma concreta de se visualizar onde algo pode estar errado (no software) e confirmar se o sistema está funcionando corretamente. Podemos tanto monitorar um software em si como também um próprio servidor/contêiner, etc. Antes de sair e observar tudo, precisamos ser assertivos e saber o que temos que monitorar, pois com o monitoramento adequado podemos reduzir e atenuar falhas. 

Imagine inúmeras pessoas realizando transações financeiras por meio do PIX e, por alguma razão, um determinado banco deixou de operar pagamentos e recebimentos via PIX. Uma vez monitorado, o determinado banco poderá alertar seus clientes que o problema ocorreu e que medidas reparatórias estão sendo executadas a fim de mitigar maiores prejuízos, como permitir um fallback de agendamento do PIX. O monitoramento é importante, pois traz insumos suficientes e nos dá uma visão ampla e específica de um possível problema.  

Até aqui ficou claro que o monitoramento é a forma de visualizar onde um determinado problema está acontecendo. Porém, temos também a observabilidade. A observabilidade não exclui o monitoramento, ela simplesmente o complementa. A principal diferença dela em relação ao monitoramento é que ela mostra como o problema que está acontecendo, enquanto o monitoramento nos mostra onde. Através da visualização do problema, conseguimos colocar uma lupa para realizar uma análise mais aprofundada e entender o que aconteceu. Ou seja, temos um número maior de dados para uma melhor tomada de decisão.  

 

Pilares da observabilidade

Basicamente, a observabilidade é construída sob três pilares: logs, métricas e rastreamentos. Abaixo, explicarei melhor cada um deles: 

• Logs
  Se você já ouviu falar sobre logs, deve imaginar que ele possui alguma relação com a Segurança da Informação e rastreabilidade. Eles são essenciais para encontrar inconsistências e anomalias em sistemas. Em resumo, os logs são eventos imutáveis, gerados de forma cronológica, com uma espécie de carimbo de tempo. Comumente, podem ser desestruturados (texto simples), estruturado (como um json) e binário. Geralmente, o armazenamento é feito utilizando arquivos, mas também é comum ver esse tipo de histórico gravado em estruturas como um banco de dados (centralizado). 

Figura 1 – Obs. Diagramar uma imagem semelhante, exemplificando uma ideia de monitoramento

 

Se você já programou alguma vez, mesmo que uma simples função, provavelmente precisou dar um “print” no console ou exibir o seu resultado em um pop–up. Como o exemplo, de multiplicação abaixo. 

Figura 2 –  Função básica de cálculo

 

Entretanto, apesar de um simples “print” ajudar, não trará muitas informações. Para isso, podemos utilizar bibliotecas de logs (Log4J, por exemplo) que podem oferecer um carimbo de tempo, níveis de criticidade e persistir tais informações em console, arquivo texto e até em banco de dados. Para exemplificar, abaixo temos o mesmo código escrito com uma biblioteca de logs: 

Figura 3 – Adicionando variável log.

Figura 4 – Log da chamada no console da aplicação

 

Obviamente, é um exemplo simples, porém o conceito é importante.  Neste caso, o log estará disponível somente no contexto da aplicação, assim que ela for finalizada a variável log será perdida. Como disse no início, é importante que esse log seja armazenado em arquivos ou outra estrutura específica. Uma biblioteca de log em si não faz todo o serviço, ela também necessita de outras ferramentas para completar o monitoramento de forma centralizada e organizada. 

Os logs não estão presentes simplesmente em softwares. Eles podem ser usados em: contêineres, banco de dados, sistemas operacionais, etc. Por exemplo, um software de antivírus pode manter exatamente o que aconteceu durante a última varredura do sistema, como no Windows que mantém todos os tipos de arquivos de log – falha de hardware, atualizações de aplicativos e erros de autenticação. 

Então, a principal utilidade de um arquivo de log é acompanhar exatamente o que está acontecendo nos bastidores do sistema e, se algo inesperado acontecer, você terá disponível uma lista de ocorrências de tudo o que aconteceu, antes e depois do comportamento inesperado. 

Figura 5 – busca de informações.

 

Conforme o sistema evolui, surge a necessidade de se utilizar logs para monitorar funcionalidades de negócio, mensagens de alerta, etc. Resumindo, é possível criar log de praticamente tudo, desde uma autenticação de usuário, IP, data e hora se tornando um poderoso histórico de rastreabilidade. 

Por outro lado, é necessário se atentar quanto ao uso demasiado de logs no sistema, porque despende muito tempo no processo de utilizar estruturas de I/O entrada e saída (arquivo/banco). 

 

• Métricas (sistêmicas e de negócio)

As métricas são uma representação numérica de dados (quantitativos e qualitativos) obtidos dentro de um intervalo de tempo. Seu objetivo é refletir o estado do software de maneira mais compreensível (visual), geralmente em forma de relatórios ou dashboards com gráficos. Tudo isso, com base no auxílio de dados oriundos dos logs e outras informações. 

As métricas podem ser originadas do sistema e da infraestrutura na qual a aplicação está contida (máquinas, contêineres, orquestradores, etc). Como exemplo, é possível analisar a capacidade de armazenamento, uso de processador (CPU), porcentagem de memória utilizada, etc. As métricas permitem uma retenção de dados mais longa, no qual pode-se refletir a tendência histórica dessas informações. Além disso, tais dados podem ser explorados na dimensão tempo, podendo ser agrupado em dias, meses, anos, etc. 

Com base nas informações, é possível analisar a causa raiz da indisponibilidade/instabilidade do sistema, ter uma tomada de decisões mais assertiva e evitar que tais imprevistos ocorram novamente em cenários semelhantes. 

 

• Tracing

Por fim, temos o último pilar da observabilidade. O tracing é a capacidade de investigar a rota completa (do início ao fim) de uma determinada requisição/transação através de todo o sistema. Se é difícil observar todo o percurso em sistemas monólitos, imagine a complexidade que é em sistemas distribuídos (como micros serviços). Através do rastreamento podemos responder, por exemplo, questões como: quais serviços foram utilizados? Quanto tempo foi gasto em cada um deles? Qual o formato da requisição/chamada? Em qual chamada houve uma exceção?, etc. 

Em resumo, a rastreabilidade no sistema é feita no início da requisição. Nele é criado um identificador único (uuid) que será propagado para cada passo seguinte. Cada passo pode adicionar informações importantes e repassar também esse id para a próxima requisição, assim sucessivamente até chegar ao final. Podemos pensar em um fluxo (chamada entre sistemas) que contêm processamentos em paralelos (threads), lineares, etc. Para representarmos esse caminho, podemos desenhá-los como grafos direcionados acíclicos. 

Figura 6 – Fonte: oreilly.com

Abaixo, é possível perceber como o tracing pode ser aplicado em cada passo, demonstrando possíveis gargalos na aplicação. Ou seja, desde o início da requisição até o fim. 

Figura 7 – Fonte: https://www.oreilly.com/library/view/mastering-distributed-tracing/9781788628464/ch03s03.html

 

Boas práticas e ferramentas

Para ajudar a você a entrar no mundo de monitoramento e observabilidade, nesta seção pretendo mostrar boas práticas para o uso de logs assim como também apresentar as principais ferramentas para o monitoramento e observabilidade. 

1. Use ferramentas/bibliotecas: existem diversas bibliotecas para diversas linguagens de programação (para Java, por exemplo, tem-se Slf4j, Log4, etcj );

2. Defina um nível de criticidade conforme o aviso desejado: podemos filtrar (via configuração) os logs de acordo com o nível. Por exemplo, podemos salvar em arquivo todos os logs de informação e os logs de erro salvar em banco de dados. Geralmente, os níveis podem ser definidos como: ERROR (determina uma atenção imediata, de modo geral os softwares não toleram esse nível), WARN (pode ocorrer uma falha, mas o fluxo do processo continua), INFO (são informações relacionadas o negócio ou algo dado que seja interessante para o monitoramento), DEBUG (informações voltadas para o desenvolvedor, onde pode-se dar mais detalhes do fluxo/processo). 

Figura 8 – exemplo de uso de níveis e criticidade por meio da Slf4j em Java.

 

3. Evite os efeitos colaterais: os logs não podem gerar erros, por exemplo. Imagine você criar um log que exiba um campo de um objeto que está nulo (cliente.getName). Ou seja, quando o fluxo passar sobre o log o mesmo irá disparar uma exceção. Uma boa prática é inserir o log após alguma verificação (verificar se o objeto cliente está preenchido). Além disso, o log não deve consultar I/O (arquivos, banco de dados, etc), isso pode pesar o processamento, tornando o software mais lento.

Figura 9 – cenário que o objeto ClienteDTO recebe null ao longo do código e posteriormente há um log tentando acessar o atributo nome. Com certeza o nosso log vai ocasionar um erro.

 

4. Mantenha as mensagens padronizadas e bem descritivas: devemos sempre ter em mente que as mensagens vão agregar valor, então, deixar uma mensagem o mais limpa e clara possível (tanto para pessoas de negócio como desenvolvedores), facilitando assim o monitoramento. Veja no exemplo abaixo (dependendo da biblioteca) você pode inserir dados sem concatenar strings, deixando a leitura mais fácil. Além disso, é necessário definir um padrão de mensagem, ou seja, todos em português/inglês. Assim como definir padrões de mensagens que podem facilmente se enquadrar em expressões regulares, etc.

Figura 10 – ao invés de concatenar strings com uso do “+” podemos usar o próprio recurso da biblioteca. Onde, cada colchete é dado representado, respectivamente, após a vírgula.

 

1. Cuidado com sistemas externos: como não temos acesso ao código de terceiros, temos que nos precaver inserindo logs de informações que foram passadas para aplicações externas e logs de informações que foram recebidas. Desta forma, você poderá mapear quais dados podem estar errados.
2. Registre as exceções de forma correta: não simplesmente coloque um stacktrace (pilha de erros), pois fica difícil saber quais informações geraram aquela exceção. Coloque também alguma informação textual, mostrando quais dados geraram aquele erro.

É imprescindível monitorar e observar o nosso software. Contudo, é possível utilizar softwares para auxiliar nesse processo. Eles geralmente são chamados de APM (Application Performance Monitoring), ou seja, monitoram o desempenho do sistema. A seguir, é apresento um resumo das principais ferramentas do mercado: 

 

Gerência e centralização de Logs
ELK: ElaticStack https://www.elastic.co/pt/elastic-stack/	ElasticSearch (mecanismo de pesquisa e análise de dados distribuídos baseado em JSON), LogStash (processamento de coleta de dados) e Kibana (dashboard de visualizações).
Splunk https://www.splunk.com	Captura e indexa os dados. Também é possível gerar relatórios, gráficos e alertas.
Graylog https://www.graylog.org	Baseada em Elasticsearch e MongoDB. Permite a captura e armazenamento.
Monitoramento de infraestrutura
Grafana https://grafana.com	Dashboard para fornecer visualizações de métricas temporais. Geralmente, é usado com Prometheus, Zabbix, Elasticsearch, Splunk, etc.
Zabbix https://www.zabbix.com	Pode-se monitorar rede, servidores, aplicações e nuvem.
Prometheus https://prometheus.io	Coleta métricas, avalia expressões de regras, criação de alertas de acordo com condições.
DataDog https://www.datadoghq.com	Monitoramento de infraestrutura, aplicações, banco de dados e servidores com base na nuvem. Oriundo do Apache Cassandra, PostgreSql e Kafka.

 

Não necessariamente os APMs são utilizados de forma solitária, eles podem ser integrados uns com os outros. Além dessas ferramentas, podemos também citar todo o controle (monitoramento e observabilidade) as quais são oferecidos dentro de plataformas em nuvem como AWS, Azure e Google Cloud. 

Após este conteúdo espero que tenha ficado claro o motivo pelo qual é necessário monitorar sistemas. Não é porque não temos confiança na qualidade do código que escrevemos ou convicção de que o que foi entregue não vai falhar ou ficar indisponível, mas uma questão de mitigar falhas, segurança e de melhoria contínua.  

 

Referências:

https://azure.microsoft.com/pt-br/products/monitor/#overview, https://cloud.google.com/products/operations?hl=pt-br,  https://aws.amazon.com/marketplace/pp/prodview-5pfjq5sbn5sw4, https://aws.amazon.com/pt/blogs/devops/tag/app-performance-monitoring-apm/