Скейлинг Logstash (с Redis /asticsearch)

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

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

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

Таким образом, logstash-shipper отправляет redis на logstash01. logstash01 отправляет Elasticsearch в отдельном процессе.

Вот что мы видим. Elasticsearch имеет 141 заблокированных тем. Распределение родительского элементаasticsearch показывает:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Вот jstack от упругого поиска

Вот 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

Так ОЫЙ-убийца убил Redis-сервер, который затем предназначенные журналы свалили в памяти на серверах , которые были судоходных вещами .. Какой каким - то образом означают , что апач получает свои панталоны в повороте. (Честно говоря, я не уверен, как, я просто предполагаю, что это следит за журналом) ..

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

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

Вопросы такие:

8. Почему Apache сходит с ума, если есть что-то, что следит за его журналом. Это то, что эта штуковина мешает Apache писать?

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

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

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

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

Некоторые спецификации для @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

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

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

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

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

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

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

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

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

• отправляйте журналы как можно быстрее с периферии. Если вы можете использовать чистый сетевой транспорт вместо записи на диск, это хорошо, но не обязательно. 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/

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

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

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