Системные журналы, записанные в монтирование NFS

Question

Сегодня у нас была проблема с сервером Linux, который заполнил (100%) весь его корневой (/) раздел из-за неверной конфигурации в postfix, которая привела к огромному файлу /var/log/syslog и вчера мы начали использовать EFS (NFS) AWS сервис) для другого случая использования.

Основываясь на этих двух событиях, мы провели внутреннюю беседу о возможных обходных путях избежания перебоев в работе серверов / дисков из-за сумасшедших файлов журналов, и нам кажется, что использование единого монтирования NFS для всех файлов журналов серверов может быть хорошей идеей, поскольку Служба EFS AWS обеспечивает практически неограниченное количество (8 эксабайт, сообщаемых df), а консолидация всех журналов на одном диске может даже облегчить сбои отладки.

Учитывая вышеизложенные факты и идею, вопрос вполне очевиден: является ли этот предлагаемый подход, использующий монтирование NFS для всех журналов Linux, хорошим? За и против?

Я осознаю, что это может быть неуместный вопрос, но мне нужна не обратная связь, а реальные возможные недостатки, с которыми мы можем столкнуться, основываясь на реальных фактах / проблемах / измерениях.

Answer 1

1) Конечно, это зависит от объема ведения журнала, но ведение журнала в сети происходит медленно, и это может существенно замедлить работу частей вашей системы по сравнению с ведением журнала на локальном диске. NFS также может использовать значительный процессор. Я видел людей, которые неделями гонялись за проблемами с производительностью на сервере, пока не выяснили, что это происходит из журналов, перемещенных в сетевую ФС из-за недостатка дискового пространства (а это была NFS в той же машинной комнате).

2) Лучше 1) переместить журналы в их собственный раздел, 2) иметь довольно агрессивную скользящую политику и 3) затем, возможно, переместить сжатые журналы в AWS. Журналы могут многое раскрыть, если они скомпрометированы, поэтому вам лучше зашифровать их перед экспортом или обеспечить очень строгую защиту в вашем хранилище AWS.