Engenharia

Autodescoberta baseada em dicas do Docker e Kubernetes com o Beats

A partir da versão 6.0, começamos a adicionar novos recursos ao Beats, melhorando nosso suporte ao monitoramento de containers. Recentemente introduzimos um novo recurso: A autodescoberta no Filebeat e Metricbeat, com suporte a Docker e Kubernetes. A autodescoberta permite definir um conjunto de configurações que serão iniciadas dinamicamente pelo Beats quando você quiser executá-las. Esse recurso é especialmente útil para monitorar containers, devido à sua natureza dinâmica.

O desafio do monitoramento de containers

Com infraestrutura tradicional, você normalmente configuraria um novo host, configuraria todos os serviços que seriam executados nele e configuraria o agente de monitoramento para consultá-los periodicamente. As ferramentas de gerenciamento de configuração ajudam na tarefa, mas o processo ainda é bastante estático.

Com a arquitetura de containers, tudo se transforma em um alvo em movimento. As implantações são dinâmicas, crescem, encolhem e desaparecem; os containers vão e vêm de um nó a outro. Não há IP fixo do qual seja possível recuperar suas métricas.

Precisamos de ferramentas específicas para rastrear tudo.

Beats autodiscover schematics

Autodescoberta

Vamos analisar como ele funciona. Veja uma configuração de amostra:

metricbeat.autodiscover:
  providers:
   - type: docker
     templates:
       - condition.contains:
           docker.container.image: etcd
         config:
          - module: etcd
            metricsets: ["leader", "self", "store"]
            hosts: "${data.host}:2379"

output.elasticsearch:
  hosts: ["localhost:9200"]

Esta é a configuração do Metricbeat para usar o provedor de autodescoberta de docker. Você pode definir uma lista de modelos que serão usados, vinculados à condição que deveria dispará-los. Nesse caso, a condição corresponde à imagem de container que contém etcd (usamos contém porque o campo de imagem armazena pares name:tag). Quando um container etcd é criado, o Metricbeat inicia o módulo etcd para monitorá-lo, substituindo a variável ${data.host} com o endereço IP do container.

Vamos ver como isso funciona em detalhes:

1. Eventos de autodescoberta

O Beats Autodiscover tem suporte a vários provedores, com o Kubernetes e Docker disponíveis no momento. Os provedores implementam uma maneira de assistir a eventos em uma plataforma específica. Quando acontece um evento, o provedor emite um evento de autodescoberta, contendo todas as informações necessárias para reagir a ele.

2. Correspondência de condições

Cada evento é verificado em confronto com uma lista de condições, usando o mesmo formato de configuração dos processadores. Se uma condição corresponder ao evento, ele gerará o conjunto fornecido de configurações para ele.

3. Expansão de variáveis

Os modelos de configuração podem conter variáveis, que são substituídas por valores reais do evento que disparou a condição. Esse mecanismo permite definir as configurações dinâmicas que podem depender do status de um container, como o endereço IP. Mas também permite configurações mais complexas, através do uso de identificações e anotações.

4. Configuração de início/parada

Depois que a configuração final for criada, ela será iniciada pelo processo de autodescoberta. Entre as configurações válidas estão módulos no Metricbeat e Filebeat, além de entradas neste último.

Existem eventos de início e parada, por isso uma configuração iniciada pela autodescoberta será interrompida automaticamente depois que o container desaparecer. Isso não requer nenhuma configuração especial.

Um ótimo recurso adicionado ao usar a autodescoberta é que todos os eventos originários dele serão enriquecidos automaticamente com os metadados do Docker ou Kubernetes, por isso não é necessário usar os processadores adddockermetadata ou addkubernetesmetadata. Esses metadados ajudarão durante a navegação de logs e métricas, permitindo-lhe filtrá-los e se concentrar naquilo que interessa.

Introdução às dicas

Com o lançamento da versão 6.3, agora você pode usar dicas para definir como monitorar containers. Tradicionalmente, era necessário atualizar o arquivo de configurações do Beats para configurar o monitoramento de um aplicativo recém-implantado.

A autodescoberta baseada em dicas inverte o controle das configurações de monitoramento, permitindo armazená-las ao lado do container de aplicativos em vez de um local central. Isso significa que a equipe que cria e implanta um aplicativo tem a capacidade de assumir a responsabilidade em definir como monitorá-lo.

Essa configuração permite a autodescoberta baseada em dicas para os logs de container do Kubernetes (essa alteração pode ser feita em nosso manifesto Kubernetes de referência para o filebeat, por exemplo):

filebeat.autodiscover:
  providers:
    - type: kubernetes
      hints.enabled: true

Trocando em miúdos: você pode usar as anotações Pod do Kubernetes ou as identificações do Docker para informar ao Filebeat e ao Metricbeat como tratar os logs de container. Por exemplo, se você estiver executando um aplicativo Java em um Pod, poderá adicionar estas anotações a ele:

annotations:
  co.elastic.logs/multiline.pattern: '^\['
  co.elastic.logs/multiline.negate: 'true'
  co.elastic.logs/multiline.match: after

Quando o Pod for iniciado, o Filebeat processará as anotações e iniciará a leitura de seus logs com o padrão multilinear fornecido, disposto a reunir stack traces Java. Você pode verificar a documentação referente a uma lista completa de dicas disponíveis.

Você também pode usar módulos para processar logs em dados estruturados, por exemplo, se estiver executando um servidor NGINX, bastará adicionar essas anotações e todos os respectivos logs serão processados para lhe fornecer informações sobre suas visitas:

annotations:
  co.elastic.logs/module: nginx
  co.elastic.logs/fileset.stdout: access
  co.elastic.logs/fileset.stderr: error

Como você pode ver, cada fluxo da saída de log é mapeado para um conjunto de arquivos diferente. Você também pode mapear todos os fluxos para um único conjunto de arquivos definindo apenas co.elastic.logs/fileset.

Também pode se beneficiar de dicas ao usar o Metricbeat; isso é como você configuraria a mesma instância NGINX para criar métricas de busca do Metricbeat a partir dela. Como você pode ver, a expansão de variáveis também está disponível aqui, ${data.host} é usado para assumir o endereço IP do container.

annotations:
  co.elastic.metrics/module: nginx
  co.elastic.metrics/metricsets: stubstatus
  co.elastic.metrics/hosts: '${data.host}:80'
  co.elastic.metrics/period: 10s

Leve em consideração que você pode usar ambos os conjuntos de dicas juntos, se estiver executando tanto o Filebeat quanto o Metricbeat.

Resumo

A autodescoberta baseada em dicas aproxima suas configurações de monitoramento dos aplicativos que você quer monitorar. Isso oferece as ferramentas certas para as equipes, principalmente em cenários multitenant. Também oferece um conjunto simples de instruções para se trabalhar, tornando a experiência simples e objetiva.

Só tratamos de uma pequena parte superficial daquilo que podemos fazer com a autodescoberta. Estamos ansiosos para receber seus comentários e saber como você está usando! Não esqueça de dar uma passada no nosso fórum do Beats e contar sua experiência.