Как вы анализируете файлы журналов с машин UNIX / Linux? Мы запускаем несколько сотен серверов, которые все генерируют свои собственные файлы журналов, либо напрямую, либо через syslog. Я ищу достойное решение, чтобы объединить их и выделить важные события. Эта проблема разбивается на 3 компонента:
1) Транспорт сообщений
Классический способ - использовать системный журнал для записи сообщений на удаленный хост. Это хорошо работает для приложений, которые входят в системный журнал, но менее полезно для приложений, которые записывают в локальный файл. Решения для этого могут включать в себя регистрацию приложения в FIFO, подключенном к программе, для отправки сообщения с использованием системного журнала, или путем написания чего-либо, что выполнит поиск локальных файлов и отправит выходные данные на центральный хост системного журнала. Тем не менее, если мы возьмем на себя труд по написанию инструментов для передачи сообщений в системный журнал, лучше ли нам заменять все это чем-то вроде Scribe Facebook, который предлагает большую гибкость и надежность, чем системный журнал?
2) агрегация сообщений
Кажется, записи в журнале делятся на два типа: для каждого хоста и для каждого сервиса. Сообщения для каждого хоста - это сообщения, которые появляются на одном компьютере; думаю, сбои диска или подозрительные логины. Сообщения для каждой службы появляются на большинстве или на всех хостах, на которых запущена служба. Например, мы хотим знать, когда Apache обнаружит ошибку SSI, но мы не хотим, чтобы такая же ошибка была на 100 машинах. Во всех случаях мы хотим видеть только одно сообщение каждого типа: нам не нужно 10 сообщений о том, что один и тот же диск вышел из строя, и мы не хотим, чтобы сообщение появлялось каждый раз, когда был сломан SSI.
Один из подходов к решению этой проблемы заключается в объединении нескольких сообщений одного типа в одно на каждом хосте, отправке сообщений на центральный сервер и затем объединении сообщений одного типа в одно общее событие. SER может сделать это, но это неудобно в использовании. Даже после нескольких дней бездействия у меня работали только элементарные агрегаты, и мне приходилось постоянно искать логику, которую SER использует для корреляции событий. Это мощная, но хитрая штука: мне нужно что-то, что мои коллеги могли бы подобрать и использовать в кратчайшие сроки. Правила SER не отвечают этому требованию.
3) Генерация оповещений
Как мы сообщаем нашим администраторам, когда происходит что-то интересное? Почтовый ящик группы? Ввести в Nagios?
Итак, как вы решаете эту проблему? Я не ожидаю ответа на тарелке; Я сам могу проработать детали, но было бы неплохо обсудить то, что, несомненно, является общей проблемой. На данный момент мы используем смесь заданий cron, системного журнала и тех, кто знает, что еще нужно найти для событий. Это не расширяемое, не обслуживаемое и не гибкое, и поэтому мы скучаем по многим вещам, которые не должны делать.
Обновлено: мы уже используем Nagios для мониторинга, который отлично подходит для обнаружения неработающих хостов / служб тестирования / и т. Д., Но менее полезен для очистки лог-файлов. Я знаю, что для Nagios есть плагины для журналов, но меня интересует нечто более масштабируемое и иерархическое, чем оповещения для каждого хоста.