Linux: como enviar novas linhas em arquivos de log para o syslog remoto?

Question

Temos vários aplicativos que estão gerando seus próprios arquivos de log de texto simples, que eu gostaria de encaminhar para um servidor syslog remoto para log centralizado. Eu não tenho acesso a root nessas máquinas, nem posso reconfigurar syslog para redirecionar a saída para uma máquina remota.

Encontrei algumas soluções on-line, mas são principalmente scripts de bash caseiros de pessoas, e estou procurando algo mais robusto que seja adequado para implementação em um ambiente de produção de alto volume.

De preferência, algo projetado com um olho para uma pegada pequena, um daemon de fundo que continue em execução, que possa acompanhar muitas linhas, etc. - Quais soluções estão disponíveis atualmente?

    

Answer 1

Eu agrupei tail.c e logger.c em um único programa compilado (binário) que é leve, rápido e estável. Desde que tenha acesso de leitura ao (s) arquivo (s) de log, ele funcionará sem a necessidade de privilégios de root.

Também fiz algumas melhorias no criador de logs nativo e adicionei um novo recurso (opcional) de inserir uma cadeia de texto no início de cada linha de log antes que ela seja enviada ao servidor de log. O resultado é um programa que pode ser executado sozinho, sem a necessidade de usar canos shell (ou seja, não é necessário tail logfile | logger ). Ele será executado para sempre até que seja explicitamente eliminado ou encontre um erro ao gravar no soquete da rede. Ele ainda continua a ser executado se o arquivo de log for girado ou até mesmo desaparecer (ele apenas continuará a procurar para ver se o arquivo reaparece).

É fácil de usar: basta dar a ele um ou mais arquivos de registro para monitorar, e toda vez que uma nova linha for gravada no arquivo, ele enviará uma cópia dessa linha para o servidor syslog local ou remoto que você especificamos. Mais a sequência de texto extra se você usar essa opção.

Eu realmente terminei o programa em dezembro, mas estava esperando que o Yahoo pegasse os direitos autorais e os disponibilizasse, o que eles fizeram agora. (Eu escrevi como parte do meu trabalho no Yahoo).

informações do programa filelogger e link de download:

• Postagem do blog sobre o filelogger
• GitHub Repo para filelogger

Answer 2

Você já rejeitou os "scripts bash de outras pessoas", mas essa é uma solução bastante comum - alguns uso criativo do comando logger pode seguir um arquivo e enviar seu conteúdo para outro lugar.
Eu pessoalmente não faria isso em um ambiente de produção.

A melhor opção que requer menos hackers de script é usar rsyslogd e o módulo de entrada de arquivo de texto como < href="https://serverfault.com/questions/547938/linux-how-to-send-new-lines-in-log-files-to-remote-syslog?noredirect=1#comment632740_547938"> yoonix mencionado - Esta é uma solução decente, embora exista algum potencial para perda de linhas durante uma rotação de arquivos, e se você estiver em um sistema Linux com rsyslog como seu daemon syslog, não há muito trabalho adicional necessário.

syslog-ng também suporta uma fonte de entrada de arquivo com funcionalidade semelhante a rsyslog 's.

IMHO a melhor solução - embora um que requer a modificação do aplicativo gerando esses logs - é logar ao syslog diretamente. Você não quer estar passando por etapas intermediárias, arquivos, etc. - syslog é o SYStem LOGger, e as coisas que escrevem registram em uma plataforma Unix devem estar enviando-as para o syslog. br> A implementação disso é, infelizmente, deixada como um exercício para o leitor (e para o desenvolvedor de aplicativos) e pode não ser possível se seus desenvolvedores forem inexistentes, preguiçosos ou incompetentes ...

    

Answer 3

Você pode usar o logstash com o entrada do arquivo e saída syslog .

Por exemplo, crie uma configuração com o arquivo (ou arquivos) que você deseja monitorar e as informações do seu servidor syslog.

arquivo-para-syslog.conf:

input { file { path => "/var/log/kern.log" } }
output {
    syslog {
        facility => "kernel"
        host => "syslog.example.com"
        port => 514
        severity => "informational"
    }
}

O logstash de inicialização com

java -jar logstash-1.2.2-flatjar.jar agent -f file-to-syslog.conf

    

Answer 4

Existem várias maneiras de lidar com isso. Mas a primeira coisa que você deve fazer é: encaminhar os logs usando o próprio syslog .

O syslog (e muitas substituições para o syslog) tem recursos internos para encaminhar o registro para outro servidor syslog em um endereço diferente. Você pode fazer isso facilmente alterando o arquivo de configuração e anexando o endereço para encaminhar o recurso. Por exemplo, adicionando esta linha a:

*.*    @192.168.1.1

... encaminhará todas as instalações para a máquina em 192.168.1.1, o que (esperançosamente) terá o serviço em execução. O exemplo que dou aqui é para o rsyslog, que é o servidor syslog da pasta no Debian, embora deva funcionar para muitos outros. Consulte a documentação para sua implementação do syslog com man syslog e veja o que ele diz sobre "encaminhamento".

