Потоковая передача текстовых лог-файлов в RabbitMQ, а затем восстановление на другом конце?

Question

Требования

У нас есть несколько серверов (20-50) - Solaris 10 и Linux (SLES) - выполняющих различные приложения, каждый из которых генерирует несколько событий журнала в текстовые файлы. Нам нужно перенести их в отдельный блок мониторинга, где мы можем выполнять анализ / отчетность / оповещения.

Текущий подход

В настоящее время мы используем SSH с удаленным «tail -f» для потоковой передачи файлов журналов с серверов на блок мониторинга. Однако это несколько хрупко.

Новый подход

Я бы хотел заменить это на RabbitMQ. Серверы будут публиковать свои события журнала в этом, и каждый скрипт / приложение мониторинга может затем подписаться на соответствующую очередь.

В идеале нам бы хотелось, чтобы сами приложения создавали события непосредственно в очередь RabbitMQ.

Однако, предполагая, что это не вариант в краткосрочной перспективе (у нас может не быть источника для всех приложений), нам нужен способ в основном "хвостить -f" лог-файлов с диска. Я чувствую себя наиболее комфортно в Python, поэтому я искал Pythonic способ сделать это - консенсус, похоже, просто использовать цикл с readline () и sleep () для эмуляции tail -f.

Вопросы

1. Существует ли более простой способ "tail -f" целой связки текстовых файлов непосредственно в поток RabbitMQ? Что-то встроенное или расширение, которое мы могли бы использовать? Любые другие советы / советы здесь?

2. Если мы напишем оболочку Python для захвата всех файлов журнала и их публикации - в идеале я бы хотел, чтобы один скрипт Python одновременно обрабатывал все файлы журнала, а не вручную раскручивал отдельный экземпляр для каждого файла журнала. Как мы должны решить это? Есть ли соображения относительно производительности, использования процессора, пропускной способности, параллелизма и т. Д.?

3. Нам нужно подписаться на очереди, а затем, возможно, сбросить события обратно на диск и восстановить исходные файлы журналов. Любые советы по этому поводу? И нам также хотелось бы, чтобы один сценарий Python, который мы могли бы запустить для восстановления всех файлов журналов, а не 50 отдельных экземпляров одного и того же сценария, - это легко достижимо?

Ура, Victor

PS: Мы взглянули на Scribe Facebook, а также на Flume, и оба они кажутся немного тяжелыми для наших нужд.

Answer 1

Если это возможно, вы можете заставить Приложение публиковать события в асинхронном режиме в RabbitMQ вместо записи его в файлы журнала.Я сделал это в настоящее время на Java.

Но иногда невозможно сделать так, чтобы приложение регистрировалось так, как вы хотите.

1) Вы можете написать файл-тайлер на python, который публикует наAMQP.Я не знаю ничего, что включает файл в качестве входа в RabbitMQ.Взгляните на http://code.activestate.com/recipes/436477-filetailpy/ и http://www.perlmonks.org/?node_id=735039 для отслеживания файлов.2) Вы можете создать Python Daemon, который может привязывать все заданные файлы либо как процессы, либо в циклическом порядке.

3) Подобный подход к 2 может помочь вам решить эту проблему.Возможно, вы можете иметь одну очередь для каждого файла журнала.

Answer 2

Если вы говорите о ведении журнала приложений (в отличие, например, от журналов доступа, таких как журналы веб-сервера Apache), вы можете использовать обработчик для ведения журнала stdlib , который записывает в промежуточное ПО AMQP .

Answer 3

Вы, похоже, описываете централизованный системный журнал с rabbitmq в качестве транспорта.

Если бы вы могли жить с syslog, взгляните на syslog-ng. В противном случае вы могли бы сэкономьте время, используя части logstash (http://logstash.net/).