Estou tentando centralizar o log 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 STDOUT/STDERR, o que remove todas as opções associadas ao driver de registro do Docker e 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 logstash, que possui uma entrada syslog. Isso funciona em termos de mover os logs de A para B, mas gerenciar logs de multitecnologia em ELK com base na entrada do syslog é horrível (por exemplo, tentar capturar vários rastreamentos de pilha Java ou consultas lentas do MySQL).
Existe uma maneira melhor de fazer isso? Devo executar o logstash em cada contêiner, para poder aplicar filtros e codecs diretamente aos arquivos de log, para não precisar depender da entrada do syslog?
Existe alguma maneira de usar o driver de log do Docker com arquivos de log do aplicativo que são gravados no sistema de arquivos?
Versões recentes do Docker suportam a transmissão de logs no formato 'GELF' para uma porta de rede. 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 entrada do Logstash: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-gelf.html
Para saída do Docker: https://docs.docker.com/engine/admin/logging/overview/#gelf
(O endereço gelf é de fora da perspectiva dos contêineres, não de dentro)
Você também pode configurar o logstash para analisar os vários arquivos de log json produzidos por padrão.
Outra abordagem é usar o que é chamado de sidecar no Kubernetes.
Eles fornecem alguns exemplos diferentes em sua página de conceitos de criação de log de cluster .
Como você escolhe aplicar esse conceito depende inteiramente de suas necessidades.
No entanto, uma simples prova de conceito pode funcionar por:
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 segue a mesma linha da sugestão de @ Jason Martin de usar o GELF.
Outro uso de um sidecar local pode ser criar um contêiner executando logstash com um arquivo input e expor um volume de log (por exemplo, /var/log/ ou /logs). Você pode compartilhar esse volume com outros contêineres, para permitir que eles gravem seus logs (por exemplo, /logs/$INSTANCE_ID/file.log) e fazer com que o logstash os analise.
Esta última configuração permite monitorar arquivos em vez de STDOUT/STDERR, mas você provavelmente terá que ter seu diretório de log
chmod 1777
(ou vários 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 seu aplicativo exponham um volume de log e faça com que um sidecar logstash leia o conteúdo do volume de log.