Destaque da Semana #2 : Graylog

by Checchia
17 minutos
Destaque da Semana #2 : Graylog

Bom, continuando a série de “Destaque da Semana” vamos falar agora de Centralização de LOGs.

Mas não vamos falar de centralização de LOGs de Sistemas Operacionais e Serviços, como smtp, email, apache, etc…. Vamos falar de LOGS CUSTOMIZADOS.

Um dos maiores desafios é acompanhar o que acontece em uma aplicação desenvolvida internamente na empresa. Aplicações Node.JS, PHP, Ruby e outras possuem seu padrão de log (like log4xxx).

A maioria dos desenvolvedores possui o hábito de criar seus logs no filesystem e, posteriormente, possuem a dificuldade de acompanhar o que acontece.

 

Mas, afinal, o que é o Graylog?

O Graylog é um sistema que tem como objetivo centralizar e catalogar log’s.

Com o Graylog se torna mais simples a auditoria e a identificação de diversos eventos em um ambiente em seu datacenter. Desenvolvimento pela empresa Alemã Torch, sobe licença da GPLv3 é um software totalmente Open Source.

Com o Graylog2 é possível realizar a consolidação, analise e gerenciamento dos log’s. Por possuir um processador de mensagens e um gerenciador de alertas, ele torna o gerenciamento muito mais robusto que um simples servidor de log.

Através do Graylog-Web é possível criar e gerenciar os eventos de forma padronizada, tornando mais simples e possível a localização de um determinado evento.

Além dos padrões normais de LOGs, como os gerados pelo Syslog, o Graylog possui um padrão denominado GELF.

GELF | Graylog Extended Log Format.

O GELF é o protocolo desenvolvido pela empresa TORCH. Tem como função o envio de mensagens através do protocolo UDP. Através deste formato é possível obter com detalhes os eventos de diversas aplicações. Existem diversos conectores desenvolvidos para esse protocolo, alguns deles: (Java, Ruby e PHP).

Mas, o que há de tão bom no protocolo GELF? Ele aborda algumas (se não a maioria) das falhas do protocolo syslog.

Com o protocolo syslog, uma mensagem de log é principalmente uma sequência em bruto, com muito pouco metadados. Há algum tipo de acordo entre os emissores e receptores; uma mensagem syslog válida deve ser formatada de uma maneira específica, permitindo extrair as seguintes informações:

  • uma priority: é uma mensagem de debugging, um aviso, algo puramente informativo, um erro crítico, etc;
  • uma timestamp mostrando quando a coisa aconteceu;
  • um hostname indicando onde a coisa aconteceu (ou seja, em qual máquina);
  • uma facility que indica se a mensagem vem do sistema de correio, do kernel e tal e tal;
  • um nome e número de processo;

Esse protocolo foi ótimo nos anos 80 (e até nos anos 90), mas tem algumas deficiências:

  • como ele evoluiu ao longo do tempo, há quase 10 diferentes RFCs para especificar, estender e adaptar para vários casos de uso;
  • o tamanho da mensagem é limitado, o que significa que mensagens muito longas (por exemplo: rastreamento) têm de ser truncadas ou divididas entre mensagens;
  • no final das contas, mesmo que alguns metadados possam ser extraídos, a carga é uma simples cadeia de texto sem adornos.

GELF fez um movimento muito arriscado e decidiu que cada mensagem de log seria um dict (ou um mapa ou um hash ou como você quiser chamá-los). Este “dict” teria os seguintes campos:

  • versão;
  • host (que enviou a mensagem em primeiro lugar);
  • timestamp;
  • versão curta e longa da mensagem;
  • qualquer campo extra que você quiser!

Isso também significa que os logs ficam armazenados como objetos estruturados, em vez de strings raw. Como resultado, você pode fazer consultas elaboradas (algo como SQL) em vez de cavar expressões regulares com o grep como se fosse um roedor.


Como o propósito é falar de ferramentas que eu já tenha implementado, implementei no final de dezembro uma estrutura que comporta atualmente mais de 2.000 msgs/s:

 
1.500msg/s (em um sábado às 20:00hs, sem usuários)

Ao todo, por dia, são mais de 100M (100.000.000) de mensagens de log de aplicações capturadas pela solução:

 

Implementamos um padrão de log com GELF, com vários campos personalizados, implantado em todas as aplicações — incluindo no CRUD do banco de dados, ou seja, todas as informações necessárias para uma trilha de auditoria.

Hoje podemos filtrar por módulo da aplicação, por dados específicos como, por exemplo, o CNPJ que estava processando e gerou o log.

Nosso objetivo como CTO e/ou Arquiteto de Soluções visa entregar para o negócio soluções que resolvam problemas de gestão (não somente na TI, mas na empresa como um todo).

Na próxima semana, um novo capítulo da série :-)