Масштабирование Logstash (с redis/elasticsearch)
SELinux мог бы быть включен. Любое использование
chcon -R -t httptd_sys_content_t <folder>
или
setenforce 0
Если Вы не используете SELinux затем, Вы могли бы рассмотреть отключение его постоянно. Хотя изучение/использование его всегда является хорошей идеей.
В вашем сообщении мало что говорится о спецификациях (память на индексаторе LS, том журнала или многое другое), но сначала я постараюсь ответить на ваши вопросы как можно лучше. Отказ от ответственности: я один из разработчиков logstash -
сходство с ума Apache, вероятно, было побочным эффектом процесса logstash. Я бы отложил это на время.
Разумный способ сделать ES f / b / s - добавить больше узлов ES. Это действительно так просто. Они даже автоматически обнаруживают друг друга в зависимости от топологии сети. За 17 лет работы в этой отрасли я никогда не видел ничего более простого в горизонтальном масштабировании, чем ElasticSearch.
Для f / b / s Redis не используйте кластеризацию Redis. Новые версии Logstash могут выполнять внутреннюю балансировку нагрузки Redis. Выходные данные Redis поддерживают список хостов Redis в конфигурации плагина, и поддержка будет добавлена к входной стороне, чтобы соответствовать этому. Тем временем вы можете использовать несколько входных определений Redis на стороне индексатора / потребителя.
Я не могу ответить на этот вопрос, кроме как сказать, что похоже, что вы слишком много пытаетесь сделать с одним (возможно, недостаточно мощным хостом).
Любой хороший процесс масштабирования начинается с разделения совместно размещенных компонентов на отдельные системы. Я нигде не вижу ваших конфигов, кроме тех мест, где "узкие места" logstash находятся в фильтрах. В зависимости от того, сколько преобразований вы делаете, это может повлиять на использование памяти процессами Logstash.
Logstash работает во многом как legos. Вы можете использовать кирпич 2x4 или два кирпича 2x2 для выполнения той же задачи. Если вы можете использовать чистый сетевой транспорт вместо записи на диск, это хорошо, но не обязательно. Logstash основан на JVM, и это имеет как хорошие, так и плохие последствия. Используйте альтернативного грузоотправителя. Я написал основанный на Python ( https://github.com/lusis/logstash-shipper ), но я бы посоветовал людям использовать вместо него Beaver ( https://github.com/josegonzalez/ beaver ).
создавать журналы в формате, требующем минимальной фильтрации (json или оптимально формат json-события) Это не всегда возможно. Для этого я написал приложение log4j ( https://github.com/lusis/zmq-appender ) и в конечном итоге разбил макет шаблона на собственное репо ( https: // github. com / lusis / log4j-jsonevent-layout ). Это означает, что мне не нужно делать ЛЮБУЮ фильтрацию в logstash для этих журналов. Я просто установил тип на входе 'json-event'
Для apache вы можете попробовать следующий подход: http://cookbook.logstash.net/recipes/apache-json-logs/
- break вещи на несколько компонентов В каждом разговоре о logstash я описываю его как unix pipe на стероидах. Вы можете сделать конвейер сколь угодно длинным или коротким. Вы масштабируете logstash, перемещая обязанности по горизонтали. Это может означать удлинение конвейера, но мы не говорим ни о чем статистически значимом с точки зрения накладных расходов по задержке. Если у вас есть больший контроль над своей сетью (т.е. НЕ на EC2), вы можете делать некоторые удивительные вещи со стандартной изоляцией трафика.
Также обратите внимание, что список рассылки logstash ОЧЕНЬ активен, поэтому вы всегда должны начинать с него. Дезинфицируйте и обновите свои конфигурации, так как это лучшее место для начала.
Есть компании (например, Sonian), масштабирующие ElasticSearch до петабайтных уровней, и компании (например, Mailchimp и Dreamhost) также масштабирующие Logstash до безумных уровней. Это можно сделать.