Como obtenho a saída / erro padrão de um serviço, controlado pelo systemd no EL7, para ir a algum lugar diferente de / var / log / messages?

Question

Meus casos de uso são os registros duplicados do Fabrice A. Marie com o systemd artigo (publicado pela Kibin Labs) coloca em sua categoria "feia", e seu breve conselho para adicionar em uma pilha inteira ELK (é o "único recurso", diz) para "feio" é um exagero para as minhas necessidades.

A categorização de Fabrice A. Marie é de que os aplicativos "bons" podem ter saídas padrão redirecionadas para /dev/null sem perda de informações resultante, apenas escrevem muito pouco para erro padrão e, portanto, para /var/log/messages (através do diário systemd) e Envie o volume de seus logs através de mecanismos de log por aplicativo (não gerenciados pelo systemd ou rsyslog) para arquivos de log mantidos pelo aplicativo privado. Isto é, se for o caso, o reverter o que eu quero, e não "bom" pelos meus critérios.

Eu tenho vários aplicativos (um deles, escolhido por exemplo aqui, é pré-renderização de backend do phantomjs, mas isso é apenas um dos meus casos de uso) que são lançados como serviços no systemd. Meus aplicativos enviam seu log para saída padrão e erro padrão (sendo este o comportamento padrão normal de console.log() in node.js ). Parece errado que para torná-los qualificados como "bons" eles devem ser reescritos para fazer seu próprio registro privado, em vez de usar systemd para isso (como são agora). De qualquer forma, não estou em posição de recodificar essas aplicações sozinho.

Eu apareci, seguindo o que Fabrice A. Marie diz e pelo que mais li, para ter a escolha gritante de todas as informações padrão de saída / erro padrão indo para /dev/null ou para /var/log/messages . Não há mediana feliz? Não posso configurar o systemd (e qualquer outra coisa) para que os logs dos meus aplicativos, gravados na saída / erro padrão, sejam manipulados pelo systemd da maneira normal, sem uma pilha ELK inteira no meio e, ao mesmo tempo, acabem em outro lugar do que /var/log/messages ?

Estou executando o CentOS 7 e o RHEL 7, e a unidade de serviço do meu serviço de exemplo é atualmente:

[Unit]
Description=prerender
After=network.target
[Service]
ExecStart=/usr/local/bin/node /var/www/prerender/node/server.js
Restart=always
User=prerender
Group=adm
Environment=PATH=/usr/bin:/usr/local/bin PORT=8900
WorkingDirectory=/var/www/prerender/node
[Install]
WantedBy=multi-user.target

    

Answer 1

Esse artigo parece um disparate, colocando a culpa em outro software por problemas causados pela invasão hostil do systemd das funções de log. Ele até menciona a solução (syslog), mas apenas como um meio de sugerir um excesso massivo como logstash .

Você não precisa do logstash para registrar um punhado de daemons em um único host.

Do artigo:

And by default when it does this, stdout is redirected to the journal. The journal in turn is sent to syslog by default, which on RedHat 7 compatible distros will end up in /var/log/messages.

Em seguida, ele ignora completamente a opção óbvia e sensata de configurar rsyslogd e indica que logstash e elasticsearch são as únicas opções se você quiser fazer algo que o journald não pode fazer.

Os daemons syslog modernos, como rsyslog e syslog-ng , podem ser configurados para filtrar mensagens syslog por todos os tipos de critérios, incluindo o nome do daemon e a correspondência de padrões regex. O padrão pode ser /var/log/messages , mas é trivialmente fácil alterar o padrão.

Então, o que você precisa são algumas regras de rsyslog para filtrar mensagens do syslog do seu serviço.

Pegue o que os defensores do sistema dizem sobre extração de madeira com um enorme sal - eles gostam de fingir que journald era necessário porque a extração anterior era primitiva e inflexível, que eles estavam resolvendo um problema que ninguém havia pensado antes resolvido várias vezes.

Além disso, BTW, a maneira correta para um programa fazer logging não é stdout nem stderr, é usando as funções syslog que estão disponíveis na maioria das linguagens.