Как вы анализируете файлы журналов с компьютеров UNIX / Linux? Мы запускаем несколько сотен серверов, каждый из которых генерирует свои собственные файлы журналов напрямую или через системный журнал. Я ищу достойное решение, чтобы объединить их и выделить важные события. Эта проблема разбивается на 3 компонента:
1) Транспорт сообщений
Классический способ - использовать системный журнал для записи сообщений на удаленный хост. Это отлично работает для приложений, которые входят в системный журнал, но менее полезно для приложений, которые записывают в локальный файл. Решения для этого могут включать размещение журнала приложения в FIFO, подключенном к программе для отправки сообщения с помощью системного журнала, или запись чего-либо, что будет выполнять поиск локальных файлов и отправлять вывод на центральный узел системного журнала. Однако, если у нас возникнут проблемы с написанием инструментов для добавления сообщений в системный журнал, не лучше ли нам полностью заменить их чем-то вроде Facebook? Писец что предлагает большую гибкость и надежность, чем syslog?
2) Агрегация сообщений
Кажется, что записи журнала делятся на два типа: для каждого хоста и для каждой службы. Сообщения для каждого хоста - это сообщения, которые происходят на одной машине; подумайте о сбоях диска или подозрительном входе в систему. Сообщения для каждой службы появляются на большинстве или на всех хостах, на которых работает служба. Например, мы хотим знать, когда Apache обнаруживает ошибку SSI, но нам не нужна такая же ошибка на 100 машинах. Во всех случаях мы хотим видеть только одно сообщение каждого типа: нам не нужно 10 сообщений о том, что один и тот же диск вышел из строя, и мы не хотим, чтобы сообщение появлялось каждый раз при срабатывании сбоя SSI.
Один из подходов к решению этой проблемы - объединить несколько сообщений одного типа в одно на каждом хосте, отправить сообщения на центральный сервер, а затем объединить сообщения одного типа в одно общее событие. SER может это сделать, но пользоваться им неудобно. Даже после пары дней возни у меня работали только элементарные агрегаты, и мне приходилось постоянно искать логику, которую использует SER для корреляции событий. Это мощная, но непростая вещь: мне нужно что-то, что мои коллеги могут подобрать и использовать в кратчайшие сроки. Правила SER не соответствуют этому требованию.
3) Генерация предупреждений
Как мы сообщаем нашим администраторам, что происходит что-то интересное? Отправить в почтовый ящик группы? Ввести в Nagios?
Итак, как вы решаете эту проблему? Я не жду ответа на тарелке; Я могу проработать детали сам, но было бы здорово обсудить на высоком уровне, что, безусловно, является общей проблемой. В настоящий момент мы используем мешанину из заданий cron, системного журнала и неизвестно чего еще для поиска событий. Это не расширяемо, не обслуживаем и не гибко, и поэтому мы упускаем многое из того, чего не должны.
Обновлено: мы уже используем Nagios для мониторинга, который отлично подходит для обнаружения неработающих хостов / служб тестирования / и т. д., но менее полезен для очистки файлов журналов. Я знаю, что для Nagios существуют плагины журналов, но меня интересует что-то более масштабируемое и иерархическое, чем предупреждения для каждого хоста.
Я использовал три разные системы для централизации журналов:
Для №3 я обычно использую syslog-ng для пересылки сообщений от каждого хоста непосредственно в splunk. Он также может анализировать файлы журнала напрямую, но это может быть немного неудобно.
Splunk отлично подходит для поиска и категоризации ваших журналов. Я не использовал splunk для оповещения журнала, но думаю, что это возможно.
Вы можете взглянуть на OSSEC, полный HIDS с открытым исходным кодом, он выполняет анализ журналов и может запускать действия или отправлять почту при предупреждениях. Оповещения запускаются набором простых правил на основе XML, в него включено множество предопределенных правил для различных форматов журналов, и вы можете добавлять свои собственные правила.
Взгляни на Осьминог. Он полностью настраивается и, кажется, отвечает всем вашим потребностям ...
PS: Я разработчик этого решения.
Вам нужно заглянуть в систему мониторинга, например Ядро Зеносса. Среди прочего, на вступительной странице написано:
Zenoss Event Monitoring and Management предоставляет возможность агрегировать информацию о журналах и событиях из различных источников, включая мониторинг доступности, мониторинг производительности, источники системного журнала, Источники ловушек SNMP, Журнал событий Windows.
Видеть какой-инструмент-вы-используете-для-мониторинга-ваших-серверов.