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

10

Em um site de alto tráfego em execução em contêineres virtuais (VMware) e com falta de armazenamento local, conseguimos aumentar significativamente a taxa de transferência (solicitações por segundo), passando de fazer logon diretamente em arquivos de log (que residem no armazenamento de rede remoto) para rsyslogd .

Basicamente, passamos do log síncrono para o assíncrono. Os funcionários do servidor da Web gravam usando syslog (3) em algum buffer de memória e o rsyslogd (8) envia os dados para um arquivo real em paralelo e em seu próprio ritmo, para que os processos não bloqueiem o IO durante o logon.

Por enquanto, 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 é preenchido rapidamente.

Minhas perguntas são:

Um cliente pode bloquear ao gravar no rsyslogd usando o syslog (3) ?
Existe uma maneira de analisar as estatísticas do rsyslogd , por exemplo, qual é o tamanho do buffer?
Existe uma maneira de aumentar o tamanho do buffer de entrada rsyslogd ?

vmware logging rsyslog

— arielf
fonte

2

Alguma vez resolveste isto? Nesse caso, eu estaria interessado em ler sua resposta.

— djeikyb

1

@djeikyb: desculpe não. Vejo interesse (votos na pergunta), mas ninguém respondeu ainda. Parece que isso requer um mergulho no código-fonte.

— Arielf

1

Você não diz qual servidor web está usando. Talvez você não deva usar o syslog. O Apache, por exemplo, usa o syslog para registrar ou apenas grava nos arquivos de registro? Fazer login em um banco de dados é outra possibilidade.

— Bloqueios19 de

1

Tanto quanto me lembro, o modo padrão para a fila principal de mensagens no rsyslog é uma matriz de tamanho fixo. Ele tem um limite para 10 mil elementos ou mais. Tente mudar isso para a fila da lista vinculada, pois ele deve lidar com suas explosões ocasionais de mensagens muito melhor.

Sim, existem FixedArraye LinkedListfilas.

— hostmaster
fonte

"Tente mudar" ... Você pode ser mais explícito? Observando /etc/rsyslog.conf: Não vejo nada relacionado aos tipos de filas que você menciona. Isso requer uma alteração de código? Onde e como eles podem ser configurados? Obrigado!

— Arielf # 20/16

1

A resposta para sua primeira pergunta é:

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

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

Em geral, se você mover o log para um servidor externo por meio do "protocolo de syslog de rede" UDP: 514, trará a possibilidade de criar bloqueios quase zero. Com a desvantagem de possível perda de alguns registros durante altas cargas.

Primeiro , nos servidores "de origem", você precisa garantir que todo o log ocorra via syslog. Por exemplo, no Apache2, você precisa especificar:

ErrorLog "syslog:daemon"

Para outros servidores, consulte a página de manual apropriada. Se você não conseguir garantir isso, lembre-se de que o logon em sistemas de arquivos pode criar

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

daemon.* @192.168.128.1
daemon.* @192.168.254.1

ter duas cópias dos logs a serem enviadas para dois servidores diferentes ao mesmo tempo.

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

$ModLoad imudp
$UDPServerRun 514

Quarto , opcional, mas altamente recomendado, eu também habilitaria carimbos de data / hora de alta resolução:

$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

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

— EnzoR
fonte