Pessoal, hoje vou falar um pouco de um stack de log muito interessante, esse papo acontece aqui no Docker de A a Z pois toda a infra de log é feita usando Docker. Nesse stack de log utilizo RabbitMQ,  LogStash, ElasticSeach e Kibana com Docker Compose. São muitos elementos, mas esse desenho garante o máximo de performance para qualquer tipo de aplicação, é destinado a alta performance, portanto você não sentirá gargalos com o acréscimo dessa infraestrutura(1)1 – A implementação apresentada aqui destina-se exclusivamente para ensinar como utilizar, de forma básica e simplista, o cliente .Net para o RabbitMQ. O não reaproveitamento das instâncias dos objetos de Conexão e Modelo do RabbitMQ.Client podem resultar degradação de performance. em comparação com aplicações de pequeno e médio porte, que usam escrita em disco (síncrona ou assíncrona), e há uma grande possibilidade de sentir uma boa melhora na performance de aplicações que geram muito IO, principalmente com Logs.

TL;DR

Ok, tem bastante conteúdo nesse post, mas você pode pular as preliminares e ir direto para docke-compose. Os comandos abaixo fazem tudo o que você precisa para ter seu ambiente funcional!

Execute-os para ter sua infra de logs pronta para uso geral.

Os papeis no Stack

RabbitMQ

Como um dos mais robustos message brokers do mercado, o RabbitMQ é encaixado nessa arquitetura de logs para oferecer o menor custo possível para aplicações, servindo às mais variadas plataformas e tecnologias, tornando o envio assíncrono em relação à persistência das mensagens, no nosso caso, dos logs.

ElasticSearch

ElasticSearch é uma engine distribuída de pesquisa e análises, projetado para escalabilidade horizontal, confiabilidade e fácil gerenciamento. Ele combina a velocidade da pesquisa com o poder da análise através de uma linguagem de consulta sofisticada, amigável, cobrindo dados estruturados e não estruturados, e de séries temporais.

ElasticSearch é utilizado como storage para nossos logs. Ele oferece uma API RESTful para persistência e consulta, suportando grandes cargas de trabalho e grandes volumes de dados persistidos. É a solução ideal para logs, mas pode ser usado para qualquer finalidade que demanda análise em tempo real.

LogStash

As mensagens enviadas ao RabbitMQ precisam ser persistidas no ElasticSearch, para que o índice possa ser consultado posteriormente. Eu e você poderíamos desenvolver alguma solução para isso, na prática, antes de conhecer o LogStash, eu havia feito uma. Ao conhecer a solução me senti muito feliz em jogar fora o projeto e me dediquei a utilizar o LogStash e hoje há uma infinidade de motivos para você não construir uma solução que faça esse transporte entre o RabbitMQ e o ElasticSearch. O primeiro motivo está relacionado ao seu propósito: O LogStash foi projetado para recuperar (input) logs de diversas estruturas, repositórios e tecnologias e enviar (output) para outros. Sua flexibilidade e diversidade, oferecida por seus inputs e outputs e filtros, garante um rico desenho de solução para os mais variados cenários. No nosso caso, apresentamos um cenário muito simples, no entanto poderíamos enriquecê-lo facilmente utilizando seus recursos nativos.

Kibana

De pouco adiantaria termos todo esse desenho se não pudéssemos ter uma interface gráfica destinada à visualização daquilo que está no ElasticSearch. O Kibana é uma plataforma de análise e visualização, mantida pela Elastic, mesma empresa que também mantém o ElasticSearch e o LogStash, e suporta os mais variados tipos de apresentação, com um modelo de customização amigável e fácil.

Visão geral

rabbitmq-elk-black

A imagem acima apresenta as responsabilidades de cada um dos participantes dessa arquitetura.

Benefícios

São inúmeras as vantagens de se utilizar dessa arquitetura para Logs, entre elas as que mais ressaltam aos olhos é a capacidade de tornar a análise de logs algo proativo. Geralmente as reclamações acontecem em decorrência de um elevado/significante número de problemas em uma determinada área da aplicação ou serviço. Na medida que você tem a chance de provativamente analisar logs, de forma fácil, simples e indolor, há grandes chances de poder cuidar do problema, antes mesmo deste ter sido reportado por teus usuários ou clientes.

Em duas das últimas grandes implantações que utilizei esse stack para logs, analistas de negócio e gestores utilizavam o Kibana diariamente para realizar uma análise básica, demandando do time uma análise mais detalhada do log, quando os indicadores mostravam alguma grande variação e/ou encontravam erros de sistema. Essa abordagem dá mais autonomia e transparência para a gestão, trazendo-a para perto da realidade de um sistema em produção.

Índice

Brinde:

Para dar suporte a esse exemplo, criei o projeto EnterpriseApplicationLog no GitHub. Graças a ele é possível testar essa infraestrutura executando apenas:

Outros posts:

Esse tema já foi abordado aqui, mas com pouco how-to nos posts:

  • Logs Estruturados | Dez/2014 | Um diálogo sobre a importância de adicionar informações de negócio nos logs de aplicação e os ganhos obtidos com essa abordagem
  • Novas tecnologias – Alguns motivos para você pensar nelas! | Fev/2016 | Uma tentativa de abrir os olhos daqueles que não gostam de novas tecnologias
  • O que eu uso? | Jul/2014 | Uma visão geral sobre algumas tecnologias que utilizava na época. Uma dica: Praticamente nada daquilo saiu da “cartola”, mas mas muita coisa legal foi adicionada!!!

[27/11/2016] Upgrade para ELK Stack 5.0 

O Jean Carlos Lourenço abriu uma issue no repositório e por estar envolvido com outras coisas essa foi a única mensão à versão 5 do ELK Stack que eu tive contato. Graças ao Jean descobri e fiz os devidos updates. Muito obrigado!

Ainda que eu precise estudar mais sobre essa release, de antemão, o que dá para ver pelos vídeos é que tende a ser algo fantástico. No Kibana vemos mudanças na UI, um layout mais interessante e organizado. É preciso entender o que mais muda e o que podemos tirar dessa nova versão. Já achei o X-Pack algo interessantíssimo, e possui features que sempre desejei no stack. Talvez mereça sua adição, quem sabe?!

  • Tiago Gomes

    Ótimo vídeo Luiz,
    Estou com um problema na hora de subir o compose apresenta o seguinte erro:
    ERROR: client version 1.22 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version.
    Estou usando docker no windows server 2016 version 17.03.0-ee-1

    • Thiago,
      roda o comando “docker info” e me passa a resposta por favor. Pode ser por email (vi que enviou um email sobre o tema).

    • Thiago, analisei seu Docker info e pude perceber que está usando Windows Containers e não Linux Containers. O exemplo do vídeo utiliza imagens da Linux/x86_64.
      Já faz algum tempo que criei a página de WIKI https://github.com/luizcarlosfaria/kb/wiki/Docker-no-Windows-vs-Docker-no-Linux que explica um pouco sobre o que fica subentendido sobre essa questão de Docker no Windows vs Docker no Linux.

      • Tiago Gomes

        Luiz, muito obrigado pela atenção, vi a explicação na sua página.
        Valeu.