fbpx
Logs Estruturados
Publicado em: domingo, 21 de dez de 2014
Categorias: Arquitetura

Então, meses sem escrever nada mas hoje estou aproveitando o domingo para escrever algumas coisas sobre o que tenho vivido no último ano. Olhando projeções para o próximo ano, vejo alguns pontos relevantes relacionados ao que posso contribuir com o dia-a-dia de vocês.

Você sabe o que são logs estruturados?

Logs estruturados, diferente dos logs de aplicação, comuns, contém uma série informações e metadados adicionais, usados para agrupamento e consulta. Logs estruturados devem conter informações relevantes ao negócio e ao desenvolvedor.

Um log comum de exceções, por exemplo, envia dados da exceção, como mensagem, stack trace, inner exceptions. Um log estruturado de exceções, poderia conter informações que diagnosticam o servidor no qual o log foi gerado, qual a operação estava sendo processada, qual o ID ou dados mais completos dos seus objetos de negócio durante a operação, além da comum severidade. E não para por aí, ainda seria possível informar qual o cliente da requisição, no caso de WebApps, qual o usuário logado, entre outras diversas informações de aplicação que poderiam ser passadas para o log, ajudando no troubleshooting e análise de problemas ou mesmo de fluxos de negócio.

Como montar uma estrutura eficiente de logs estruturados?

Ao pensar em logs estruturados, um dos primeiros pontos que me vêm a cabeça é a necessidade de metamodelos. A primeira implementação de log estruturado que fiz, foi para a B2W Viagens em 2010, chamava-se LogEngine. Na prática, uma estrutura de log com dados estáticos e dinâmicos. Os dados dinâmicos eram as tags, que diferente do modelo comum que vemos por aí no mercado, oferecia Tag/Valor, em uma estrutura bem simples de Chave/Valor. Nessas chaves você poderia adicionar qualquer informação, nos valores a mesma coisa acontecia. Para que as aplicações não fossem oneradas em virtude da necessidade de persistência desse log, passei a publicar esses logs em filas no MSMQ e posteriormente no RabbitMQ, assim que o Oragon começou a dar suporte ao RabbitMQ. A publicação de mensagens de log nas filas do RabbitMQ foi o primeiro motivador para a implementação dessa feature no projeto.

A persistência desse modelo acontecia em banco relacional e aí começaram os problemas. Embora seja extremamente eficiente do ponto de vista de armazenamento (nenhum dado semelhante era duplicado), a performance de consulta e escrita não eram satisfatórios para a massa de dados que eu estava trabalhando.

O Log Engine não existe mais, mas era um projeto bem interessante, pois permitia que os desenvolvedores vissem seus logs, em tempo real, mas ainda usando queries em banco, e muitas vezes queries bem complexas.

Ferramentas de Suporte

O projeto não chegou a virar produto por falta de um time de desenvolvimento. Basicamente hoje o mercado está cheio dessas soluções, mas na época, apenas existia o Oragon Architecture e o LogEntries. Alguns anos depois, já na iMusica, fui apresentado ao Sentry, e posteriormente ao LogStash/ElasticSearch/Kibana. Bom o Sentry é uma ferramenta bem interessante, mas tuná-lo é uma tarefa bem chatinha. Sofri alguns meses com o Sentry, principalmente com a perda de mensagens. Por padrão o Sentry é passivo, portanto você precisa publicar as mensagens nele. O protocolo padrão é HTTP e usamos o Raven para executar a tarefa. Diferente do modelo padrão, onde a aplicação chama diretamente o Sentry, nossas mensagens eram enviadas para o RabbitMQ, e posteriormente outro serviço se encarregava exclusivamente de publicar essas mensagens no Sentry. Essa mudança no viés exige que se faça uma mudança simples no Raven para que a data da mensagem não seja adicionada no momento em que a mensagem está sendo publicada no Sentry. Sua mensagem que estava na fila já possui essa informação, e você pode ter um delay entre uma tarefa e outra.

Outro produto que estou usando mais agora é o ELK, acrônimo para ElasticSearch, LogStash e Kibana. Enquanto o ElasticSearch é um backend NoSQL, baseado no Lucene, com uma API REST de escrita/leitura, e uma API muito robusta de consulta, já o LogStash é um serviço de coleta de logs ativo, responsável pela leitura e transformação de logs e sua publicação. No modelo ELK o LogStash publica os logs no ElasticSearch, mas tem a capacidade de publicar os logs em outros backends e tecnologias. Há uma abstração bem clara entre o que ele chama de input e output. Além da leitura e escrita, ele possui capacidades de transformação de logs, e converte logs nos mais variados formatos de origem e destino, é excepcional! Por fim o Kibana é um dashboard html+javascript extremamente configurável e robusto que conversa direto com o ElasticSearch. Esse é o padrão que utilizo hoje.

Conslusões

Uma das grandes vantagens desse modelo, é eliminar a necessidade de implementação de mecanismos de leitura das filas (RabbitMQ) e publicação no backend de log. O LogStash faz essa tarefa graciosamente. O ElasticSearch é extremamente robusto e suporte uma massa de dados infinita, com suporte a clustering, charding, e muito mais. O Kibana poderia ser melhor, ter mais funcionalidades, mas já oferece muita coisa interessante.

Outro ponto bem interessante desse modelo foi a eliminação de tabelas de log do meu modelo de domínio. Como meus logs são bem estruturados consigo manter uma boa rastreabilidade com base nas tags e em seus valores, permitindo além de consultas diretas, ser chamado direto a partir de interfaces Web, usando HTTP, desde que seu ElasticSearch possua conectividade. De qualquer forma há API`s para .Net, oferecendo suporte Server Side.

Bom, é isso, se tiverem dúvidas sobre logs estruturados, é só comentar ou mandar uma mensagem!

Obrigado pessoal.

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.