Réponses:
D'après mon expérience, logrotate est génial. Il est très flexible et fonctionne bien avec la plupart des logiciels.
Cependant, il y a quelques problèmes, et comme cronolog est principalement une fonction de rotation des journaux Web, je vais écrire mon expérience avec logrotate + apache qui était problématique:
Lors de la rotation des journaux, nous devons informer apache qu'un journal est en cours de rotation, car même si logrotate renomme access.log en access.log.1, apache continuera d'écrire dans access.log.1, comme il écrit dans l'inode, et renommer le fichier n'affecte pas le numéro d'inode.
Sur debian etch (et probablement de nombreuses autres distributions), logrotate est utilisé pour faire tourner les journaux apache. Maintenant, apache a un redémarrage gracieux qui conseille aux processus enfants apache de quitter une fois qu'ils ont fini de servir les connexions existantes, apache relit ensuite sa configuration, génère de nouveaux processus enfants, qui commencent à écrire dans un nouveau fichier journal (dans le cas où le précédent était tourné).
Cela semble être une excellente solution, cependant un redémarrage gracieux ne fonctionne pas toujours dans certaines conditions (comme une charge lourde), donc les développeurs Debian ont décidé d'utiliser un redémarrage apache au lieu d'un redémarrage gracieux, dans la configuration logrotate d'apache. Malheureusement, toutes les connexions sont interrompues en même temps, ce qui est très mauvais pour les sites lourdement chargés. En outre, le redémarrage d'Apache peut également provoquer des problèmes comme l'arrêt et le démarrage d'Apache (également dans certaines situations de chargement), voir les liens de bogue ci-dessous pour plus de détails.
En bout de ligne, logrotate est génial, mais peut entraîner certains problèmes pour certains programmes. Je n'ai pas beaucoup d'expérience avec cronolog, mais comme il écrit des journaux via un canal, il ne nécessite aucun rechargement apache lorsqu'il fait tourner des fichiers journaux, ce qui résout essentiellement tout ce qui est décrit ci-dessus.
Bogues liés à Debian dans Logrotate / Apache:
Je préfère cronolog, mais ce n'est pas une préférence vraiment forte.
logrotate où est démarré par cron, et si un système est arrêté pour une raison quelconque lorsque la rotation aurait dû se produire, vos fichiers journaux ne seront pas pivotés.
J'aime aussi que les fichiers journaux aient la date (% Y% m.combined.access.log) dans le nom parce que je garde ces journaux pendant longtemps. Sur la plupart des systèmes, par défaut, apache logrotate nommera les fichiers access.log, access.log.1, etc. Il peut être possible d'utiliser une date dans les fichiers journaux avec logrotate, mais je n'ai pas compris comment faire la dernière fois que j'ai regardé.
Seulement utilisé logrotate. C'est ce que Debian utilise par défaut et je n'ai jamais eu de plaintes avec.
J'utilise presque exclusivement cronolog
over logrotate
.
logrotate
vient avec Debian, et je lui permets de continuer à travailler pour les services système comme les journaux du serveur de messagerie. Mais pour Apache et lighttpd
les fichiers journaux, c'est tout cronolog
.
L'une des raisons pour lesquelles j'utilise cronolog
est que toute la configuration se produit dans la ligne du fichier journal de la configuration du serveur Web
par exemple dans un lighttpd
fichier de configuration, vous pouvez mettre:
accesslog.filename = "|/usr/bin/cronolog --symlink=/var/log/webs/access.log /var/log/webs/%Y/%W-access.log"
Et tous obtiennent un nouveau fichier journal chaque semaine sans aucune autre configuration. Ou vous pouvez devenir créatif et faire quelque chose comme:
accesslog.filename = "|/usr/bin/cronolog --symlink=/var/log/webs/access.log /var/log/webs/%Y/%m/%a-access.log"
Et obtenez un fichier journal qui affiche le trafic par jour de la semaine. par exemple tous les dimanches, tous les mardis.
Ce qui est mieux, c'est que même si le serveur est arrêté pendant un certain temps, le fichier journal correct sera utilisé au redémarrage.