Відповіді:
На мій досвід, логротат - це чудово. Це дуже гнучко і добре працює з більшістю програмного забезпечення.
Однак з цим є деякі проблеми, і оскільки кронолог - це передусім обертання веб-журналу, я запишу свій досвід роботи з logrotate + apache, що було проблематично:
Під час обертання журналів ми повинні повідомляти apache про те, що журнал обертається, як навіть якщо logrotate перейменовує access.log на access.log.1, apache продовжить записувати на access.log.1, як це записується в inode, і перейменування файлу не впливає на номер вводу.
У програмі debian etch (і, мабуть, у багатьох інших дистрибутивах) логротат використовується для обертання журналів apache. Тепер у апачі є витончений перезапуск, який радить дочірнім процесам apache вийти, як тільки вони закінчують обслуговувати наявні з'єднання, apache потім перечитує його конфігурацію, породжує нові дочірні процеси, які починають записувати у новий файл журналу (у випадку, якщо попередній був обертається).
Це звучить як чудове рішення, однак витончений перезапуск не завжди працює в певних умовах (наприклад, велике навантаження), тому розробники debian вирішили використовувати перезапуск apache замість витонченого перезапуску в конфігурації apache logrotate. На жаль, це призводить до того, що всі з'єднання одразу перестають, що дуже погано для сильно завантажених сайтів. Крім того, перезапуск апачі також може спричинити проблеми, такі як зупинка апачу та не запуск (також у певних ситуаціях із завантаженням), див. Посилання помилок нижче.
Суть полягає в тому, що логротат великий, але може призвести до певних проблем для певних програм. Я не маю великого досвіду роботи з кронолом, але, оскільки він пише журнали через трубу, він не потребує перезавантажень apache під час обертання файлів журналів, що в основному вирішує все, що описано вище.
Пов'язані помилки logrotate / apache debian:
Я віддаю перевагу кронології, але це не дуже сильна перевага.
logrotate, де починається cron, і якщо система з якихось причин не працює, коли поворот мав статися, ваші файли журналів не повертатимуться.
Мені також подобається, що у файлах журналів у назві є дата (% Y% m.combined.access.log), оскільки я зберігаю ці журнали довгий час. У більшості систем, за замовчуванням, apache logrotate буде називати файли access.log, access.log.1 тощо. Можливо, можна використовувати дату в журналах з логротатом, але я не міг зрозуміти, як це робити останній раз, коли я дивився.
Тільки коли-небудь використовується логротат. Це те, що Debian використовує за замовчуванням, і я ніколи не мав жодних скарг з цим.
Я майже виключно використовувати cronologбільш logrotate.
logrotateпоставляється з Debian, і я дозволяю йому продовжувати працювати для системних служб, таких як журнали поштового сервера. Але для lighttpdфайлів Apache та журналів - це все cronolog.
Однією з причин, чому я користуюся, cronologє те, що вся конфігурація відбувається в рядку журналу файлу конфігурації веб-сервера
наприклад, у lighttpdконфігураційний файл, ви можете поставити:
accesslog.filename = "|/usr/bin/cronolog --symlink=/var/log/webs/access.log /var/log/webs/%Y/%W-access.log"
Усі отримують новий журнальний файл щотижня без будь-якої іншої конфігурації. Або ви можете проявити творчість і зробити щось на кшталт:
accesslog.filename = "|/usr/bin/cronolog --symlink=/var/log/webs/access.log /var/log/webs/%Y/%m/%a-access.log"
І отримайте файл журналу, який відображає трафік по днях тижня. наприклад, всі неділі, всі вівторки.
Що краще, що навіть якщо сервер не працює протягом будь-якого часу, при перезапуску буде використаний правильний файл журналу.