использование VFS для динамического монтирования
Несколько причин, о которых я могу подумать:
- В корпоративных средах у вас могут быть тысячи пользователей. В этом случае cron придется каждую минуту просматривать каталог каждого пользователя на предмет наличия файла crontab (был ли он создан, удален или изменен).
Храня их в одном месте, он не должен выполнять это интенсивное сканирование. - Домашние каталоги могут быть не всегда доступны. Если домашние каталоги являются autofs mount, они могут быть не смонтированы. Если заставить cron проверять их каждую минуту, они будут смонтированы и не будут размонтированы из-за бездействия. Также, если домашний каталог зашифрован и расшифрован паролем пользователя, cron не сможет добраться до домашнего каталога, пока пользователь не войдет в систему и не расшифрует/монтирует его.
- Домашние каталоги могут быть общими для всех хостов. Если домашний каталог является общим сетевым ресурсом, то один и тот же домашний каталог будет отображаться на нескольких хостах. Но вы можете не хотеть, чтобы ваши задания cron выполнялись на всех хостах, а только на одном из них.
Возможным решением может быть отправка журналов в не -реляционную базу данных.
Вы также можете попробовать какой-нибудь хак, выбрав файловую систему, которая поддерживает одновременную запись из нескольких источников.
У обоих этих двух решений есть свой собственный набор проблем, и они мне не нравятся.
Другим возможным решением проблемы является совместное использование общего каталога /var/log/machine через NFS. Это также неприятный хак, который может работать с парой серверов, но плохо масштабируется.
Я бы создал центральный сервер системных журналов и по возможности направлял бы на него все журналы. Таким образом, по крайней мере, в этих логах решается проблема синхронности.
Что касается других приложений, которые не поддаются прямому syslog'ированию, или даже для syslog, я бы посмотрел на filebeat или Graylog.
В конечном счете, я бы попытался обрабатывать не -системные журналы в центральном системном журнале (. Последнее я делал с журналами Apache и Tomcat ).
Вы также можете ознакомиться с другими коммерческими предложениями, такими как loggly, Scalyr. New Relic или Splunk Enterprise. В качестве дополнительного бонуса вы можете иметь очень хорошую статистику для демонстрации руководству и планирования загрузки.
После затрат и наличия хорошо -определенного процесса,затем вы устанавливаете внутренние правила, согласно которым тот, кому нужно установить новое решение, должен отправлять журналы в официальное место назначения с помощью «официального» метода.
П.С. Вы пытаетесь решить организационную проблему с помощью технического решения. Часто это не слишком хорошо. Вы должны задействовать свои высшие -ups.