Сегодня у нас возникла проблема с сервером Linux, который заполнил (на 100%) весь свой корневой ( /) раздел из-за неправильной настройки в postfix, что привело к созданию огромного /var/log/syslogфайла, и вчера мы начали использовать AWS EFS (службу NFS) для других целей.
На основе этих двух событий мы провели внутреннее обсуждение возможных обходных путей, позволяющих избежать сбоев сервера/диска из-за сбоя в работе файлов журналов, и нам кажется, что использование одного монтирования NFS для всех файлов журналов серверов может быть хорошей идеей, поскольку сервис EFS AWS обеспечивает практически безграничный объем (8 эксабайт, как сообщает df), а объединение всех журналов на одном диске может даже облегчить отладку сбоев.
Учитывая вышеизложенные факты и идею, вопрос вполне очевиден: является ли предложенный подход с использованием монтирования NFS для всех журналов Linux хорошим? Плюсы / минусы?
Я понимаю, что это может быть субъективный вопрос, но мне нужна не такая обратная связь, а реальные возможные недостатки, с которыми мы можем столкнуться, исходя из реальных фактов/проблем/измерений.
решение1
1) Конечно, это зависит от объема логирования, но сетевое логирование медленное, и это может существенно замедлить работу частей вашей системы по сравнению с логированием на локальном диске. NFS также может использовать значительную часть CPU. Я видел, как люди неделями гонялись за проблемами производительности на сервере, пока не выяснили, что это было из-за того, что логи были перемещены в сетевую файловую систему из-за нехватки места на диске (а это была NFS в том же машинном зале).
2) Лучше 1) переместить журналы в их собственный раздел, 2) иметь довольно агрессивную политику обновления и 3) затем, возможно, переместить сжатые журналы в AWS. Журналы могут многое раскрыть, если их скомпрометировать, поэтому лучше зашифровать их перед экспортом или обеспечить очень строгую безопасность вашего хранилища AWS.