Logstash vs Rsyslog для агрегации файлов журнала
Я работаю над решением для централизованной агрегации файлов журнала из нашего CentOs 6.x-сервер. После установки стека Elasticsearch/Logstash/Kibana (ELK) я наткнулся на плагин Rsyslog omelasticsearch, который может отправлять сообщения из Rsyslog в Elasticsearch в формате logstash и начал спрашивать себя, зачем мне нужен Logstash.
Logstash имеет множество различных плагинов ввода, включая тот, который принимает сообщения Rsyslog. Есть ли причина, по которой я буду использовать Logstash для моего использования случай, когда мне нужно собрать содержимое файлов журналов с нескольких серверов? Кроме того, есть ли преимущество отправки сообщений из Rsyslog в Logstash вместо отправки их непосредственно в Elasticsearch?
4 ответов
Я бы использовал Logstash посередине, если есть что-то, что мне нужно от него, чего у rsyslog нет. Например, получение GeoIP с IP-адреса.
Если, с другой стороны, мне нужно будет индексировать содержимое системного журнала или файла в Elasticsearch, я бы использовал rsyslog напрямую. Он может выполнять буферизацию (диск+память), фильтрацию, вы можете выбрать, как будет выглядеть документ (например, вы можете поместить текстовую серьезность вместо числа), и он может анализировать неструктурированные данные. Но главным преимуществом является производительность, на которой сосредоточен rsyslog. Вот презентация с некоторыми номерами (и советами и трюками) на Logstash, rsyslog и Elasticsearch: http://blog.sematext.com/2015/05/18/tuning-elasticsearch-indexing-pipeline-for-logs/
Я бы рекомендовал logstash. Это было бы проще настроить, больше примеров, и они тестируются, чтобы соответствовать друг другу.
кроме того, есть некоторые преимущества, в logstash вы можете фильтровать и изменять свои журналы.
- вы можете расширить журналы с полезными данными: имя сервера, метка времени, ...
- приведение типов string в int, и т. д. (полезно для правильного эластичного индекса)
- отфильтровать журналы по некоторым правилам
кроме того, вы можете настроить размер партии для оптимизации экономии на эластичность. Еще одна особенность, если что-то пошло не так, и есть сумасшедшее количество журналов в секунду, что эластичный не может обрабатывать, вы можете настроить logstash, что он сохранит некоторую очередь событий или отбросит события, которые не могут быть сохранены.
Если вы идете прямо с сервера на elasticsearch, вы можете получить основные документы (предполагая, что источником является json и т. д.). Для меня сила logstash-добавить значение к журналам, применяя бизнес-логику для изменения и расширения журналов.
вот один пример: syslog предоставляет уровень приоритета (0-7). Я не хочу иметь круговую диаграмму, где значения 0-7, поэтому я делаю новое поле, содержащее красивые имена ("emerg"," debug " и т. д.), которые могут быть использованы для дисплей.
только один пример...
не является жизнеспособным вариантом, если вы действительно хотите, чтобы полагаться на систему работы под нагрузкой и высокой доступности.
мы обнаружили, что использование rsyslog для отправки в централизованное место, архивировать его с помощью redis Кафки, а затем с помощью logstash, чтобы сделать свою магию и корабль Elasticsearch является лучшим вариантом.
читайте наш блог об этом здесь - http://logz.io/blog/deploy-elk-production/
(отказ от ответственности - я продукт VP для logz.Ио и мы предлагаем лось как сервис)