Isso pode realmente acontecer - há uma série de situações em que esse tipo de bloqueio pode acontecer, e todas elas basicamente se resumem à fila do syslog ou ao buffer estar cheio, de forma que as gravações são atrasadas.
Isso (geralmente) tende a agravar o problema, porque as coisas começam a falhar e querem sinalizar o máximo, mas precisam esperar que o syslog aceite suas mensagens.
Observe que também há bugs que podem causar comportamento inadequado em tais situações - especialmente, o rsyslog causou esse problema no RH ( link ).
Então, eu recomendaria definitivamente verificar suas versões do software contra bugs conhecidos.
Além disso, verifique as configurações de DNS do seu syslog - para os clientes que enviam o syslog, não há motivo para pensar em usar o DNS. Para o servidor de recebimento, se você pode fazer sem pesquisas de DNS, pode valer a pena tentar ver se isso ajuda na taxa de transferência.
Felizmente, há também várias correções (não especificamente para o syslog-ng), mas você precisará fazer algum tipo de compromisso, é a versão curta.
-
Se você puder tolerar a perda de alguns dados, alternar seu log para o UDP é uma opção. Obviamente, dado o tipo de problema que você está descrevendo, parece quase certo que, se você fizer isso, você irá perder alguns dados.
-
Outra opção é ser mais seletivo sobre o que você envia pela rede, ou seja, filtrar e / ou priorizar alguns fluxos em detrimento de outros. O quanto isso ajuda depende em parte de quais opções estão disponíveis na implementação escolhida do seu syslog - o rsyslog tem muitas opções, outras com as quais eu não estou tão familiarizado.
-
Nem sempre é necessário fazer login diretamente na rede. Você pode pensar em não fazê-lo e, em vez disso, usar algum tipo de agente de acompanhamento / análise de log (algo como link ) - isso pode evitar tocar em uma configuração de syslog em funcionamento, embora ainda possua log remoto (você também pode fazer com que o agente escute no host local e encaminhar dados do syslog localmente, se você não armazenar dados no arquivo no momento).
-
Em uma nota semelhante, eu recomendo que você verifique sua política de auditoria e veja se há algo que possa estar causando um problema. Notavelmente, se auditd estiver registrando no syslog, o fluxo pode ser bastante substancial, mesmo (ou especialmente) ao usar configurações de 'melhores práticas' (por exemplo, benchmarks do CIS). Eu vi isso causar problemas em várias áreas e, em alguns casos, quando o audispd não pode mais enviar mensagens para o syslog, ele pode bloquear.
-
Por fim, para coisas como o rsyslog, você também tem opções que usam filas de disco e memória para aliviar esses tipos de problemas. É preciso um pouco de configuração (para o rsyslog, consulte link ), mas permite a construção uma configuração muito mais tolerante a falhas, se você não se importa em lançar alguns recursos para o problema.
O Rsyslog fornece um guia para configurações de alto desempenho ( link ) e o syslog de failover servidores ( link ).
Eu definitivamente recomendo que você pelo menos investigue o servidor de log central para ter certeza de que é capaz de lidar com o volume de logging - e ajustá-lo de outra maneira (tive boas experiências fazendo isso com rsyslog, onde um receptor razoavelmente 'padrão' config foi incapaz de acompanhar, mas o ajuste nos permitiu suportar várias ordens de magnitude mais tráfego).
Além disso, considere revisar sua configuração de log mais geralmente - eu sei de (triste) experiência que pode haver uma tendência de pessoas habilitar o log TRACE ou DEBUG e deixá-lo ligado, o que geralmente não faz syslog (ou o sistema mais geralmente) muitos favores.