rsyslog з logrotate: перезавантажити rsyslog vs copytruncate

Я працюю над Ubuntu 14 з утилітою rsyslog та logrotate.

У /etc/logrotate.d/rsyslogконфігурації rsyslog logrotate за замовчуванням я бачу таке:

/var/log/syslog
{
        rotate 7
        daily
        missingok
        notifempty
        delaycompress
        compress
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

З того, що я розумію, рекомендується використовувати copytruncate у всіх сценаріях логратування, оскільки він не переміщує поточний журнал, а швидше обрізає журнал, тому будь-який процес із відкритим обробником файлів зможе продовжувати писати до нього.

То як же прийти конфігурація за замовчуванням, використовуючи замість неї функцію перезавантаження rsyslog?

Щоб відповісти на ваше запитання, спочатку потрібно зрозуміти різні компроміси перезавантаження та копіювання даних:

• reload : старий файл журналу перейменовується, і процес запису в цей журнал повідомляється (за допомогою сигналу Unix), щоб відновити його файл журналу. Це найшвидший / нижчий накладний метод: операції з перейменуванням / переміщенням дуже швидкі та мають постійний час виконання. Більше того, це майже атомна операція: це означає, що (майже) жоден запис журналу не буде втрачено під час переміщення / перезавантаження. З іншого боку, вам потрібен процес, здатний перезавантажити та повторно відкрити його файл журналу. Rsyslog - це такий процес, тому конфігурація logrotate за замовчуванням використовує метод перезавантаження. Використання цього режиму з rsyslog настійно рекомендується rsyslog вище.
• copytruncate : старий файл журналу копіюється в архівний файл, а потім він усікається для "видалення" старих рядків журналу. Хоча операція обрізання дуже швидка, копія може бути досить довгою (залежно від того, наскільки великий ваш файл реєстрації). Більше того, деякі записи в журнал можуть бути втрачені протягом часу між операцією копіювання (пам’ятайте, це може бути повільно) та усіканням. З цих причин copytruncate за замовчуванням не використовується для служб, здатних перезавантажувати та відтворювати свої файли журналів. З іншого боку, якщо сервер не здатний перезавантажувати / відтворювати файли журналів, copytruncate - це ваша найбезпечніша ставка. Іншими словами, вона не потребує підтримки на рівні обслуговування. Проект rsyslog вище за течією настійно не рекомендує використовувати цей режим.

Виступаючи автором rsyslog, copytruncate - це насправді дуже, дуже, дуже поганий вибір. Це за своєю суттю швидкість і його використання - це майже гарантія того, що ви втратите дані журналу. Чим частіше файл записується, тим більше ви втратите. І це не просто частина останнього рядка, але може бути декілька сотень, залежно від точних строків та стану системи в момент, коли відбувається обертання.

Коли файл переміщується та створюється новий inode (файл), rsyslog відстежує попередній файл та завершує його обробку. Тож ви не маєте жодної втрати в цьому випадку. Гарантоване (за винятком випадків, коли ви відключите файлову систему ...).

Щодо "reopenOnTruncate": я особисто бачив, що reopenOnTruncate є раціональним і в інших аспектах, особливо з NFS тощо. Деякий час тому я повністю усунув цю функціональність, але пізніше переконав у об'єднанні подібної функціональності назад. Це залишиться "експериментальним", ймовірно, назавжди, оскільки я дійсно знаю, що люди стикаються з проблемами в дуже сильно завантажених системах. "copytruncate" - просто не гідний режим роботи з файлами журналів.

Зараз я працюю над рефакторингом імфіляту (ETA 8.34 або 8.35). Реконструйована версія, ймовірно, зможе запобігти випадковому повторному надсиланню через гонку API, але також не може захистити від втрати даних - оскільки це концептуально неможливо.

Це повністю залежить від того, як процес пише журнали.
copytruncateпрацює, лише якщо повідомлення журналу додаються до файлу (напр whatever >> logfile.,
а не тоді, коли він перенаправляє вихід (наприклад whatever > logfile).

Оскільки у версії 8.16 rsyslog має опцію imfile, reopenOnTruncateяка обробляє проблему copytruncte.

Для rsyslog конкретно, мабуть, більше сенсу залишати речі такими, якими вони є.

Основна причина полягає в тому, що rsyslog має внутрішні черги, які він може використовувати у випадках, коли його вихідна ручка стає недоступною.

Перезавантаження a) призведе до того, щоб rsyslog відтворив власний файл журналу, і b) призведе до того, що будь-які події черги будуть передані у файл під час створення.

Можливо, copytruncate не приносить шкоди (хоча я б заклопотаний тим, що частково записані рядки усічені), але я схиляюся до думки, що копія / видалення / перезавантаження "безпечніше" з точки зору цілісності.

Як зазначає @ faker , оскільки rsyslog може впоратися з ситуацією, коли його файл стає недоступним, не існує переконливої ​​причини використовувати copytruncate.

І , як згадувалося на @ SelivanovPavel , Rsyslog фактично вимагає спеціальної конфігурації , щоб мати справу з копією зрізаним правильно.

Тож якби тільки тому, що використання reloadпідходу вимагає меншого відхилення від конфігурації за замовчуванням, я б зберігав його.