logging assíncrono via rsyslogd (8) e aumento do buffer de gravação

Question

Em um site de alto tráfego rodando em contêineres virtuais (VMware) e sem armazenamento local, conseguimos aumentar significativamente a taxa de transferência (solicitações por segundo) alternando do registro diretamente para os arquivos de log (que residem na rede remota armazenamento) para rsyslogd .

Essencialmente, mudamos de log síncrono para assíncrono. Os servidores web escrevem usando syslog (3) para algum buffer de memória e rsyslogd (8) envia os dados para um arquivo real em paralelo, e em seu próprio ritmo, então processos não bloqueiam o IO ao registrar.

Até aí tudo bem. O problema é que, ocasionalmente, o rsyslogd é impedido de gravar (por exemplo, uma interrupção momentânea / prolongada da rede) e o buffer de entrada é rapidamente preenchido.

Minhas perguntas são:

• Um cliente pode bloquear quando escreve para rsyslogd usando syslog (3) ?
• Existe uma maneira de ver as estatísticas do rsyslogd , por exemplo quão grande / cheio é o buffer?
• Existe uma maneira de aumentar o tamanho do buffer de entrada rsyslogd ?

Answer 1

Tanto quanto me lembro, o modo padrão para a fila de mensagens principal no rsyslog é matriz de tamanho fixo. Tem um limite para elementos de 10k ou mais. Tente mudar isso para a fila de listas vinculadas, ele deve lidar com a sua mensagem ocasional muito melhor.

Sim, existem FixedArray e LinkedList filas.

    

Answer 2

A resposta para sua primeira pergunta é:

  

Sim, qualquer chamada para o syslog () está bloqueando. Talvez por um tempo muito curto   mas ainda é uma chamada síncrona envolvendo um descritor de arquivo. Veja man 3 syslog para mais detials.

A menos que seus servidores usem arquiteturas assíncronas e primitivos, sempre haverá algum bloqueio. Isso pode ser atenuado, mas não eliminado, por exemplo, usando um separatethread para registro. Para as outras duas perguntas eu realmente não sei, mas inspeção para o código-fonte rsyslogd (assim como para a família de funções syslog ()) é a única maneira de saber.

Mais em geral, se você mover o log para um servidor externo através do UDP: 514 "protocolo de syslog de rede", você trará as possibilidades de criar bloqueios para quase zero. Com a desvantagem de possíveis perdas de alguns registros durante altas cargas.

Primeiro , nos servidores de "origem" você precisa garantir que todos os registros sejam feitos via syslog. Por exemplo, no Apache2 você precisa especificar:

ErrorLog "syslog:daemon"

Para outros servidores, consulte a página do manual apropriada. Se você não pode garantir isso, por favor, tenha em mente que o registro em sistemas de arquivos pode criar

Segundo , na configuração rsyslogd de origem solicitada para direcionar todo o tráfego syslog para o recurso escolhido ("daemon" neste exemplo) para um ou mais servidores syslog externos. No arquivo de configuração do rsyslog você pode especificar:

daemon.* @192.168.128.1
daemon.* @192.168.254.1

para que duas cópias dos logs sejam enviadas para dois servidores diferentes ao mesmo tempo.

Terceiro , no (s) servidor (es) de destino, você ativa a recepção da mensagem do syslog por UDP: 514. Está no arquivo de configuração (destino) rsyslogd e é normalmente desabilitado por defualt (seria suficiente remover os #s principais:

$ModLoad imudp
$UDPServerRun 514

Quarto , opcional, mas altamente recomendado, eu também habilitaria os timestamps de alta resolução:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

Além disso, esta opção normalmente é desativada por padrão (por que na Terra?).