Вопрос: Масштабирование Logstash (с помощью redis / elasticsearch)


За кластер из более чем 12 centos 5.8 серверов я развернул logstash, используя собственный отправитель логсташей, который отправляет /var/log/*/*.log назад к центральному серверу логсташа.

Мы попытались использовать rsyslogd в качестве отправителя, но из-за ошибки в модуле ImFile rsyslogd, если удаленный конец не ответил, журналы будут накапливаться в памяти.

В настоящее время мы используем Redis в качестве механизма транспорта, поэтому logstash01 имеет redis, работающий локально, привязанный к IP для VLAN для этих журналов.

Поэтому logstash-shipper отправляет redis на logstash01. logstash01 отправляет в Elasticsearch, работающий в отдельном процессе.

Вот что мы видим. У Elasticsearch есть 141 заблокированный поток. Из-за того, что родительский список elasticsearch показывает:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Вот jstack от elasticsearch

Вот jstack из logstash

Итак .. Вчера вечером некоторые веб-серверы (чьи журналы были привязаны к logstash) перешли на гайки, с загрузкой в ​​среднем более 500.

На logstash01 есть

Dec 19 00:44:45 logstash01 kernel: [736965.925863] Killed process 23429 (redis-server) total-vm:5493112kB, anon-rss:4248840kB, file-rss:108kB

Таким образом, OOM-killer убил redis-server, что означало, что журналы были заполнены в памяти на серверах, которые отправляли вещи. как-то означает, что apache получает свои трусики в закрутке. (Честно говоря, я не уверен, как, я просто предполагаю, что это хвост журнала) ..

Это моя теория о том, как разворачивались события:

  1. У нас был трафик.
  2. Было создано огромное количество журналов.
  3. Они складываются в Redis, так как logstash / elasticsearch, похоже, способен обрабатывать 300-400 новых событий / секунду.
  4. Редис полностью заполнился до такой степени, что ООМ-убийца убил его бессмысленно.
  5. Redis перестает принимать новые предметы.
  6. Элементы теперь начинают накапливаться на стороне удаленных хостов.
  7. Все идет орешки, Apache перестает принимать запросы. (Зачем?).

Вопросы таковы:

  1. Почему апач сходит с ума, если есть что-то, закрывающее журнал. Разве это то, что от него блокирует апач?

  2. Есть ли разумный способ сделать elasticsearch быстрее / лучше / устойчиво?

  3. Есть ли разумный способ сделать redis упругим и не умереть из-за того, что он OOM'd

  4. Есть ли фундаментальный недостаток в том, как я все это установил, или у всех есть эта проблема?

-- РЕДАКТИРОВАТЬ --

Некоторые спецификации для @lusis.

admin@log01:/etc/init$ free -m
             total       used       free     shared    buffers     cached
Mem:          7986       6041       1944          0        743       1157
-/+ buffers/cache:       4140       3845
Swap:         3813       3628        185

Filesystem             Size  Used Avail Use% Mounted on
/dev/sda2               19G  5.3G   13G  31% /
udev                   3.9G  4.0K  3.9G   1% /dev
tmpfs                  1.6G  240K  1.6G   1% /run
none                   5.0M     0  5.0M   0% /run/lock
none                   3.9G     0  3.9G   0% /run/shm
/dev/sda1               90M   72M   14M  85% /boot
/dev/mapper/data-disk  471G  1.2G  469G   1% /data

/dev/sda2 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/data-disk on /data type ext3 (rw)
/data/elasticsearch on /var/lib/elasticsearch type none (rw,bind)

log01:/etc/init$ top 
top - 14:12:20 up 18 days, 21:59,  2 users,  load average: 0.20, 0.35, 0.40
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.0%us,  1.0%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  : 12.0%us,  1.0%sy,  0.0%ni, 86.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu2  :  4.7%us,  0.3%sy,  0.0%ni, 94.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  5.6%us,  1.3%sy,  0.0%ni, 93.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  5.3%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  6.4%us,  1.0%sy,  0.0%ni, 92.3%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   8178120k total,  6159036k used,  2019084k free,   761780k buffers

16
2017-12-19 11:40


Источник


У меня были проблемы с ES и этими супер-классными настройками. Теперь я пишу свой собственный простой syslog-приемник в python. Единственный способ разобраться в том, чтобы начать работу и продолжать добавлять ES-узлы, увеличивая размер логсташа ... кошмар. Я считаю, что apache блокирует запись в файле журнала, так что это может быть проблемой, если он не может записывать в файл журнала. - Abhishek Dujari
Re: проблема с rsyslog, у Bitbucket также был выход из-за проблем с rsyslog. Oни блог об этом и как они работали вокруг него. - James O'Gorman


Ответы:


Ваше сообщение не описывает многое в способе спецификаций (память на индексаторе LS, том журнала или многое другое), но я постараюсь ответить на ваши вопросы наилучшим образом, я могу в первую очередь. Отказ от ответственности: я один из разработчиков logstash -

  1. Apache, идущий на гайки, вероятно, является побочным эффектом процесса лостового старта. Я сейчас отложил это.

  2. Разумным способом сделать ES f / b / s является добавление дополнительных узлов ES. Это очень легко. Они даже автоматически обнаруживают друг друга в зависимости от топологии сети. После 17 лет в этой отрасли я никогда не видел ничего масштабного горизонтально так же легко, как ElasticSearch.

  3. Для f / b / s Redis не используйте кластеры redis. Более поздние версии Logstash могут выполнять балансировку Redis внутренне. Выход Redis поддерживает список хостов Redis в конфигурации плагина, и поддержка также будет добавлена ​​во входную сторону, чтобы соответствовать этому. В промежутке времени вы можете использовать несколько определений ввода Redis на стороне индексатора / потребителя.

  4. Я не могу ответить на этот вопрос, не говоря уже о том, что это похоже на то, что вы пытаетесь сделать многое с одним (возможно, недостаточно мощным хостом).

Любой хороший процесс масштабирования начинается с разбивки размещенных компонентов на отдельные системы. Я не вижу ваших конфигураций gist'd в любом месте, кроме мест, где «узкие места» в журнальной стойке находятся в фильтрах. В зависимости от того, сколько преобразований вы делаете, это может повлиять на использование памяти в процессах Logstash.

Logstash работает много как legos. Вы можете использовать кирпич 2x4 или использовать два кирпича 2x2 для выполнения одной и той же задачи. За исключением случая логсташа, на самом деле более жестким является использование меньших кирпичей, чем один большой кирпич.

Некоторые общие рекомендации, которые мы обычно даем, это:

  • судовые журналы как можно быстрее с края Если вы можете использовать чистый сетевой транспорт вместо записи на диск, это приятно, но не обязательно. Logstash основан на JVM и имеет хорошие и плохие последствия. Используйте альтернативного грузоотправителя. Я написал питон на основе ( https://github.com/lusis/logstash-shipper ), но я бы предложил, чтобы люди использовали Бивера вместо ( https://github.com/josegonzalez/beaver ).

  • генерировать ваши журналы в формате, который требует как можно меньшей фильтрации (json или оптимально json-event format) Это не всегда возможно. Я написал приложение 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/

  • разбить вещи на несколько компонентов В каждом разговоре, который я сделал о logstash, я описываю его как unix-канал на стероидах. Вы можете сделать трубопровод длинным или коротким, как вам нравится. Вы масштабируете логсташ, перемещаясь вокруг обязанностей по горизонтали. Это может означать продление срока действия конвейера, но мы не говорим о какой-либо статистически релевантной с точки зрения задержки накладных расходов. Если у вас есть больший контроль над вашей сетью (т. Е. НЕ на EC2), вы можете сделать некоторые потрясающие вещи со стандартной изоляцией трафика.

Также обратите внимание, что список рассылки logstash ОЧЕНЬ активен, поэтому вы всегда должны начинать работу там. Санируйте и создавайте свои конфиги, так как это лучшее место для начала.

Есть компании (например, Sonian), масштабирующие ElasticSearch до уровней петабайта и компаний (таких как Mailchimp и Dreamhost), масштабируя Logstash до безумных уровней. Это может быть сделано.


22
2018-01-07 14:06



Я вставил некоторую системную информацию в Q - Tom O'Connor
Я бы сказал, что 8G является недостаточным в зависимости от объема журналов и того, как долго вы их держите. Я бы начал перемещать Redis и Logstash на другой сервер. Вы используете ES в процессе работы с Logstash или как отдельный сервис? - lusis
Это отличный сервис. Я сделал смелый шаг перед рождеством и выключил redis, сохраняя поведение диска, и все это стало более стабильным. - Tom O'Connor
Ссылка apache-json-logs нарушена. Есть ли замена? - Kate Ebneter