web-dev-qa-db-fra.com

Logrotate pour nettoyer les fichiers horodatés

J'essaie actuellement de trouver une méthode pour ranger les fichiers journaux Oracle Recover qui sont créés par Cron ...

Actuellement, notre processus de récupération de secours Oracle est appelé par Cron toutes les 15 minutes à l'aide de la commande suivante:

0,15,30,45 * * * * /data/tier2/scripts/recover_standby.sh SID >> /data/tier2/scripts/logs/recover_standby_SID_`date +\%d\%m\%y`.log 2>&1

Cela crée des fichiers qui ressemblent à:

$ ls -l /data/tier2/scripts/logs/
total 0
-rw-r--r-- 1 Oracle oinstall 0 Feb  1 23:45 recover_standby_SID_010213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  2 23:45 recover_standby_SID_020213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  3 23:45 recover_standby_SID_030213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  4 23:45 recover_standby_SID_040213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  5 23:45 recover_standby_SID_050213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  6 23:45 recover_standby_SID_060213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  7 23:45 recover_standby_SID_070213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  8 23:45 recover_standby_SID_080213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb  9 23:45 recover_standby_SID_090213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb 10 23:45 recover_standby_SID_100213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb 11 23:45 recover_standby_SID_110213.log
-rw-r--r-- 1 Oracle oinstall 0 Feb 12 23:45 recover_standby_SID_120213.log

Je veux essentiellement supprimer les fichiers de plus de x jours, ce que je pensais que logrotate serait parfait pour ...

J'ai configuré logrotate avec le fichier de configuration suivant:

/data/tier2/scripts/logs/recover_standby_*.log {
    daily
    dateext
    dateformat %d%m%Y
    maxage 7
    missingok
}

Y a-t-il quelque chose qui me manque pour obtenir le résultat souhaité?

Je suppose que je pourrais supprimer la date du fichier journal Crontab, puis demander à logrotate de faire tourner ce fichier, mais la date dans le fichier journal ne reflétera pas le jour où les journaux ont été générés ... c'est-à-dire que les récupérations sur 010313 seraient dans un fichier avec un date de 020313 en raison de la mise à feu logrotate sur 020313 et de la rotation du fichier ...

D'autres idées? Et merci d'avance pour toutes les réponses.

Cordialement

Gavin

linuxoraclelogrotate
24
fatmcgav

Logrotate supprime les fichiers selon l'ordre dans la liste triée lexiquement des noms de fichiers journaux pivotés, ainsi que par âge du fichier (en utilisant l'heure de la dernière modification du fichier)

  • rotation est le nombre maximal de fichiers tournés, vous pouvez trouver. S'il y a un plus grand nombre de fichiers journaux pivotés, leurs noms sont triés lexicalement et les plus petits lexicalement sont supprimés.

  • maxage définit un autre critère de suppression des fichiers journaux pivotés. Tout fichier journal pivoté, étant plus ancien que le nombre de jours donné, est supprimé. Notez que la date est détectée à partir de l'heure de dernière modification du fichier et non à partir du nom du fichier.

  • dateformat permet un formatage spécifique pour la date dans les fichiers tournés. La page de manuel note que le le format doit entraîner un tri lexicalement correct.

  • dateyesterday permet d'utiliser les dates dans les noms des fichiers journaux un jour en arrière.

Pour conserver un nombre de jours donné dans les fichiers ayant subi une rotation quotidienne (par exemple, 7), vous devez définir rotate sur une valeur de 7 et vous pouvez ignorer maxage, si vos fichiers sont créés et pivotés réellement tous les jours.

Si la création du journal ne se produit pas pendant quelques jours, par exemple. pendant 14 jours, le nombre de fichiers journaux pivotés sera toujours le même (7).

maxage améliorera la situation dans les scénarios "journaux non produits" en supprimant toujours les fichiers trop anciens. Après 7 jours sans production de journaux, aucun fichier journal tourné ne sera présent.

