Como criamos análises e visualizações de logs utilizando AWS Lambda e o Quicksight
Exemplo real de como desenvolvemos essa arquitetura
Introdução
Quando uma aplicação é desenvolvida, muitas vezes as mensagens de logs são negligenciadas ou simplesmente inseridas em um arquivo gigantesco que só será resgatado quando algum problema em produção acontece. Lidar com logs deveria ser algo do cotidiano no ciclo de desenvolvimento de software, seja para acompanhar o uso da aplicação, para prever algum problema ou identificar erros.
Os usuários da AWS estão acostumados a visualizar os logs em serviços da própria provedora como o CloudWatch. Aqui na KeyCash, o time de Software Engineering desenvolve as API’s no AWS Lambda com o framework Serverless, inserindo todos os logs, por padrão, no CloudWatch.
Para o time de Data Science da KeyCash, algumas informações inseridas nestas logs e que vão para o CloudWatch são de suma importância para a tomada de decisão do time comercial e são cruciais para acompanhar a saúde das aplicações, assim como a evolução dos nossos produtos.
Como desafio, o time de Data Science precisa selecionar as informações relevantes nos logs de aplicações sem a necessidade de envolver o time de Software Engineering. Mas como fazer isso?
Na Keycash a cultura test and learn foi adotada desde o momento de criação da empresa. Algumas arquiteturas foram testadas, utilizando por exemplo Kinesis Data Firehose e Lambda Extensions API. Por fim, uma solução final foi desenvolvida, esta solução consiste em uma Lambda que monitora o log group (cada serviço na AWS possui um log group no CloudWatch onde os logs são armazenados) do serviço que possui as informações a serem capturadas. Toda vez que uma mensagem é inserida nesse log group com um padrão determinado, a Lambda é acionada, fazendo todo o tratamento necessário e armazenando os dados em um bucket no AWS S3, disponibilizando as informações para serem usadas no QuickSight.
Os principais pontos para a adoção dessa solução foram:
- Controle sobre qual informação é capturada pela Lambda e como vai ser processada
- Arquitetura simples e fácil de fornecer manutenção
- Near real time
- Solução independente da atuação de outros times
O objetivo desse artigo é mostrar como foi desenvolvida a solução adotada para capturar informações importante armazenadas em logs de aplicações, utilizando as ferramentas que a AWS disponibiliza. A ideia não é explicar detalhadamente cada serviço, por isso é interessante que o leitor esteja familiarizado com alguns termos e ferramentas, como:
- CloudWatch
- Lambda
- S3
- Glue
- Athena
- QuickSight
Caso você, ou sua empresa esteja passando por desafios parecidos, esse artigo pode lhe ser bem útil!
Como é o fluxo macro
Antes de explicar cada etapa da arquitetura proposta, é interessante contextualizar o leitor com o macro fluxo do processo:
- Uma requisição é feita na API de Software Engineering
- Uma Lambda é acionada
- Os logs dessa Lambda vão para o CloudWatch
- Uma outra Lambda monitora um Log Group definido
- Dado um padrão, a Lambda que está monitorando o Log Group é acionada e processa os logs
- O resultado é enviado para um bucket no s3
- Um crawler no AWS Glue mapeia e categoriza os dados desse bucket*
- Um database e tabela são criados no Athena*
É interessante observar que a interação com o time de Software Engineering acontece apenas no início do processo. Independente da aplicação criada, o time de Data Science possui autonomia para definir um padrão para acionar uma Lambda e a partir disso, todo o restante do fluxo é de forma automática.
Apesar das diversas etapas no fluxo, depois da criação inicial, todas as partes são feitas automaticamente a partir de uma Lambda. Essa recebe os logs que possuem o padrão definido, trata os dados, salva no s3 da forma como será utilizado e por último atualiza a tabela no Athena.
* Esses passos são feitos apenas uma vez, após isso eles são atualizados direto pela Lambda. Ao decorrer do artigo esse ponto será mais bem explicado.Como funciona cada etapa
1. Logs no CloudWatch
Como dito anteriormente, todos os logs que as Lambdas produzem são inseridos, por padrão, no CloudWatch em um grupo específico. Dentro do grupo existem conjuntos de logs separados por tempo, os Log Streams. Por fim, dentro de cada Log Stream estão os eventos onde estão todas as informações geradas pela aplicação são inseridos. Tais eventos são chamados de Log Events.
A imagem a seguir representa um exemplo de um Log Stream e seus Log Events.
2. Captura dos Logs via Lambda
Como toda informação gerada por uma aplicação é inserida em forma de log no CloudWatch, muitas dessas informações, não são escopo de análise do time de Data Science e portanto não necessitam de captura e tratamento. Mas como filtrar apenas o necessário? A AWS fornece um serviço bem direto e simples de configurar, chamado Subscription Filter.
Existem duas formas de configurar o subscription filter (limite de dois por Log Group): Lambda subscription filter e Elasticsearch subscription filter. É possível utilizar o Kinesis Firehose também, porém este tema não é escopo deste artigo. Como o destino final do exemplo em questão não é o Elasticsearch, foi registrado um Lambda subscription filter.
Ao utilizar um subscription filter, é possível incluir um padrão para a Lambda ser “acionada”. É bem flexível a forma como é definido o padrão, podendo ser um caractere, uma chave caso o log seja um arquivo JSON e existe até a possibilidade de criar condições, por exemplo.
O processo para registrar uma Lambda como subscription filter de um Log Group é bem simples. Como citado no começo do artigo, na KeyCash o framework Serverless é utilizado para construir todas as funções Lambdas. Desta forma é possível relizar o deploy de todos os serviços necessários da AWS para executar a Lambda, definir os acessos, entre outras funcionalidades de forma programática, utilizando o conceito de Code as a Service.
Exemplo de um arquivo .yml para configurar uma Lambda como subscription filter de um Log Group específico:
Como explicado anteriormente, essa Lambda só será acionada caso algum log com o padrão “teste” definido no tópico filter for encontrado.
3. Lambda customizada para processar os logs que recebe
Ao iniciar um novo projeto utilizando o framework serverless, é possível construir a função principal e as auxiliares que vão lidar com todo o processamento dos logs.
Um payload com as informações é enviado para a Lambda codificado com o método base64, de acordo com o exemplo a seguir:
O resultado da decodificação da mensagem é algo parecido com o exemplo a seguir:
É possível notar todas as informações do log, não apenas a mensagem, mas o timestamp, id do Log Event, Log Stream, Log Group, entre outras. Com esses dados é possível extrair apenas o conteúdo que será tratado de acordo com o uso e salvá-los em outro lugar de armazenamento.
No exemplo utilizado, ao termino da limpeza e separação do conteúdo filtrado, o resultado é salvo em um bucket no s3 e depois uma tabela no Athena é atualizada.
Esse seria um exemplo do código que envia um arquivo JSON para o s3. A estrutura year={}/month={}/day={}/hour={}, é utilizada de acordo como programado no AWS Glue para mapear os dados no bucket.
Para atualizar o Athena é utilizda a seguinte função:
Essa função executa uma query no Athena que adiciona o arquivo (partição), inserido no s3, no database e tabela que foram gerados a partir do mapeamento do bucket. Por padrão é verificado se a partição existe, caso não, ela é adicionada dado o caminho dela no s3.
Importante notar que mesmo após executar a query e tendo um retorno positivo, não necessariamente a partição será adicionada, por isso um loop é executado para verificar o estado da query, se está processando, se falhou ou se já foi processada.
Feito todo esse processo o resultado são as informações necessárias, tratadas da forma como serão utilizadas, armazenadas no s3, atualizadas e pronta para serem acessadas no Athena e QuickSight.
4. Crawler no AWS Glue
A ideia não é estender muito esse tópico. Neste artigo este tópico é explicado com mais detalhes.
Recomenda-se a leitura, principalmente pois são esses crawlers que mapeiam e catalogam os dados, para assim criar um database e tabela no Athena.
5. Tabela no Athena
No Athena é possível visualizar todas os dados de um database e uma tabela específica. Dados que estão armazenados no s3.
O query editor do Athena é uma ótima ferramenta para realizar análises prévias e posteriormente desenvolver relatórios no QuickSight. É de fácil uso, dado que a sintaxe é o SQL.
6. QuickSight
O QuickSight é uma solução da Amazon para Data Visualization. Basicamente, é uma ferramenta para criar painéis de forma rápida, escalável e de fácil integração em sites proprietários, apps etc.
A ideia não é explicar a fundo como funciona essa ferramenta ou como criar painéis, e sim explicar os motivos para a adoção dessa ferramenta dentre tantas outras disponíveis no mercado:
- Fácil utilização. A curva de aprendizado da ferramenta é rápida, sendo necessário poucos dias para aprender o mínimo para construção de um dashboard simples
- Já está integrado com todos os serviços da AWS
- Fácil integrar em aplicações Web proprietárias
- Fácil realizar a publicação de novos dashboards. É uma solução que não demanda muito esforço para colocá-los em produção
- Satisfaz as principais necessidades de Data Visualization
Conclusão
A área de dados é bem extensa, tendo diversos pilares e frentes de atuação, sendo uma delas o Data Visualization. Conseguir acompanhar a saúde das aplicações e evolução dos produtos é de suma importantância. Porém, para chegar nesse estágio, muitas outras etapas são necessárias. Um longo trabalho de engenharia de dados é preciso para que os dados cheguem da melhor forma possível e assim gerar análises, dashboards e insights.
Em uma empresa com um grande time de dados é comum que essas funções estejam bem separadas, sendo responsabilidade de pessoas diferentes. Mas, como dito no neste artigo da KeyCash, cada cenário é diferente e requer uma solução específica. Com uma equipe mais enxuta essa foi a forma encontrada para resolver o problema de forma rápida e sem perder a qualidade.
Nesse artigo vimos:
- O motivo para adoção da solução apresentada
- Como é o macro fluxo
- O que cada etapa do fluxo significa
- Quais são os pontos importantes de cada etapa
- Exemplo real
Caso tenham alguma observação ou dúvida, não deixem de comentar ou entrar em contato conosco! Nos vemos no próximo artigo :)
