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


8

Temos vários aplicativos que estão gerando seus próprios arquivos de log de texto sem formatação, que eu gostaria de encaminhar para um servidor syslog remoto para registro centralizado. Não tenho acesso a rootessas máquinas, nem posso reconfigurar syslogpara redirecionar a saída para uma máquina remota.

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

De preferência, algo projetado de olho em uma pequena área ocupada, daemon em segundo plano que continua em execução, que pode acompanhar muitas linhas etc. - Quais soluções estão disponíveis no momento?



@yoonix: Não, eu não tenho, mas eu vou :)
Michael Martinez

3
O syslog pode enviar para servidores syslog remotos. Configure o seu syslog local para enviar para um servidor remoto. Em seguida, acesse o syslog local por meio das chamadas syslog padrão ou usando o logger ou algo assim.
Zoredache

4
Por que você não escreve seus arquivos de log para um pipe nomeado e ter uma escuta daemon que os envia em seu caminho serverfault.com/questions/189477/...
user9517

3
Você não precisa modificar o aplicativo, basta colocar um canal nomeado com o mesmo nome que o arquivo de log no qual o aplicativo está gravando.
user9517

Respostas:


13

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


Uma opção melhor que requer menos hackers de script está sendo usada rsyslogde o módulo de entrada de arquivo de texto como yoonix mencionado - Esta é uma solução bastante decente, embora exista um potencial de linhas perdidas durante uma rotação de arquivo, e se você estiver em um sistema Linux com rsyslogcomo seu daemon syslog, não há muito trabalho adicional necessário.

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


IMHO, a melhor solução - embora exija a modificação do aplicativo que gera esses logs - é efetuar logon no syslog diretamente. Você não quer passar por etapas intermediárias, arquivos, etc. - syslogé o SYStem LOGger, e as coisas que escrevem logs em uma plataforma Unix devem enviá-las para o syslog.
Infelizmente, a implementação disso é deixada como um exercício para o leitor (e desenvolvedor de aplicativos) e pode não ser possível se os desenvolvedores forem inexistentes, preguiçosos ou incompetentes.


7
@MichaelMartinez Você modifica a rsyslogconfiguração atualmente em execução no sistema. Você NÃO deve estar executando dois daemons syslog. Para não ser rude, mas você precisa parar de tentar fazer algo errado *: Toda solução adequada para esse cenário requer ações administrativas (raiz) no servidor ou modificação do aplicativo. Você terá que enfrentar essa realidade e lidar com qualquer grupo dentro da sua organização que tenha raiz nos sistemas em questão; caso contrário, essa pergunta será fora de tópico (você está tentando burlar as políticas da sua organização) ...
voretaq7

5
@ Michael Tudo isso nos diz que alguém está tentando forçar a equipe errada a implementar a correção.
Andrew B

4
@MichaelMartinez imho, isso parece uma rota bastante rápida para níveis incapacitantes de dívida técnica.
Sirex 29/10

2
@Sirex. Seja como for, é o caminho das coisas. Eu trabalho em uma organização que emprega 10s de milhares de pessoas, a maioria dos quais são técnicos (engenheiros, dev, ops, etc.)
Michael Martinez

5
Eu acho. Geralmente, descobri a longo prazo que não há medalhas para vencer batalhas auto-infligidas. Quando a dívida técnica chega ao ponto de afetar os negócios ironicamente, as pessoas que trabalharam arduamente para evitar o elefante na sala tendem a acabar carregando a lata, na minha experiência. Então, eu diria: cubra sua bunda e peça a alguém que concorde em escrever as desvantagens disso.
Sirex 29/10

6

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

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

file-to-syslog.conf:

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

O logstash inicial com

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

+1. se o uso da entrada de arquivo do rsyslog não for uma opção, o logstash é a próxima melhor opção. De muitas maneiras, é melhor a longo prazo.
Sirex

Eu não estou familiarizado com isso. Se ele fizer o que eu preciso, teria me poupado do trabalho de invadir o coreutils e o util-linux.
Michael Martinez

Sim, a configuração ficará mais ou menos assim: pastebin.com/xeC9hxD3
Sirex

parece uma ferramenta muito legal, mas definitivamente um exagero para o que eu preciso aqui. O logstash é seu próprio serviço, com interface da web, requer java, etc. Continuarei a usar meu registrador de arquivos, que é leve e compacto, otimizado para desempenho. ... Mas, obrigado por sugerir o logstash porque eu posso ver a necessidade dele em outras situações no futuro!
Michael Martinez