Vous ne pouvez pas utiliser dateformat comme le montre OP, car il n'est pas triable lexicalement. Jouer avec dateformat entraînerait probablement la suppression d'autres fichiers journaux pivotés que vous ne vouliez vraiment.

Astuce: Exécutez logrotate à partir de la ligne de commande avec -d option pour effectuer un essai à sec: vous verrez ce que ferait logrotate mais ne fait rien. Effectuez ensuite une exécution manuelle à l'aide de -v (verbeux) afin que vous puissiez confirmer que ce qui est fait est ce que vous voulez.

Solution: nettoyer les journaux créés par cron

Le concept est:

Laissez cron créer et mettre à jour les fichiers journaux, mais apportez de petites modifications pour créer des fichiers, en suivant les noms de fichiers standard logrotate lorsque vous utilisez par défaut dateext

/data/tier2/scripts/logs/recover_standby_SID.log-`date +\%Y\%m\%d`.log

Utilisez logrotate uniquement pour supprimer les fichiers journaux trop anciens

  • viser le fichier journal non existant /data/tier2/scripts/logs/recover_standby_SID.log
  • utilisez missingok pour permettre le nettoyage de logrotate
  • définissez rotate suffisamment haut pour couvrir le nombre de fichiers journaux à conserver (au moins 7, s'il y aura un fichier journal "tourné" par jour, mais vous pouvez le définir en toute sécurité comme 9999)
  • définissez maxage sur 7. Cela supprimera les fichiers dont l'heure de dernière modification est supérieure à 7 jours.
  • dateext est utilisé uniquement pour garantir que logrotate recherche des fichiers plus anciens ressemblant à une rotation.

Le fichier de configuration de Logrotate ressemblerait à:

data/tier2/scripts/logs/recover_standby_SID.log {
    daily
    missingok
    rotate 9999
    maxage 7
    dateext
}

Solution: rotation directe par logrotate une fois par jour

Je ne sais pas comment le fichier de secours de récupération de source est créé, mais je suppose que Oracle ou un de vos scripts est régulièrement ou continuellement ajouté à un fichier /data/tier2/scripts/logs/recover_standby_SID.log

Le concept est:

  • faire pivoter le fichier une fois par jour de logrotate
  • travailler directement avec un fichier journal contenant des données de récupération /data/tier2/scripts/logs/recover_standby_SID.log
  • daily provoquera une rotation une fois par jour (en termes de compréhension de crondaily)
  • rotate doit être défini sur 7 (ou tout nombre supérieur).
  • maxage défini sur 7 (jours)
  • dateext pour utiliser le suffixe de date de rotation par défaut
  • dateyesterday utilisé pour provoquer des suffixes de date dans les fichiers tournés depuis un jour.
  • missingok pour nettoyer les fichiers plus anciens même en l'absence de nouveau contenu à faire pivoter.

La configuration de Logrotate ressemblerait à:

data/tier2/scripts/logs/recover_standby_SID.log {
    daily
    missingok
    rotate 7
    maxage 7
    dateext
    dateyesterday
}

Notez que vous devrez peut-être jouer un peu avec copytruncate et d'autres options similaires liées à la façon dont le fichier journal source est créé par un processus externe et comment il réagit à l'acte de rotation.

30
Jan Vlcinsky

Vous pouvez utiliser la commande find pour effectuer cette tâche facilement! Il supprimera tous les 7 Days anciens fichiers. Mettez-le dans crontab et exécutez la nuit:

$ cd /data/tier2/scripts/logs/    
$ /usr/bin/find . -mtime +7 -name "*.log" -print -delete

Ou mieux

$ /usr/bin/find /data/tier2/scripts/logs/ -mtime +7 -name "*.log" -print -delete;
18
Satish

(Mise à jour) Vos options sont:

  • Comme Satish a répondu, abandonnez logrotate et mettez un script de recherche dans cron
  • Vous pouvez même utiliser logrotate et mettre un script find dans la commande postrotate

Au départ, je pensais que changer le format de date pour correspondre à vos journaux pourrait fonctionner mais comme Reid Nabinger l'a souligné, le format de date n'était de toute façon pas compatible avec logrotate. Récemment, j'ai essayé de configurer la même chose mais pour Java journaux tournés que je voulais que logrotate supprime. J'ai essayé la configuration ci-dessous mais il a continué d'essayer de supprimer tous les journaux

/opt/jboss/log/server.log.* {
    missingok
    rotate 0
    daily
    maxage 30
}

J'ai fini par implémenter ce que Satish a suggéré - une simple recherche avec le script rm dans cron.

4
Lars Nordin

(Impossible de commenter car la réputation n'est pas suffisante)

J'ai eu un problème similaire. Par tous les comptes, logrotate est inutile pour une utilisation sur les noms de fichiers avec des horodatages intégrés.

Si tout le reste était égal, j'irais probablement avec find dans un travail cron.

Pour mes propres raisons, je voulais utiliser logrotate et j'ai finalement trouvé un moyen: https://stackoverflow.com/a/23108631

C'était essentiellement un moyen d'encapsuler le travail cron dans un fichier logrotate. Peut-être pas la plus jolie ou la plus efficace mais comme je l'ai dit, j'avais mes raisons.

3
northern-bradley

Selon @Jan Vlcinsky, vous pouvez laisser logrotate ajouter la date - utilisez simplement dateyesterday pour obtenir la bonne date.

Ou, si vous souhaitez entrer la date vous-même, vous pouvez viser le nom sans la date, puis les noms avec la date seront nettoyés.

Cependant, ce que j'ai trouvé, c'est que si je n'ai pas de fichier journal là-bas, logrotate ne fait pas le nettoyage des fichiers avec des dates.

Mais si vous êtes prêt à avoir un fichier journal vide, vous pouvez le faire fonctionner.

Par exemple, pour nettoyer /var/log/mylogfile.yyyymmdd.log après 7 jours, touch /var/log/mylogfile.log, puis configurez logrotate comme suit:

/var/log/mylogfile.log. m% d 
 extension .log 
 si vide 
 créer 
}

Cette entrée, combinée à l'existence de mylogfile.log, déclenche logrotate pour nettoyer les anciens fichiers, comme s'ils avaient été créés par logrotate.

daily, rotate plus maxage entraînent la suppression des anciens fichiers journaux après 7 jours (ou 7 anciens fichiers journaux, selon la première éventualité).

dateext, dateformat plus extension fait correspondre logrotate à nos noms de fichiers.

Et ifempty plus create s'assurent qu'il y a toujours un fichier vide, sinon la rotation du journal s'arrêterait.

Une autre astuce pour les tests, préparez-vous à modifier /var/lib/logrotate.status pour réinitialiser la date de la dernière rotation ou logrotate ne fera rien pour vous.

2
Ben Aveling

Pour info, je sais que c'est une vieille question, mais la raison pour laquelle cela ne fonctionne pas pour vous est que votre format de date n'est pas triable lexicalement. Depuis la page de manuel:

   dateformat format_string
          Specify the extension for dateext using the notation similar to strftime(3)  function.  Only
          %Y  %m  %d  and %s specifiers are allowed.  The default value is -%Y%m%d. Note that also the
          character separating log name from the extension is part of the dateformat string. The  sys-
          tem  clock must be set past Sep 9th 2001 for %s to work correctly.  Note that the datestamps
          generated by this format must be lexically sortable (i.e., first the year,  then  the  month
          then  the  day.  e.g.,  2001/12/01 is ok, but 01/12/2001 is not, since 01/11/2002 would sort
          lower while it is later).  This is because when using the rotate option, logrotate sorts all
          rotated filenames to find out which logfiles are older and should be removed.

La solution consiste à passer à celle qui correspond à l'année-mois-date ou à appeler un processus externe pour effectuer le nettoyage.

1
Reid Nabinger