rsyslog с logrotate: перезагрузите rsyslog по сравнению с copytruncate
Я работаю над Ubuntu 14 со значением по умолчанию rsyslog и logrotate утилитой.
В значении по умолчанию rsyslog logrotate /etc/logrotate.d/rsyslog конфигурация я вижу следующее:
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
reload rsyslog >/dev/null 2>&1 || true
endscript
}
Из того, что я понимаю, рекомендуется использовать copytruncate во всех logrotate сценариях, поскольку это не делает перемещает текущий журнал, а скорее усекает журнал, таким образом, любой процесс с открытым обработчиком файлов сможет продолжать писать в него.
Таким образом, каким образом конфигурация по умолчанию с помощью rsyslog перезагружает функцию вместо этого?
Чтобы ответить на ваш вопрос, вам сначала нужно понять различные компромиссы между перезагрузкой и copytruncate:
- reload : старый файл журнала переименовывается, и процесс записывает в него log уведомляется (через сигнал Unix) о необходимости воссоздания своего файла журнала. Это самый быстрый метод с меньшими накладными расходами: операции переименования / перемещения выполняются очень быстро и имеют постоянное время выполнения. Более того, это почти атомарная операция: это означает, что (почти) никакая запись в журнале не будет потеряна во время перемещения / перезагрузки. С другой стороны, вам нужен процесс, способный перезагружать и повторно открывать свой файл журнала. Rsyslog - это такой процесс, поэтому в конфигурации logrotate по умолчанию используется метод перезагрузки. Использование этого режима с rsyslog настоятельно рекомендуется восходящим потоком rsyslog.
- copytruncate : старый файл журнала копируется в файл архива, а затем он усекается, чтобы «удалить» старый строки журнала. Хотя операция усечения выполняется очень быстро, копия может быть довольно длинной (в зависимости от размера вашего файла журнала). Более того, некоторые записи в журнале могут быть потеряны во время между операциями копирования (помните, это может быть медленным) и усечением. По этим причинам copytruncate не используется по умолчанию для служб, способных перезагружать и воссоздавать свои файлы журналов. С другой стороны, если сервер не способен перезагружать / воссоздавать файлы журнала, copytruncate - ваш самый безопасный вариант. Другими словами, он не требует поддержки на уровне обслуживания. Исходный проект rsyslog настоятельно не рекомендует использовать этот режим.
Это полностью зависит от того, как процесс записывает журналы.
copytruncate работает только в том случае, если сообщения журнала добавлены к файлу (например, any >> logfile .
И не тогда, когда он перенаправляет вывод (например, любой> файл журнала ).
Начиная с версии 8.16, rsyslog имеет параметр imfile reopenOnTruncate , который обрабатывает copytruncte выпуск.
В частности, для rsyslog, вероятно, имеет больше смысла оставить все как есть.
Основная причина в том, что у rsyslog есть внутренние очереди, которые он может использовать в случаях, когда его выходной дескриптор становится недоступным .
Перезагрузка будет: а) заставит rsyslog воссоздать свой собственный файл журнала и б) приведет к тому, что все события из очереди будут сброшены в файл при создании.
Может быть, copytruncate не причинит вреда (хотя я был бы обеспокоен об усеченных частично написанных строках), но я склонен думать, что копирование / удаление / перезагрузка «безопаснее» с точки зрения целостности.
Как упоминал @ faker , поскольку rsyslog может справиться с ситуацией, когда его файл становится недоступным, нет веских причин для использования copytruncate.
И как указано @ SelivanovPavel , rsyslog на самом деле требует определенной конфигурации для правильной обработки усечения копии.
Так что хотя бы потому, что использование подхода reload требует меньшего отклонения от конфигурации по умолчанию, я бы оставил его.
Как автор rsyslog, copytruncate на самом деле очень , очень и очень плохой выбор. Он по своей природе колоритен, и его использование почти гарантирует, что вы потеряете данные журнала. Чем чаще выполняется запись в файл, тем больше вы потеряете. И это не просто часть последней строки, а может быть несколько сотен, в зависимости от точного времени и состояния системы в момент, когда происходит ротация.
Когда файл перемещается и появляется новый индексный дескриптор (файл) Создано, rsyslog отслеживает предыдущий файл и полную обработку. Так что в этом случае у вас нет никаких потерь. Гарантированно (кроме случаев, когда вы размонтируете файловую систему ...).
О "reopenOnTruncate": Я лично видел, что reopenOnTruncate также является колоссальным и в других отношениях, особенно с NFS и подобными. Некоторое время назад я полностью удалил эту функциональность, но позже меня убедили объединить аналогичную функциональность. Скорее всего, это останется «экспериментальным» навсегда, поскольку я действительно знаю, что у людей возникают проблемы на очень сильно загруженных системах. "copytruncate" - просто неподходящий режим для работы с файлами журнала.
В настоящее время я работаю над рефакторингом imfile (ETA 8.34 или 8.35). Реорганизованная версия, вероятно, сможет предотвратить случайную повторную отправку из-за гонки API, но также не сможет защитить от потери данных - потому что это концептуально невозможно.