Sim, é uma ferramenta jruby cheia de jar. O gui é na verdade kibana, que é empacotado para facilitar, mas na verdade é um projeto separado, portanto não é necessário apenas para analisar mensagens. É basicamente um canivete suíço de exploração madeireira. Você define entradas e saídas e no meio pode opcionalmente grok os logs, o que lhes dá contexto. - É provável que seja um exagero para você, a menos que você também deseje usar a pesquisa elástica em seus dados de log.
Sirex

4

Eu hackeei juntos tail.ce logger.cem um único programa compacto de pegada pequena (binário) que é leve, rápido e estável. Desde que tenha acesso de leitura ao (s) arquivo (s) de log, 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 sequência de texto no início de cada linha de registro antes de ser enviada ao servidor de registro. O resultado é um programa que pode ser executado sozinho, sem a necessidade de usar pipes de shell (ou seja, não é necessário tail logfile | logger). Ele será executado para sempre até ser explicitamente eliminado ou encontrar um erro ao gravar no soquete de rede. Ele ainda continua a ser executado se o arquivo de log for girado ou até desaparecer (ele continuará a verificar se o arquivo reaparece).

É fácil de usar: basta fornecer um ou mais arquivos de log 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ê especificar. Além disso, a sequência de texto extra se você usar essa opção.

Na verdade, terminei o programa em dezembro, mas estava esperando o Yahoo obter os direitos autorais e disponibilizá-lo, o que eles já fizeram. (Eu escrevi como parte do meu trabalho no Yahoo).

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


@slm: Eu reescrevi como você pediu
Michael Martinez

Muito útil, obrigado Michael. Alguma chance de empacotá-lo para a instalação do debian apt-get?
Joelparkerhenderson 19/09/15

@joelparkerhenderson. Oi Joel. Infelizmente, provavelmente não porque eu não trabalho com o debian. Você já tentou copiar o binário para o seu sistema e ver se ele é executado?
Michael Martinez

1

Existem várias maneiras de resolver isso. Mas o muito, muito primeira coisa que você deve fazer é: encaminha os logs usando syslog si .

O syslog (e muitas substituições para o syslog) possui recursos internos para encaminhar o log 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 o qual encaminhar o recurso. Por exemplo, adicionando esta linha a:

*.*    @192.168.1.1

... encaminharia todas as instalações para a máquina em 192.168.1.1, que (espero) tenha o serviço em execução. O exemplo que eu dou aqui é para o rsyslog, que é o servidor de estoque do syslog no Debian, embora deva funcionar para muitos outros. Consulte a documentação para sua implementação do syslog man sysloge veja o que diz sobre "encaminhamento".

O servidor syslog remoto pode ser o que você quiser. Há ainda produtos, como Splunk , que felizmente agregar esses logs em uma única visualização com um painel web, pesquisa, notificações dirigidas a eventos, etc. etc. Você pode ver mais aqui: http://www.splunk.com/ Se que não atende às suas necessidades, você pode usar outra coisa. Existem até 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 entregue a você?


Edit: Então eu voltei e reli a pergunta, e notei vários comentários. Parece:

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

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

  1. O syslog foi criado para agregar logs juntos. Você pode usar o que quiser, mas há uma razão pela qual ela existe há muito tempo. É bem testado, bem depurado, bem documentado, conhecido e para a maioria das plataformas * nix quase universalmente suportadas em um sabor ou outro.
  2. não precisamos acessar rootpara configurar o log. Nós precisamos apenas acessar a API syslog. rootnão é um requisito para gravar no syslog; se esse fosse o caso, todos os serviços que eliminassem privilégios não conseguiriam gravar diagnósticos nos arquivos de log.
  3. Re: despejos de texto, isso é normal. no entanto, você 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 quebradiço e está bem documentado. De fato, é um dos motivos pelos 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, escreva um desvio para despejar a saída de texto no syslog em vez de um arquivo de texto sem formatação. Isso não deve ser muito difícil; tudo o que você faz é pegar as linhas que você produziria e envolvê-las com uma chamada. Contudo....

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


