Hoje chegamos à versão 4 do nosso stack de observabilidade. Contamos com o upgrade para a versão 7.13.0 de todos os recursos da Elastic e a adição de novos componentes entre eles o Application Performance Monitoring (APM).
Motivador
Monitoramento sempre foi um desafio. E cenários on premise ou baseados em IaaS são mais desafiadores ainda. Mas nem por isso não é possível trabalhar de forma profissional.
A primeira vez que coloquei no ar o ELK stack, foi em 2013. Após uma experiência fracassada com o Sentry, recebi uma recomendação e parei para avaliar esse stack.
Comparado com o Sentry, de fato temos um cenário bem diferente com diversos componentes. No caso ElasticSearch, um índice baseado no projeto Apache Lucene, o LogStash, um middleware de processamento de logs, que transforma e escreve no ElasticSearch. E por fim o Kibana, uma interface de visualização para o ElasticSearch.
Aquele setup, era o primeiro ou um dos primeiros setups linux do qual eu fazia parte. Me recordo de assistir atentamente e entender como os pontos se conectavam, como os diversos arquivos de configuração precisavam ser orquestrados para que no fim, todo o stack se falasse. Meu papel ali era de cliente e coadjuvante.
No post Por onde andei, andei frustrado eu relato outras partes desse roadmap, para esse post sobre esse stack, eu isole especial na imagem ao lado a parte que fala somente do tema observabilidade. Já no post Logs Estruturados você vai encontrar minha crítica aos logs em plain text.
Entre os grandes motivadores para a adoção de uma infraestrutura de logs, está o abandono dos logs em arquivo texto, que não servem de nada nos casos de sucesso. E atrapalham nos casos de insucesso. Por outro lado, logs estruturados são passíveis de virar gráficos, boards e fornecer uma visão bem interessante sobre sua aplicação.
Naquela época eu ainda tinha outro desafio. Quando a aplicação rodava em um servidor (algumas rodavam no desktop do dev), era necessário acessar o servidor para entender o que estava acontecendo.
A história do stack
A primeira vez que subi esse stack sozinho foi para um cliente em 2015. Era um parque 100% windows tive de fazer o setup do ElasticSearch, LogStash e Kibana em servidores windows on premise. Somente depois desse stack no ar, e a aplicação sendo toda instrumentada, pude entender o que acontecia de fato. Essa foi uma das defesas mais insanas e sensatas que fiz até hoje. Graças à observabilidade consegui identificar com clareza problemas, gargalos e aumentamos substancialmente nossa capacidade de nos defender, visto que por conta de uma integração sofríamos “ataques” o tempo todo, acusando falha em nossos serviços. Mas com o monitoramento ganhamos a capacidade de responder com precisão milimétrica tudo que estava acontecendo do nosso lado.
No final de 2015 eu tenho meu primeiro contato com Docker. Já no ano seguinte eu resolvo montar esse stack e publicar como um docker-compose pré-configurado. No final de setembro de 2016 temos a primeira versão do stack no ar. Ele deu suporte para o vídeo Docker – de A a Z – 15 – RabbitMQ, ElasticSearch , LogStash e Kibana de 1° de outubro.
Desde então o projeto tem sido mantido em uma página aqui no gaGO.io ( EnterpriseApplicationLog @ Docker Gallery ). E já rolaram diversos posts aqui também sobre essa stack.
Docker – de A a Z – 15 – RabbitMQ, ElasticSearch , LogStash e Kibana
Enterprise Application Log + Access Log NGINX
docker-gallery/EnterpriseApplicationLog – v3.0
Além de já ter virado tema no Docker Definitivo.
O que há nesse stack?
Primeiro o ElasticSearch é nosso storage e search engine. LogStash está empenhado em trazer as mensagens do RabbitMQ para o ElasticSearch. Enquanto o Kibana exibe tudo.
Adicionalmente temos o MetricBeat para métricas do Docker, Elastic e RabbitMQ, e o Heartbeat para análise de uptime. Serve como demonstração para você monitorar seus serviços.
A última adição foi o Elastic APM, um application performance monitoring server que lida com os principais desafios de tracing.
Possibilidades
Uma das coisas que faço na minha infra pessoal é entregar os logs do NGINX para o meu ElasticSearch, isso é feito com uma mudança na configuração do NGINX para produzir JSON e uma configuração adicional no logstash para considerar esse arquivo.
O Metricbeat possibilita gerar métrica de dezenas de outras ferramentas, isso pode ser útil.
Já o Heartbeat monitora uptime de qualquer um dos seus serviços ou servidores.
O APM tem SDK para diversas tecnologias, e permite gerar uma visão uniforme entre as aplicações, enquanto o Logstash está pré-configurado para enviar todas as mensagens do RabbitMQ, que estiverem na fila ApplicationLog, residente no Vhost EnterpriseLog, direto para o elastic. Isso abre outras possibilidades e interoperabilidade. Possibilitando na pior das hipóteses que seja criada uma camada HTTP para essa publicação.
Comparativo com Application Insights
Toda vez que eu publico uma atualização do stack sempre surgem perguntas a respeito do Application Insights. Nesse stack o serviço que mais se assemelha ao Application Insights é o APM. Após 4 anos, essa é a primeira vez que coloco o APM no stack.
Application Insights é uma ferramenta do azure para quem quer ou não se importa de visualizar seus dados no Azure.
Essa não é a realidade de nenhuma empresa onde trabalhei.
Seja no e-commerce onde você cria um board para exibir os impactos de uma campanha de marketing na quantidade de pedidos, ou para uma visão sobre pressão e carga de trabalho nos servidores de uma API. Em ambos os cenários eu quero criar um board customizado com métricas, agregadores, e inúmeras variações possíveis.
Esse stack baseado no ELK tem o propósito de servir não só ao time técnico, mas possivelmente também a um time de negócios, portanto lidar com acesso e credenciais do azure não seria uma coisa muito interessante, além da dificuldade de criar dashboard que não tenham uma visão sistêmica.
O monitoramento não é somente das aplicações, mas dos servidores, inclusive servidores que não possuem projetos onde um APM se encaixa. São esses servidores de bancos de dados, servidores de RabbitMQ, serviços que são isolados e estão sozinhos em máquinas das quais precisamos monitorar.
Dessa forma, essa essa comparação não faz muito sentido. Os propósitos são bem diferentes.
Porque criar um stack?
Configurar tudo isso é trabalhoso, você facilmente levaria alguns dias para dar vida a esse stack e não necessariamente você tem esse tempo para essa atividade. Outro ponto é que para fazer de forma minimamente consistente, você precisa de conhecimento específico, seja com Docker, seja sobre cada uma das ferramentas.
Com esse stack, basta um docker-compose up e pronto, os serviços estão no ar. Claro que essa versão não usa autenticação e isso tem a ver com o modelo de licença antigo em que o X-Pack era um pacote licenciado. Eu ainda não mudei isso.
Sobre o licenciamento
O repositório github.com/luizcarlosfaria/EnterpriseApplicationLog está licenciado como MIT. Isso diz respeito ao stack. Cada um dos serviços da Elastic devem respeitar as devidas licenças.
Lembrando que um deslize aqui pode custar muito caro!
https://github.com/elastic/elasticsearch/blob/master/LICENSE.txt
https://github.com/elastic/beats/blob/master/LICENSE.txt
https://github.com/elastic/kibana/blob/master/LICENSE.txt
https://github.com/elastic/apm-server/blob/master/LICENSE.txt
Propósito e como tirar proveito desse stack?
Sabe aquele projetinho que você faria todo cagadinho? Bom, pode pelo menos colocar um monitoramento nele, para que possa argumentar quando os alertas acusarem bugs e mais bugs.
Sabe aquela PoC que era simpleszinha e virou um elefante branco? Agora temos pelo menos um board para lembrar que isso entrou em produção e que ao invés de ser utilizado apenas por uma semana, já faz 1 ano que o cliente está usando a versão de homologação como se fosse produção.
Sabe quando você criar um background worker para processar mensagens de uma fila e não sabe se está tudo ok ou não? Pois bem!
Posso usar esse stack em produção?
Se você não sabe o que está fazendo, não.
Para colocar em produção você precisa planejar sem ambiente, planejar seu storage, validar se o elastic será colocado em cluster ou não, verificar o licenciamento e garantir que não está ferindo nenhuma licença.
Toda simplificação que esse stack pronto lhe trouxe acaba no exato momento em que você pensa em colocar em produção.
Pensando nisso eu resolvi não dar atenção à autenticação, isso quer dizer que para ter esse ambiente autenticado, você precisará estudar um pouquinho!
Que comecem os jogos!
Conclusão
Temos uma das maiores e mais significativas mudanças no stack. Quase 1 ano após a última release.
Vale lembrar que docker reduz o esforço para testar e validar tecnologias, mas é tua responsabilidade ser responsável pelo que coloca no teu projeto e o que coloca em produção. Na prática a gente adia o aprendizado de algumas coisas para que possamos validar a ideia e decidir entes de empenhar mais tempo no assunto.
0 comentários