Logs + Athena + Quicksight

Não importa se você é dev, ops, sec e outra sigla qualquer. Você precisa extrair informações de logs.
Existem diversas ferramentas no mercado que podem te ajudar, você faz a carga dos seus logs e voila diversos gráficos e sugestões podem surgir. Existem algumas mais caras como Splunk e Sumologic. E outras mais acessíveis como Loggly e Logz.io. Algumas possuem um free tier, mas mesmo assim, se você não estiver disposto a abrir a carteira, você vai ficar muito limitado.

Pensando nisso, olhei as ferramentas da AWS e pensei como poderia analisar logs rapidamente, gastando pouco e gerando a informação necessária.

Motivação: Eu tinha o seguinte problema: uma aplicação estava instável e apresentava alguns erros 500 e eu precisava descobrir quem era o “culpado” pelo erros.

Vamos lá:

Essa aplicação estava atrás de um Elastic Load Balancer. Então em primeiro lugar, precisamos ativar o Log do ELB.

Clique no seu Load Balancer e desça até a opção de atributos

E ative conforma a imagem abaixo:

A partir de agora a cada 5 minutos teremos alguns arquivos no bucket escolhido. Você pode direcionar para o mesmo bucket os logs de um ou mais ELB.

O Athena é um serviço de consulta (baseado no Apache Presto), capaz de acessar arquivos direto do S3 usando SQL padrão. Ele cobra por TB scaneado. Neste caso o volume de dados é pequeno então isso não gera uma preocupação. Caso você tenha um volume grande, considere comprimir os arquivos pois isso vai te gerar uma economia.

No console vamos ao Athena:

E podemos criar a nossa tabela de consulta. Para a nossa alegria, existe um tutorial simples que cria exatamente o que precisamos para o ELB

Basta seguir o passo a passo, sem criar particionamento. Apenas fique atendo para o passo 3. Escolha o DB, o nome da tabela e a localização do Data Set, que deve ser o mesmo Bucket dos logs do ELB.

Agora no Athena já podemos fazer algumas consultas aos nossos logs:

Vamos rodar um exemplo, basta clicar em new query e colar o seguinte trecho:

SELECT url, count(*) as contador
FROM elb_logs
WHERE elb_response_code='500'
GROUP BY url
ORDER BY contador DESC
LIMIT 10;

Sua tela ficará assim:

E temos o seguinte resultado:

Neste exemplo, já achamos quem é o principal culpado pelos erros 500. E fica fácil começar a resolver.

Porém a abordagem de consultas SQL não é muito amigável e apresentar um resultado em gráfico normalmente produz um impacto maior.

A AWS possui uma ferramenta de análise chamada QuickSight, feita para o público de BI e Analytics. Com suporte a diversas fontes de dados, entre elas o Athena, ele vai nos atender bem neste caso.

O primeiro usuário é FREE para até 1 GB de espaço, no meu exemplo temos mais do que isso. Porém não vou carregar os dados para dentro do QuickSight, o Athena será consultado diretamente. Naturalmente perderemos em performance, mas teremos sempre os dados atualizados para rodar as nossas consultas.

Clique em New Analysis e posteriormente em new DataSet

Dentro de um novo DataSet do tipo Athena

Vamos escolher a nossa fonte de dados:

Nossa tabela. Aqui já podemos editar os nossos dados, mas não faremos. Isso será feito em uma próxima etapa.

O QuickSight nos dá a opção de importarmos os dados ou consultarmos direto do Athena, que será a nossa escolha

Pronto, em seguida temos a seguinte tela e podemos começar a trabalhar nosso dados:

1 . Clique uma vez elb_response_code e depois clique (novamente) na seta a direita e seleciona a opção Add filter to this field

2 . Na filtragem, desmarque a opção ALL e selecione apenas apenas erro 500

3 . Aplique e feche.

4 . Volte para a função Visualize e escolha o gráfico de pizza:

5 . Arraste a url para os dois campos:

6 . E teremos o seguinte gráfico:

Que nos dá uma noção maior ainda, do problema que essa URL está gerando. Entre outras idéias que podemos levantar. Mas o interessante é que isso tudo está sendo consultado em tempo real no S3.

Ou seja, sempre que o Load Balancer enviar novos logs teremos os dados atualizados.

Conclusão:

Gastando pouco é possível gerar muita informação relevante a partir dos seus logs e com um fator interessante, serverless. Ou seja, sem se preocupar com infra, software ou manutenção.

Tem mais idéias para logs ou dúvidas, escreve aqui em baixo.

Originally published at medium.com by @francisco.