Como a agregação de métricas é diferente da agregação de log? Os logs não podem incluir métricas? Os sistemas de agregação de logs não podem fazer as mesmas coisas que os sistemas de agregação de métricas?

Estas são perguntas que ouço com frequência. Eu também já vi fornecedores lançando seu sistema de agregação de logs como a solução para todos os problemas de observabilidade. A agregação de logs é uma ferramenta valiosa, mas normalmente não é uma boa ferramenta para dados de séries temporais.

Um par de recursos valiosos em um sistema de agregação de métricas de séries temporais são o intervalo regular e o sistema de armazenamento personalizado especificamente para dados de séries temporais. O intervalo regular permite que um usuário obtenha resultados matemáticos reais de forma consistente. Se um sistema de agregação de logs estiver coletando métricas em um intervalo regular, ele pode potencialmente funcionar da mesma forma. Entretanto, o sistema de armazenamento não é otimizado para os tipos de consultas típicas em um sistema de agregação de métricas. Essas consultas levarão mais recursos e tempo para processar usando sistemas de armazenamento encontrados em ferramentas de agregação de logs.

Então, sabemos que um sistema de agregação de logs provavelmente não é adequado para dados de séries temporais, mas para que ele é bom? Um sistema de agregação de logs é um ótimo lugar para a coleta de dados de eventos. Estas são atividades irregulares que são significativas. Um exemplo pode ser logs de acesso para um serviço web. Estes são significativos porque queremos saber o que está acessando nossos sistemas e quando. Outro exemplo seria uma condição de erro da aplicação – porque não é uma condição normal de operação, pode ser valiosa durante a solução de problemas.

Uma mão cheia de regras para o log:

• DO incluir um carimbo de tempo
• DO no formato JSON
• DON’T log events insignificantes
• DO log all application errors
• MAYBE log warnings
• DO turn on logging
• DO write messages in a human-formulário legível
• DON’T log dados informativos em produção
• DON’T log qualquer coisa que um humano não possa ler ou reagir

Custos em nuvem

Quando se investiga ferramentas de agregação de log, a nuvem pode parecer uma opção atraente. No entanto, pode vir com custos significativos. Os logs representam muitos dados quando agregados em centenas ou milhares de hosts e aplicativos. A ingestão, armazenamento e recuperação desses dados são caros em sistemas baseados em nuvem.

Como ponto de referência de um sistema real, uma coleção de cerca de 500 nós com algumas centenas de aplicativos resulta em 200GB de dados de log por dia. Há provavelmente espaço para melhorias nesse sistema, mas mesmo reduzi-lo pela metade vai custar quase 10.000 dólares por mês em muitas ofertas SaaS. Isso geralmente inclui retenção de apenas 30 dias, o que não é muito longo se você quiser olhar as tendências dos dados ano após ano.

Isso não é para desencorajar o uso desses sistemas, pois eles podem ser muito valiosos – especialmente para organizações menores. O objetivo é ressaltar que pode haver custos significativos, e pode ser desencorajador quando eles são realizados. O resto deste artigo focará em soluções de código aberto e comerciais que são auto-hospedadas.

Opções de ferramentas

ELK

ELK, abreviação para Elasticsearch, Logstash e Kibana, é a ferramenta de agregação de log de código aberto mais popular no mercado. É usada pela Netflix, Facebook, Microsoft, LinkedIn, e Cisco. Os três componentes são todos desenvolvidos e mantidos pela Elastic. A Elasticsearch é essencialmente uma implementação do motor de busca NoSQL, Lucene. Logstash é um sistema de log pipeline que pode ingerir dados, transformá-los e carregá-los em uma loja como a Elasticsearch. Kibana é uma camada de visualização no topo do Elasticsearch.

A poucos anos atrás, Beats foram introduzidos. Os Beats são coletores de dados. Eles simplificam o processo de envio de dados para Logstash. Ao invés de precisar entender a sintaxe apropriada de cada tipo de log, um usuário pode instalar um Beat que exportará os logs NGINX ou os logs proxy Envoy corretamente para que eles possam ser usados efetivamente dentro do Elasticsearch.

Ao instalar uma pilha ELK de nível de produção, algumas outras peças podem ser incluídas, como Kafka, Redis, e NGINX. Também, é comum substituir Logstash por Fluentd, que discutiremos mais tarde. Este sistema pode ser complexo de operar, o que em seus primeiros dias levou a muitos problemas e reclamações. Estes foram em grande parte corrigidos, mas ainda é um sistema complexo, então você pode não querer tentar se você for uma operação menor.

Que dito isso, há serviços disponíveis, então você não precisa se preocupar com isso. Logz.io irá executá-lo para você, mas a lista de preços é um pouco íngreme se você tiver muitos dados. É claro, você provavelmente é menor e pode não ter muitos dados. Se você não pode pagar Logz.io, você pode olhar para algo como AWS Elasticsearch Service (ES). ES é um serviço que a Amazon Web Services (AWS) oferece que torna muito fácil pôr o Elasticsearch a funcionar rapidamente. Ele também tem ferramentas para obter todos os logs AWS no ES usando Lambda e S3. Esta é uma opção muito mais barata, mas há alguma gestão necessária e há algumas limitações.

