Transformer un fichier journal en une sorte de tampon circulaire

Mes amis, existe-t-il une solution * nix qui ferait en sorte que le fichier journal agisse comme un tampon circulaire? Par exemple, j'aimerais que les fichiers journaux stockent au maximum 1 Go de données et éliminent les anciennes entrées une fois la limite atteinte.

Est-ce possible du tout? Je crois que pour y parvenir, un fichier journal doit être transformé en une sorte d'appareil spécial ...

PS Je connais des outils de logrotating divers mais ce n'est pas ce dont j'ai besoin. Logrotating nécessite beaucoup d'E / S, se produit généralement une fois par jour alors que j'ai besoin d'une solution "runtime".

Linux a un tampon d'anneau de noyau. Vous pouvez utiliser dmesgpour l' afficher .

Ou voici un module du noyau Linux qui semble faire ce que vous voulez.

Qu'est-ce que l'emlog?

emlog est un module du noyau Linux qui facilite l'accès à la sortie la plus récente (et seulement la plus récente) d'un processus. Il fonctionne exactement comme "tail -f" sur un fichier journal, sauf que le stockage requis ne croît jamais. Cela peut être utile dans les systèmes embarqués où il n'y a pas assez de mémoire ou d'espace disque pour conserver des fichiers journaux complets, mais les messages de débogage les plus récents sont parfois nécessaires (par exemple, après qu'une erreur est observée).

Le module du noyau emlog implémente un pilote de périphérique de caractères simple. Le pilote agit comme un tube nommé doté d'un tampon circulaire fini. La taille du tampon est facilement configurable. À mesure que davantage de données sont écrites dans le tampon, les données les plus anciennes sont supprimées. Un processus qui lit à partir d'un périphérique emlog lira d'abord le tampon existant, puis verra le nouveau texte tel qu'il est écrit, similaire à la surveillance d'un fichier journal en utilisant "tail -f". (Les lectures non bloquantes sont également prises en charge, si un processus doit obtenir le contenu actuel du journal sans bloquer pour attendre de nouvelles données.)

La chose la plus proche à laquelle je peux penser est RRDTools, mais ce n'est probablement pas ce que vous recherchez. Une autre solution serait de surveiller le fichier journal (disons toutes les secondes ou sous Linux avec inotify), par exemple vous écrivez un script comme:

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

avec inotify:

while :; do
  if inotifywait [some options] $FILE; then
    # check size and rotate the file
  fi
done

Vous pouvez utiliser le multilog depuis les Daemontools de djb. Vous redirigez votre sortie du journal en lui. Oui, c'est la rotation du journal, mais les rotations sont simplement:

ln current $tai64nlocaltimestamp

Ce qui, sur à peu près n'importe quel système de fichiers Linux moderne, est une opération ultra rapide. Vous pouvez spécifier le nombre de fichiers journaux que vous souhaitez, la taille souhaitée. créez 10 fichiers de 1024 Mo, et vous aurez votre tampon en anneau de 1 Go.

Notez qu'en raison de la rotation automatique, c'est une source par instance de journal multiple. Mais vous pouvez contourner cela en écrivant un simple wrapper avec netcat ou à la main.

Vous pouvez créer un tube FIFO, puis le lire à l'aide d'un script inséré dans une base de données. Lorsque le compteur atteint 1 000, redémarrez le numéro d'identification inséré dans la base de données. Cela ne fonctionnerait pas pour la taille, bien sûr, mais vous l'avez utilisé comme exemple, donc je suppose que c'est une question théorique.

Question interessante; vous ne voyez généralement pas cela comme une conception. J'ai un programme qui utilise une technique légèrement similaire pour enregistrer l'historique, mais il utilise un format binaire. Le «fichier journal» comprend quatre parties, toutes présentées dans un format neutre pour la machine:

1. Un en-tête contenant le nombre magique et le nombre (maximum) d'entrées dans la liste utilisée et la liste libre, le numéro de séquence pour la prochaine entrée d'historique, le nombre réel d'entrées dans la liste utilisée, le nombre réel d'entrées dans la liste libre et la longueur du fichier (chacun de 4 octets).
2. La liste utilisée, chaque entrée donnant un décalage et une longueur (4 octets pour chaque partie de chaque entrée).
3. La liste libre, chaque entrée similaire à l'entrée de liste utilisée.
4. Les données principales, chaque enregistrement d'historique consistant en un ensemble contigu d'octets terminé par un octet de terminaison nul.

Lorsqu'un nouvel enregistrement est alloué, s'il y a de l'espace dans la liste libre, il écrase une entrée là-bas (pas nécessairement en l'utilisant tout - auquel cas le fragment reste sur la liste libre). Lorsqu'il n'y a pas d'espace dans la liste libre, un nouvel espace est alloué à la fin. Lorsqu'un ancien enregistrement pivote, son espace est déplacé vers la liste libre et fusionné avec tous les enregistrements libres adjacents. Il est conçu pour gérer les instructions SQL afin que les enregistrements puissent être répartis sur plusieurs lignes. Ce code fonctionne sur un nombre spécifié d'enregistrements. Cela ne limite pas la taille du fichier en soi (bien qu'il ne soit pas difficile de le faire).

Le code d'historique du code principal se trouve dans deux fichiers, history.c et history.h, disponibles à la source pour le programme SQLCMD (ma version, pas celle de Microsoft; la mienne existait une décennie ou plus avant celle de Microsoft), qui peut être téléchargée à partir de les archives logicielles du groupe d'utilisateurs d'Informix International . Il existe également un programme de vidage de fichiers d'historique (histdump.c) et un testeur d'historique (histtest.ec - il prétend être ESQL / C, mais il s'agit en fait de code C; l'une des fonctions de support qu'il appelle utilise un peu Informix ESQL / C fonctions de bibliothèque). Contactez-moi si vous voulez expérimenter sans utiliser Informix ESQL / C - voir mon profil. Il y a quelques changements triviaux à faire pour qu'il compile les tests en dehors de son milieu de conception, et vous avez besoin d'un makefile.

Je suis d'accord avec le commentaire de pehrs sur votre question. La rotation des journaux n'est pas si difficile. Vous pouvez configurer logrotate ou un autre script pour vérifier périodiquement votre fichier journal, même aussi souvent que chaque minute si vous le souhaitez. Lorsqu'il détecte que votre fichier atteint 1 Go, il effectue simplement un changement de nom, qui ne prend pratiquement pas d'E / S. Pendant le changement de nom, le processus continue d'écrire le fichier journal. Le rotateur de journaux peut ensuite envoyer un HUP à votre démon syslog (votre démon se connecte via syslog, non? Sinon, il devrait prendre en charge le signal HUP s'il est bien écrit ...) pour qu'il rouvre le chemin du fichier d'origine . À ce stade, il commencera à écrire dans un nouveau fichier sur le chemin d'origine et vous pouvez supprimer la version pivotée.