duas razões: (1) simplesmente porque, como já mencionado, não tinha raiz ou sudo nas caixas em questão. (2) o próprio "logger" pode encaminhar para o servidor remoto, mas possui um limite de 400 caracteres por linha de log, o que não é apropriado para os logs do Apache. De qualquer forma, eu já montei uma solução personalizada que faz exatamente o que eu precisava (e melhora o "logger" também). Veja minha resposta aqui para "filelogger"
Michael Martinez

4. O Syslog não é apenas um fluxo de arquivos no qual posso abrir e escrever texto. O shunt que eu escrevo teria que abrir um soquete para a porta UDP que o syslog escuta?
Noumenon

1
@Noumenon, não estou totalmente esclarecido sobre sua intenção, mas suponho que você queira canalizar a saída do programa no log do sistema, o que pode ser feito com o comando logger. linux.die.net/man/1/logger
Avery Payne

@ AveryPayne Assim como Runtime.exec("logger ...") OK, obrigado.
Noumenon

0

Estou respondendo minha própria pergunta.

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

Portanto, a primeira coisa que fiz foi fazer o download do código-fonte do util-linux-2.20.1, para o qual o programa logger suporta log remoto. Após o teste, ficou claro que há um limite imposto ao número de caracteres permitido na linha de log. Ao pesquisar no código fonte, encontrei um limite de 400 caracteres codificado. (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 log do tipo apache (incluindo nodejs), portanto, modifiquei o código e aumentei o limite para 4096. Enquanto estava nele, também adicionei uma nova opção de linha de comando que permite inserir um opcional sequência de texto no início de cada linha de log. Fiz isso porque os logs do nodejs não incluem o nome do host como se poderia ver no apache.

Nesse ponto, eu poderia executar um script de shell com "tail -F -n 0 [arquivo de log] | ./modified_logger ...." e funcionou. Mas eu tinha algumas preocupações sobre executar isso da supervisão (daemontools) ou mesmo em segundo plano, porque se um ou os outros lados do tubo terminarem, haverá o risco de todo o tubo terminar. Eu também tinha preocupações (embora não testadas) sobre desempenho.

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

O resultado é um novo binário (tamanho de 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, via UDP ou TCP. Ele funciona como um encanto. Consegui fazer um pequeno teste comparativo e ele registra cerca de 17.000 linhas (1,8 MB) em cerca de 3 segundos em sub-redes com uma vlan e alguns comutadores físicos entre elas, em um servidor remoto executando o syslog-ng.

Para executar o programa, faça algo como o seguinte (em primeiro plano, em segundo plano ou supervisionado com daemontools):

./filelogger -t 'access' -d -p local1.info -n [host de log remoto] -u / tmp / ignorado -a $ (nome do host) / 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. Nesse caso, insiro o nome do host local no início de cada linha de log.

Essas soluções eram exatamente o tipo de solução que eu estava procurando quando fiz a pergunta e, como se viu, não existia até que eu a fiz. :)


Provavelmente disponibilizarei isso no sourceforge em algum momento. Suas vantagens são que é um espaço muito pequeno, leve, fácil de usar e otimizado para desempenho. Depois que o texto da mensagem é lido, todo o processamento é feito no buffer de memória e depois transferido diretamente para o soquete.
Michael Martinez


4
Eu estou tentando não ser dura, mas eu estou indo para ser franco: Esta solução não existisse, porque é terrível. Em vez de fazer interface com os outros grupos da sua organização e implementar uma solução padrão e sadia, você lançou um hack no lugar com código totalmente não suportado, que agora você precisa testar / depurar / manter no futuro. Você ignorou facilmente mais de 50 anos de experiência combinada dizendo "Não faça isso" - espero que isso não exploda na sua cara, mas você está absolutamente, inquestionavelmente, fazendo errado aqui ...
voretaq7

1
sim. certo .... É assim que o código aberto avança, cara. Se todos fizessem do seu jeito, não haveria progresso. Como você acha que o GNU, Linux e tudo o que se baseia nele surgiu? Pessoas fazendo exatamente o tipo de coisa que eu fiz aqui. Se você se sentir melhor, pretendo inserir meu código em nosso sistema de gerenciamento de pacotes, onde todos os membros da organização podem usá-lo, implementá-lo e aprimorá-lo, se assim o desejarem.
22813 Michael Martinez

E para sua informação, não é uma solução terrível. Pelo contrário, é uma ferramenta muito útil. Quando eu estava pesquisando on-line por soluções na semana passada, me deparei com outras pessoas perguntando onde poderiam encontrar essa funcionalidade exata.
Michael Martinez
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.