У меня начинает складываться целая коллекция виртуальных машин Ubuntu, которыми я должен управлять. Я начинаю исследовать Puppet для управления конфигурацией всех из них и apticron, чтобы сообщить мне, что устарело. Но проблема, с которой я должен заняться раньше, чем позже, - это агрегирование журналов. Я хотел бы пока остаться в сфере бесплатного / открытого исходного кода, так как у нас пока нет большого бюджета на что-то вроде splunk.
В дополнение к системному журналу я хотел бы собирать журналы конкретных приложений (мы запускаем разные приложения на разных машинах, от nginx +senger для рельсов до Apache + Tomcat для java, до PHP для механизма выражений и сервера базы данных mysql / postgresql) , чтобы мы могли проанализировать соответствующие данные.
На данный момент я просто хочу собрать все журналы в одном месте.
Многие приложения могут регистрироваться в системном журнале, что означает, что вы можете получать журналы на сервере журналов. apache, mysql, tomcat (log4j) могут, по крайней мере.
Тогда вам понадобится компетентный сервер системного журнала для агрегирования. Я использую syslog-ng, но это потому, что 7 лет назад это была единственная серьезная альтернатива. Debian Lenny перешел на rsyslog, который, вероятно, имеет более разумную кодовую базу и даже больше функций.
По моему опыту, хороший механизм регулярных выражений - самая важная часть агрегирующего сервера системного журнала. Так много групп, которые вы хотите отфильтровать, чтобы увидеть соответствующие части. Вы также можете указать logwatch на агрегированные журналы, если хотите быстро начать работу.
РЕДАКТИРОВАТЬ: я должен быть явным. Наша стратегия состоит в том, чтобы регистрировать все, от определенного хоста до одного или нескольких файлов в папке для этого хоста, и одновременно регистрировать в сильно отфильтрованных файлах, которые регистрируют определенные действия на всех хостах. Например, может быть файл с ошибками входа на всех хостах.
Еще один интересный проект Осьминог. Это анализатор журналов с открытым исходным кодом, оповещатель и репортер. У меня еще не было возможности настроить это, но я слышал о нем кое-что хорошее.
Кто-то еще упомянул Зеносса. Я использую Zenoss, и хотя он может предупреждать на основе журналов, я бы не сказал, что это его сильная сторона. Его основная задача - мониторинг и оповещение на основе snmp, для чего я его и использую.
LogZilla обладает высокой масштабируемостью (сотни миллионов событий) и составляет 1/10 стоимости другого программного обеспечения этого класса. Его также намного проще использовать.
Для агрегирования и анализа журналов вам следует попробовать ECA (Корреляция и анализ событий) или SIEM (Менеджер событий безопасности). Например: