Transformando um arquivo de log em uma espécie de buffer circular

16

Pessoal, existe uma solução * nix que faria o arquivo de log agir como um buffer circular? Por exemplo, eu gostaria que os arquivos de log armazenassem no máximo 1Gb de dados e descartassem as entradas mais antigas assim que o limite fosse atingido.

É possível? Acredito que, para conseguir isso, um arquivo de log deve ser transformado em algum tipo de dispositivo especial ...

P.S. Estou ciente de várias ferramentas de logrotating, mas isso não é o que eu preciso. Logrotating requer muitos IO, acontece normalmente uma vez por dia enquanto eu preciso de uma solução de "tempo de execução".

    
por pachanga 17.04.2010 / 09:24

6 respostas

12

O Linux tem um buffer de anel do kernel. Você pode usar dmesg para exiba isto .

Ou aqui é um módulo do kernel do Linux que parece fazer o que você quer.

What is emlog?

emlog is a Linux kernel module that makes it easy to access the most recent (and only the most recent) output from a process. It works just like "tail -f" on a log file, except that the storage required never grows. This can be useful in embedded systems where there isn't enough memory or disk space for keeping complete log files, but the most recent debugging messages are sometimes needed (e.g., after an error is observed).

The emlog kernel module implements simple character device driver. The driver acts like a named pipe that has a finite, circular buffer. The size of the buffer is easily configurable. As more data is written into the buffer, the oldest data is discarded. A process that reads from an emlog device will first read the existing buffer, then see new text as it's written, similar to monitoring a log file using "tail -f". (Non-blocking reads are also supported, if a process needs to get the current contents of the log without blocking to wait for new data.)

    
por 17.04.2010 / 12:49
4

A coisa mais próxima que eu posso pensar é RRDTools, mas provavelmente não é o que você está procurando. Outra solução seria monitorar o arquivo de log (digamos, a cada segundo ou no Linux com inotify), por exemplo, você escreve um script como:

while :; do
  if [[ $(stat -c %s $FILE) -gt 10000 ]]; then
    # rotate the log
  fi
  sleep 1
done

com inotify:

while :; do
  if inotifywait [some options] $FILE; then
    # check size and rotate the file
  fi
done
    
por 17.04.2010 / 09:46
4

Você pode usar o multilog dos daemontools do djb. Você canaliza sua saída de log para . Sim, é a rotação de log, mas as rotações são simples:

ln current $tai64nlocaltimestamp

Que, em praticamente qualquer sistema de arquivos Linux moderno, é uma operação super rápida. Você pode especificar quantos arquivos de log você deseja, o tamanho que deseja. faça 10 x 1024mb, e você terá seu buffer de 1gb.

Note que, devido à rotação automática, é uma fonte por instância multilog. Mas você pode contornar isso escrevendo um simples wrapper com o netcat ou manualmente.

    
por 17.04.2010 / 13:38
1

Você pode criar um pipe FIFO e depois lê-lo usando um script que se insere em um banco de dados. Quando o contador atingir 1.000, reinicie o número de ID que está sendo inserido no banco de dados. Não funcionaria para o tamanho, é claro, mas você usou isso como exemplo, então estou assumindo que essa é uma questão teórica.

    
por 17.04.2010 / 09:31
1

Pergunta interessante; você não costuma ver isso como um design. Eu tenho um programa que usa uma técnica levemente semelhante para gravar o histórico, mas ele usa um formato binário. O 'arquivo de log' tem quatro partes, todas dispostas em um formato neutro de máquina:

  1. Um cabeçalho contendo o número mágico e o número (máximo) de entradas na lista utilizada e na lista livre, o número de sequência da próxima entrada do histórico, o número real de entradas na lista usada, o número real de entradas na a lista livre e o tamanho do arquivo (cada um com 4 bytes).
  2. A lista usada, cada entrada dando um deslocamento e um comprimento (4 bytes para cada parte de cada entrada).
  3. A lista livre, cada entrada semelhante à entrada da lista usada.
  4. Os dados principais, cada registro de histórico que consiste em um conjunto contíguo de bytes terminados por um byte de terminador nulo.

Quando um novo registro é alocado, se houver espaço na lista livre, ele sobrescreve uma entrada lá (não necessariamente usando tudo - nesse caso, o fragmento permanece na lista livre). Quando não há espaço na lista livre, o novo espaço é alocado no final. Quando um registro antigo é rotacionado, seu espaço é movido para a lista livre e unido a qualquer registro livre adjacente. Ele é projetado para manipular instruções SQL para que os registros possam ser distribuídos por várias linhas. Esse código funciona em um número especificado de registros. Ele não limita o tamanho do arquivo em si (embora não seja difícil fazê-lo).

O código principal do histórico de código está em dois arquivos, history.c e history.h, disponíveis na fonte do programa SQLCMD (minha versão, não da Microsoft; a minha já existia uma década ou mais antes da da Microsoft), que pode pode ser baixado do Software Archive do International Informix User Group. Há também um programa de despejo de arquivo de histórico (histdump.c) e um testador de histórico (histtest.ec - ele afirma ser ESQL / C, mas é realmente um código C; uma das funções de suporte que ele chama usa algum Informix ESQL / C funções da biblioteca). Entre em contato se quiser experimentar sem usar o Informix ESQL / C - consulte meu perfil. Existem algumas mudanças triviais para compilar o histtest fora de seu ambiente de design, além de você precisar de um makefile.

    
por 17.04.2010 / 11:06
0

Concordo com o comentário de pehrs à sua pergunta. Rotação de log não é tão difícil. Você pode configurar o logrotate ou outro script para verificar periodicamente o seu arquivo de log, mesmo que a cada minuto, se assim o desejar. Quando detecta que seu arquivo atinge 1 GB de tamanho, ele simplesmente executa uma renomeação, que não leva a nenhuma E / S. Durante a renomeação, o processo continua gravando o arquivo de log. O roteador de log pode enviar um HUP para o seu daemon syslog (o daemon é logar através do syslog, certo? Se não, ele deve suportar o sinal HUP se estiver bem escrito ...) para tê-lo reabra o caminho do arquivo original. Neste ponto, ele começará a gravar em um novo arquivo no caminho original e você poderá excluir a versão girada.

    
por 17.04.2010 / 18:58

Tags