Elastic, a empresa mãe da pilha, oferece um produto mais robusto que usa o modelo de núcleo aberto, que fornece opções adicionais em torno de ferramentas analíticas, e relatórios. Ele também pode ser hospedado na plataforma Google Cloud Platform ou AWS. Esta pode ser a melhor opção, já que esta combinação de ferramentas e plataformas de hospedagem oferece uma solução mais barata do que a maioria das opções SaaS e ainda fornece muito valor. Este sistema pode efectivamente substituir ou dar-lhe a capacidade de um sistema de informação de segurança e gestão de eventos (SIEM).

A pilha ELK também oferece grandes ferramentas de visualização através do Kibana, mas falta-lhe uma função de alerta. Elastic fornece funcionalidade de alerta dentro do add-on X-Pack pago, mas não há nada integrado para o sistema de código aberto. Yelp criou uma solução para este problema, chamada ElastAlert, e provavelmente existem outras. Este software adicional é bastante robusto, mas aumenta a complexidade de um sistema já complexo.

Graylog

Graylog aumentou recentemente em popularidade, mas começou a funcionar quando Lennart Koopmann o criou em 2010. Uma empresa nasceu com o mesmo nome dois anos mais tarde. Apesar da sua crescente utilização, ainda está muito atrás da pilha ELK. Isso também significa que ela tem menos recursos desenvolvidos pela comunidade, mas pode usar as mesmas batidas que a pilha ELK usa. O Graylog ganhou elogios na comunidade Go com a introdução do Graylog Collector Sidecar escrito em Go.

Graylog usa Elasticsearch, MongoDB, e o Graylog Server sob o capô. Isto torna a execução tão complexa quanto a pilha ELK e talvez um pouco mais. Entretanto, o Graylog vem com alertas incorporados na versão open source, assim como vários outros recursos notáveis como streaming, reescrita de mensagens e geolocalização.

O recurso streaming permite que os dados sejam encaminhados para Streams específicos em tempo real enquanto eles estão sendo processados. Com esta funcionalidade, um utilizador pode ver todos os erros da base de dados num único Stream e os erros do servidor Web num Stream diferente. Os alertas podem até ser baseados nestes Streams à medida que novos itens são adicionados ou quando um limite é excedido. A latência é provavelmente um dos maiores problemas com sistemas de agregação de logs, e os Streams eliminam esse problema no Graylog. Assim que o log chega, ele pode ser roteado para outros sistemas através de um Stream sem ser processado completamente.

O recurso de reescrita de mensagens usa o mecanismo de regras de código aberto Drools. Isto permite que todas as mensagens recebidas sejam avaliadas contra um arquivo de regras definido pelo usuário, permitindo que uma mensagem seja descartada (chamada Blacklisting), um campo seja adicionado ou removido, ou a mensagem seja modificada.

O recurso mais legal pode ser a capacidade de geolocalização do Graylog, que suporta a plotagem de endereços IP em um mapa. Esta é uma funcionalidade bastante comum e também está disponível no Kibana, mas adiciona muito valor – especialmente se você quiser usar isto como seu sistema SIEM. A funcionalidade de geolocalização é fornecida na versão de código aberto do sistema.

Graylog, a empresa, cobra pelo suporte na versão de código aberto se você quiser. Ela também oferece um modelo de núcleo aberto para sua versão Enterprise que oferece arquivamento, registro de auditoria e suporte adicional. Não há muitas outras opções de suporte ou hospedagem, então você provavelmente estará por conta própria se você não usar Graylog (a empresa).

Fluentd

Fluentd foi desenvolvido na Treasure Data, e a CNCF adotou-o como um projeto Incubador. Foi escrito em C e Ruby e é recomendado pela AWS e Google Cloud. Fluentd se tornou um substituto comum para Logstash em muitas instalações. Ele atua como um agregador local para coletar todos os logs dos nós e enviá-los para sistemas centrais de armazenamento. Não é um sistema de agregação de logs.

Utiliza um sistema plugin robusto para fornecer integrações rápidas e fáceis com diferentes fontes de dados e saídas de dados. Como há mais de 500 plugins disponíveis, a maioria de seus casos de uso deve ser coberta. Se não estiverem, isto parece uma oportunidade de contribuir de volta para a comunidade de código aberto.

Fluentd é uma escolha comum em ambientes Kubernetes devido aos seus baixos requisitos de memória (apenas dezenas de megabytes) e ao seu alto rendimento. Num ambiente como o Kubernetes, onde cada pod tem um sidecar Fluentd, o consumo de memória irá aumentar linearmente com cada novo pod criado. Usando o Fluentd irá reduzir drasticamente a utilização do seu sistema. Isto está se tornando um problema comum com ferramentas desenvolvidas em Java que são destinadas a rodar um por nó onde a sobrecarga de memória não tem sido um grande problema.