O servidor syslog remoto pode ser o que você quiser. Existem até mesmo produtos, como Splunk , que agregam esses logs em uma única visualização com um painel da web, pesquisa, notificações orientadas a eventos, etc. etc. Você pode ver mais aqui: link Se isso não atender às suas necessidades, você pode usar outra coisa. Existem até mesmo servidores syslog que serão despejados em um banco de dados SQL!

Claro, você poderia escrever seu próprio script / programa / serviço para fazer isso por você, mas por que reinventar a roda quando ela é feita para você e já foi dada a você?

Editar: Então voltei e reli a pergunta e notei vários comentários. Parece que:

1. você deseja agregar seus registros do aplicativo
2. você não tem acesso ao root
3. seu (s) aplicativo (s) apenas despeja texto em algum lugar
4. seu (s) aplicativo (s) não sabe como escrever no syslog local
5. você não tem controle sobre o código-fonte do seu aplicativo

Então, vamos abordar cada um deles em sequência:

1. O syslog foi criado para agregar logs juntos. Você pode usar qualquer coisa que quiser, mas há uma razão pela qual existe há muito tempo. É bem testado, bem depurado, bem documentado, bem conhecido, e para a maioria das plataformas * nix quase universalmente suportado em um sabor ou outro.
2. não precisamos de acesso a root para configurar o registro. Nós só precisamos acessar a API do syslog. root não é um requisito para gravar no syslog; se esse fosse o caso, todos esses serviços que descartassem privilégios não conseguiriam gravar diagnósticos nos arquivos de log.

3. Re: despejos de texto, isso é normal. no entanto, você deve poder usar um subshell para canalizar a saída de STDERR e STDOUT para um programa que chama a API syslog. Isso não é ciência de foguetes, está longe de ser frágil e está bem documentado. Na verdade, essa é uma das razões pelas quais o redirecionamento de saída existe. Um comando simples que poderia ser lançado em um único script de shell seria:

   (meu-aplicativo 2 > & 1; meu-syslog-shunt) &

4. Se você tiver a capacidade de alterar o código-fonte do seu aplicativo, deverá escrever um shunt nele para despejar a saída de texto para o syslog, em vez de um arquivo de texto simples. Isso não deve ser muito difícil; tudo o que você faz é pegar as linhas que você enviaria e envolvê-las com uma chamada. No entanto ....

5. você pode não ter acesso ao código-fonte, então não pode fazer isso. O que significa que algo como o nº 3 acima funcionaria bem.

Answer 5

Estou respondendo minha própria pergunta.

swatch pode ter funcionado, mas não consegui fazer com que o módulo Sys :: Syslog do perl funcionasse no host, e o / usr / bin / logger instalado no host não suporta o logging para o servidor remoto (util-linux -ng-2.17.2).

Então, a primeira coisa que fiz foi baixar o código-fonte do util-linux-2.20.1 para o qual o programa logger suporta logging remoto. Após o teste, ficou claro que há um limite imposto ao número de caracteres permitidos na linha de registro. Indo para o código-fonte, encontrei um limite de 400 caracteres codificados. (Se você não acredita em mim, execute "strings / usr / bin / logger | grep 400" em qualquer sistema Linux).

Esse limite não é aceitável para o tipo de log do apache (incluindo nodejs), então eu modifiquei o código e aumentei o limite para 4096. Enquanto eu estava nisso, eu também adicionei uma nova opção de linha de comando que permite insira uma string de texto opcional no início de cada linha de log. Eu fiz isso porque os logs do nodejs não incluem o nome do host como alguém poderia ver no apache.

Neste ponto, eu poderia executar um script de shell com "tail -F -n 0 [logfile] | ./modified_logger ...." e funcionou. Mas eu tive algumas preocupações sobre a execução deste de supervise (daemontools) ou mesmo em segundo plano, porque se um ou os outros lados do tubo termina, então há o risco de que o tubo inteiro irá terminar. Eu também tive preocupações (embora não testadas) sobre desempenho.

então decidi combinar a funcionalidade tail com a funcionalidade logger em um único binário executável que contornaria a necessidade de usar pipes Unix ou programas externos. Eu fiz isso hackeando tail.c do gnu coreutils e incorporando o que eu preciso no programa de logger modificado.

O resultado é um novo binário (tamanho 117k) que estou chamando de "filelogger" e que monitora continuamente um ou mais arquivos e registra cada nova linha em um syslog local ou remoto, seja via UDP ou TCP. Ele funciona como um encanto. Eu consegui fazer um pouco de benchmarking e ele registra cerca de 17.000 linhas (1.8MB) em cerca de 3 segundos em sub-redes com uma vlan e alguns switches físicos entre elas, para um servidor remoto que executa o syslog-ng.

para executar o programa, você faz algo como o seguinte (em primeiro plano, plano de fundo ou supervisionado com daemontools):

./ filelogger -t 'access' -d -p local1.info -n [loghost remoto] -u / tmp / ignorado -a $ (hostname) / tmp / myfile1 / tmp / myfile2 ...

/ tmp / myfile1 e / tmp / myfile2 são os arquivos que estão sendo monitorados.

O "-a" é a nova opção que adicionei. Neste caso, insiro o nome do host local no início de cada linha de log.

Esta solução era exatamente o tipo de solução que eu estava procurando quando fiz a pergunta e, como se viu, não existia até que eu mesmo fizesse isso. :)