Logrotate avançado em um grande número de arquivos quando uma única instância do logrotate não consegue acompanhar

Question

Estou gerenciando um servidor que funciona como um repositório de log remoto para um grande número de arquivos. Atualmente, uma única instância de logrotate não consegue acompanhar esse número de registros. Qual é a melhor maneira de acelerar a rotação de log, possivelmente executando muitas instâncias em paralelo?

Abaixo está o adendo para o esclarecimento:

• O disco I / O não é o problema; Além disso, não estou perdendo registros ou entradas.
• O sistema é uma fera quando comparado a este trabalho (é um Xeon quad core com potência suficiente) o gargalo está na compressão. Um núcleo carrega em w / 1,00 e não pode terminar sua fila de compressão.
• Arquivos de log não são copiados. Apenas um backup diário é levado para outro disco, mas novamente não é um gargalo.
• Eu posso agrupar os arquivos de registro por padrões. Os arquivos não são enormes, só eles são muito. Eu só não sei como paralelizar o logrotate embora eu tenha idéias, mas incapaz de encontrar recursos para isso. Na verdade, o núcleo da questão é _do logrotate gera um processo filho para cada stub no arquivo de configuração ou arquivo de configuração?

Answer 1

Você pode executar várias instâncias do logrotate. Eles precisam trabalhar em diferentes conjuntos de arquivos e usar diferentes arquivos de estado.

Você deve usar gzip (compressão padrão) ao invés de bzip. AFAIK você pode passar algumas opções extras para gzip - assim você pode dizer para usar compressão mais rápida.

    

Answer 2

Informe-nos mais sobre seus requisitos. É difícil adivinhar o que limita seu servidor:

• disco i / o? Você pode querer distribuir esses arquivos de log por discos / sistemas de arquivos
• cpu - está comprimindo esses logs quando eles são girados? Você pode querer usar um sistema de arquivos com compactação interna e até mesmo aceleração de hardware.
• cache do diretório? veja a resposta de Chris Card - espalhe seus arquivos pelos diretórios e, tão importante quanto, torne esses arquivos mais diferentes nos primeiros caracteres do nome do arquivo, ou você não verá os benefícios do cache de diretórios aplicado a eles, o que atrasa as pesquisas significativamente.
• se o seu servidor está atingindo seus limites - é apenas para rotação de log ou já está faltando nas entradas de log?
• Você está copiando esses arquivos de log ou está movendo-os (dentro do mesmo sistema de arquivos)?
• ...

Se você criar uma estrutura para seus arquivos de registro, não haverá nada que impeça a paralelização dos mesmos.

edite em resposta aos requisitos adicionados

Tanto quanto sei, o logrotate não paraleliza em si mesmo. Uma vez que você tenha criado uma estrutura clara, existem algumas estradas que você pode explorar para paralelizá-lo (ou pelo menos as peças que o atrapalham) manualmente:

• O próprio comando compress: você pode usar um script wrapper para fazer a compactação. O gzip gerado pode ser executado em segundo plano enquanto o script retorna imediatamente - deixando assim o trabalho de compactação em execução enquanto o logrotate passa para o próximo arquivo de log. Duas ressalvas:
  1. Prefiro estar seguro e ativar delaycompress para evitar ainda mexer no arquivo de log enquanto o processo está sendo SIGHUP'ed ou o que for necessário para iniciar um novo log (dependendo do processo).
  2. Eu também teria "bom" o trabalho de compactação, para evitar que muitas tarefas de compactação paralelas competissem pelo tempo da CPU.
• Se você estiver se sentindo sofisticado (ou acabar com vários trabalhos gzip paralelos diminuindo o loghost), você poderá fazer a transição para escrever um conjunto de processos de trabalho levando seus arquivos para compactar a partir de uma lista gerada pela "compactação". comando "script declarado em sua configuração do logrotate.
• Você pode ter instâncias independentes de logrotate em execução com um pouco de planejamento:
  • cada instância precisa de seu próprio arquivo de configuração.
  • cada instância precisa de seu próprio conjunto de diretórios para observar arquivos de log. Você pode (e provavelmente deve) ter entradas separadas de crontab para elas.
  • cada instância precisa de seu próprio statefile (configurável)

Answer 3

Uma coisa que pode ajudar é não colocar todos os logs no mesmo diretório - ter muitos arquivos no mesmo diretório pode degradar muito o desempenho.