rsyslog com logrotate: reload rsyslog vs copytruncate

Question

Estou trabalhando no Ubuntu 14 com o utilitário padrão rsyslog e logrotate.

No padrão rsyslog logrotate /etc/logrotate.d/rsyslog config eu vejo o seguinte:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

Pelo que entendi, é recomendado usar copytruncate em todos os cenários de logrotate, já que ele não move o log atual, mas trunca o log para que qualquer processo com um manipulador de arquivos aberto possa continuar escrevendo nele .

Então, como é que a configuração padrão usa o recurso de recarregamento do rsyslog?

    

Answer 1

Para responder à sua pergunta, primeiro você precisa entender os diferentes trade-offs de reload e copytruncate:

• reload : o arquivo de log antigo é renomeado e o processo de gravação nesse log é notificado (via sinal Unix) para recriar seu arquivo de log. Este é o método de overhead mais rápido / menor: as operações rename / move são muito rápidas e têm um tempo de execução constante. Além disso, é uma operação quase atômica: isso significa que (quase) nenhuma entrada de log será perdida durante a movimentação / recarga. Por outro lado, você precisa de um processo capaz de recarregar e reabrir seu arquivo de log. O Rsyslog é um processo desse tipo, portanto, a configuração padrão do logrotate usa o método de recarregamento. Usar este modo com o rsyslog é strongmente recomendado pelo rsyslog upstream.
• copytruncate : o arquivo de log antigo é copiado em um arquivo e, em seguida, é truncado para "excluir" linhas de log antigas. Enquanto a operação de truncagem é muito rápida, a cópia pode ser bastante longa (dependendo de quão grande é o seu logfile). Além disso, algumas entradas de log podem ser perdidas durante o tempo entre a operação de cópia (lembre-se, pode ser lento) e o truncamento. Por esses motivos, o copytruncate não é usado por padrão para serviços capazes de recarregar e recriar seus arquivos de log. Por outro lado, se um servidor não tiver capacidade de recarregar / recriar arquivos de log, o copytruncate é sua aposta mais segura. Em outras palavras, não requer nenhum suporte de nível de serviço. O projeto upstream do rsyslog recomenda strongmente contra o uso deste modo.

Answer 2

Falando como autor do rsyslog, copytruncate é na verdade uma escolha muito, muito, muito ruim. É inerentemente atrevido e usá-lo é quase uma garantia de que você perderá dados de log. Quanto mais frequentemente o arquivo é gravado, mais você perderá. E isso não é apenas parte da última linha, mas pode ser várias centenas, dependendo do momento exato e do estado do sistema no momento em que a rotação acontece.

Quando o arquivo é movido e um novo inode (arquivo) criado, o rsyslog mantém o controle do arquivo anterior e do processamento completo. Então você não tem nenhuma perda neste caso. Garantido (exceto se você desmontar o sistema de arquivos ...).

Em "reopenOnTruncate": Eu pessoalmente já vi o reopenOnTruncate ser atrevido em outros aspectos também, especialmente com NFS e afins. Algum tempo atrás, eu removi totalmente essa funcionalidade, mas depois fui persuadida a incorporar funcionalidades semelhantes de volta. Ficará "experimental" provavelmente para sempre, já que eu realmente sei que as pessoas enfrentam problemas em sistemas muito carregados. "copytruncate" é simplesmente nenhum modo decente para trabalhar com arquivos de log.

Atualmente, trabalho na refatoração de arquivos imfile (ETA 8.34 ou 8.35). A versão refatorada provavelmente será capaz de evitar o reenvio acidental devido à corrida da API, mas também não pode proteger contra perda de dados - porque isso é conceitualmente impossível.

    

Answer 3

Isso depende completamente de como o processo está gravando registros.
copytruncate só funciona, se as mensagens de log forem anexadas ao arquivo (por exemplo, whatever >> logfile .
E não quando está redirecionando a saída (por exemplo, whatever > logfile ).

    

Answer 4

Desde a versão 8.16, o rsyslog tem a opção imfile reopenOnTruncate , que trata do problema do copytruncte.

    

Answer 5

Para o rsyslog especificamente, provavelmente faz mais sentido deixar as coisas como estão.

O motivo básico é que o rsyslog tem filas internas que podem ser usadas nos casos em que o identificador de saída fica indisponível.

O recarregamento a) fará o rsyslog recriar seu próprio arquivo de log, eb) fará com que todos os eventos enfileirados sejam liberados para o arquivo na criação.

Pode ser que o copytruncate não cause nenhum dano (embora eu esteja preocupado com linhas parcialmente escritas sendo truncadas), mas eu tenderia a pensar que copy / delete / reload é 'mais seguro' do ponto de vista da integridade.

Como mencionado por @ falsificador , uma vez que o rsyslog pode lidar com a situação em que o arquivo fica indisponível, não há razão convincente para usar o copytruncate.

E, como mencionado por @ SelivanovPavel , o rsyslog requer uma configuração específica para lidar corretamente com o truncamento da cópia.

Portanto, somente porque usar a abordagem reload requer menos desvio da configuração padrão, eu a manteria.