Enterprise Application Log consiste é um stack pré-configurado que contém RabbitMQ e ELK Stack colaborando para entregar uma robusta plataforma de monitoramento, centralização e consolidação de logs.
Nesse stack de log utilizo RabbitMQ, LogStash, ElasticSearch 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 - 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 o tratamento inadequado ou inexistente do Model 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!
git clone https://github.com/docker-gallery/EnterpriseApplicationLog.git cd ./EnterpriseApplicationLog docker-compose up
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.
O 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
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
- Apresentação
- Docker Gallery
- Demo 1 - Envio manual
- Projeto EnterpriseApplicationLog @ GitHub
- Subindo a infraestrutura com Docker Compose
- Interrupção (desculpem por isso, eu cortei várias interrupções, essa acabou passando!)
- Entrando na administração do RabbitMQ
- Entrando na interface do Kibana
- Criando primeiro Log usando a interface de administração do RabbitMQ
- Configuração Inicial do Kibana e visualização dos primeiros logs
- Demo 2 - Envio com uma aplicação .NET
- Considerações finais
Brinde:
Para dar suporte a esse exemplo, criei o projeto EnterpriseApplicationLog no GitHub. Graças a ele é possível testar essa infraestrutura executando apenas:
git clone https://github.com/docker-gallery/EnterpriseApplicationLog.git cd ./EnterpriseApplicationLog docker-compose up
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?!
[25/01/2018] Pendência de Upgrade
O Alexsandro Pereira me chamou um dia desses no telegram para avisar que rolaram umas mudanças no projeto e agora eles possuem 3 imagens distintas. Isso ainda não foi revisado/implementado, mas desde já agradeço! Esses filhos (projetos) precisam de uma atenção que as vezes é complicado dar.
[11/03/2018] Release Products-6.2.2-Stack-1.1.0 liberada!
Aproveitei um final de semana mais tranquilo para resolver algumas pendências do stack. Agora saímos da versão 5.0 para a versão 6.2.2 do ELK stack, já com as mudanças para o novo modelo de imagens *-oss disponibilizadas pela Elastic. Adicionei o Beats ( Metricbeat ) ao stack, para monitoramento do Docker (Host), e dos containers RabbitMQ e Elasticsearch, portanto agora temos as seguintes imagens em uso:
- rabbitmq:3-management-alpine
- docker.elastic.co/elasticsearch/elasticsearch-oss:6.2.2
- docker.elastic.co/logstash/logstash-oss:6.2.2
- docker.elastic.co/kibana/kibana-oss:6.2.2
- docker.elastic.co/beats/metricbeat:6.2.2
O stack, como sempre, continua configurado e pronto para uso da mesma forma que o apresentado no vídeo, mas agora temos novos elementos.
Alguns adereços relacionados a health check foram adicionados na configuração para facilitar o deploy.
A propósito aboli o SemVer! SemVer não consegue expressar bem esse tipo situação onde a versão dos produtos envolvidos no stack é mais relevante que o stack em si. Adotei uma forma mais verbosa, no entanto que exprime com fidelidade o que temos.
A propósito está aqui o Kibana em ação, com um dos dashboards.
[30/03/2019] - Release Products-6.7.0-Stack-2.0.0 liberada
O mais incrível é que quem o fez foi o Thiago Aragão. Ele precisou de algo para resolver o problema, baixou, usou, validou a implementação e fez o update + pull request! That's fuking awesome!
Imagens utilizadas:
- rabbitmq:3-management-alpine
- docker.elastic.co/elasticsearch/elasticsearch-oss:6.7.0
- docker.elastic.co/logstash/logstash-oss:6.7.0
- docker.elastic.co/kibana/kibana-oss:6.7.0
- docker.elastic.co/beats/metricbeat-oss:6.7.0
Participe e Colabore
Note que em diversas a comunidade ajudou a evoluir o projeto, ou comentando alguma novidade (que por sua vez demandou update) ou enviando pull requests. Ajude também com sugestões, forks e PR's.
Concorrência é boa e sadia
Se você quer fazer algo parecido com outro stack, eu aconselho Graphite / Grafana!
Tenho muita vontade de criar uma versão 2 do stack com esses elementos, para testar, e quem sabe usar também.
Acho que ter várias alternativas é sadio, faz bem para a comunidade e melhora o ecossistema.
Eu posso te ajudar de diversas formas
Eu posso ajudar de diversas formas, divulgando, colocando um banner aqui, ou mesmo ajudando a construir o stack ou dando algum suporte caso precise.
Requisitos: Para que eu ajude, basta que seu stack siga as seguintes regras:
- Usar Docker Compose
- Usar RabbitMQ
- Com as mesmas credenciais (se quiser mudar, combinamos e mudamos juntos)
- Mesmo Virtual Host (se quiser mudar, combinamos e mudamos juntos)
- Mesmo nome de fila (se quiser mudar, combinamos e mudamos juntos)
- Mesmo volume docker (se quiser mudar, combinamos e mudamos juntos)
Esse é o contrato para as demos, quem baixou ou criou um fork desse stack aqui já conhece esses recursos, com essas credenciais, essa fila, e portanto faz todo sentido caminharmos juntos para que um stack seja um drop-in-replacement do outro.
0 comentários