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.