Como encaminhar logs de aplicativos de contêineres do Docker para o ELK

3

Estou tentando centralizar o registro em um ambiente que usa várias tecnologias de aplicativos (Java, Rails e vários bancos de dados).

Queremos que os desenvolvedores criem pilhas com o Docker Compose, mas queremos que eles se refiram a uma fonte de log central (ELK) para depurar problemas, em vez de tentar abrir shells em contêineres do Docker em execução.

Todos os aplicativos gravam no sistema de arquivos em vez de no STDOUT / STDERR, que remove todas as opções associadas ao driver de registro do Docker e ao logspout também.

O que fizemos foi configurar os contêineres para que o rsyslog inclua os arquivos de log do aplicativo e os encaminhe para o logstash, que possui uma entrada de syslog. Isso funciona em termos de mover os logs de A para B, mas o gerenciamento de logs de multitecnologia no ELK com base na entrada do syslog é horrível (por exemplo, tentar capturar rastreamentos de várias cadeias Java ou consultas lentas do MySQL).

Existe uma maneira melhor de fazer isso? Devo estar executando o logstash em cada contêiner, para que eu possa aplicar filtros e codecs diretamente aos arquivos de log, para que eu não precise confiar na entrada do syslog?

Existe alguma maneira de usar o driver de registro do Docker com arquivos de log de aplicativo que são gravados no sistema de arquivos?

    
por Garreth McDaid 21.03.2017 / 15:44

2 respostas

2

Versões recentes do Docker suportam a transmissão de logs no formato 'GELF' para uma porta de rede. O Logstash tem uma entrada GELF. Você pode executar o Logstash em cada nó e ter todas as instâncias do Docker no nó encaminhadas para ele.

Como uma entrada do Logstash: link

gelf {
}

Para saída do Docker: link

$ docker run -dit \
             --log-driver=gelf \
             --log-opt gelf-address=udp://127.0.0.1:12201 \
             alpine sh

(O endereço gelf é de fora da perspectiva dos contêineres, não dentro)

    
por 21.03.2017 / 15:52
0

Você também pode configurar o logstash para analisar os vários arquivos de log json que o docker produz por padrão.

Outra abordagem é usar o que é chamado de sidecar no Kubernetes.

Eles fornecem alguns exemplos diferentes em sua página de conceitos registro em cluster .

Como você escolhe aplicar esse conceito depende totalmente de suas necessidades.

No entanto, uma simples prova de conceito pode funcionar por:

  • criando um sidecar de logstash que aceita fluxos de syslog recebidos (por exemplo, usa a entrada do syslog)
  • configurando todos os contêineres para usar o driver syslog do docker para enviar o registro para o sidecar.

Você também pode, é claro, configurar um ouvinte syslog central (usando logstash ou rsyslog, por exemplo) e fazer isso sem um sidecar.

Essa abordagem também é muito parecida com a sugestão do @ Jason Martin de usar o GELF.

Outro uso de um sidecar local pode ser criar um contêiner executando o logstash com um entrada de arquivo e expôs um volume de log (por exemplo, / var / log / ou / logs). Você poderia compartilhar esse volume com outros contêineres, para permitir que eles gravassem seus registros (por exemplo, /logs/$INSTANCE_ID/file.log) e fizessem o logstash analisá-los.

Esta última configuração permite monitorar os arquivos em vez de STDOUT / STDERR, mas você provavelmente terá que ter seu diretório de log chmod 1777 (ou ter vários desses sidecars).

A configuração 'reversa' também funcionaria, é claro (mas parece mais difícil de gerenciar / manter): faça com que os contêineres de aplicativos exponham um volume de log e faça uma transação lateral do logstash ler o conteúdo do volume de log.

    
por 21.03.2017 / 16:57