Масштабування Logstash (з червоним / еластичним пошуком)

На кластері з понад 12 центровими серверами 5.8 я розгорнув logstash за допомогою власного вантажовідправника, який відправляє /var/log/*/*.logназад на центральний сервер logstash.

Ми намагалися використовувати rsyslogd як вантажовідправника, але через помилку в модулі ImFile rsyslogd, якщо віддалений кінець не відповість, журнали накопичуються в пам'яті.

Наразі ми використовуємо Redis як транспортний механізм, тому logstash01 перезапустився локально, прив’язаний до IP для VLAN для цих журналів.

Тож logstash-вантажовідправник відправляє redis на logstash01. logstash01 посилає Elasticsearch, що працює в окремому процесі.

Ось що ми бачимо. Elasticsearch має 141 заблоковану нитку. Напруження батьківського еластичного дослідження показує:

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 / elastsearch шукає лише 300-400 нових подій в секунду.
4. Редіс повністю заповнився до того моменту, коли вбивця OOM безглуздо вбив його.
5. Redis перестає приймати нові предмети.
6. Елементи тепер починають накопичуватися на стороні віддалених хостів.
7. Все йде нанівець . Apache перестає приймати запити. (Чому?).

Питання такі:

8. Чому apache збивається, якщо просто щось зав'язує його журнал. Це те, що річ, що вказує на нього, блокує apache від написання?

9. Чи є розумний спосіб зробити еластичний пошук швидшим / кращим / пружнішим?

10. Чи є здоровий спосіб зробити Redis пружним і не померти через те, що був OOM'd

11. Чи є фундаментальний недолік у тому, як я все це налаштував, чи всі мають цю проблему?

- EDIT -

Деякі характеристики для @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, ймовірно, є побічним ефектом процесу зникнення журналу. Я б відклав це поки.

2. Здоровим способом зробити ES f / b / s є додавання більшої кількості вузлів ES. Це серйозно так просто. Вони навіть автоматично розкривають один одного в залежності від топології мережі. Після 17 років у цій галузі я ніколи не бачив нічого масштабного по горизонталі так просто, як ElasticSearch.

3. Для f / b / s Redis не використовуйте кластеризації Redis. Новіші версії Logstash дозволяють Redis балансувати навантаження внутрішньо. Вихід Redis підтримує список хостів Redis у конфігурації плагінів, і підтримка вже буде додана на сторону введення, а також відповідати цьому. У проміжку часу ви можете використовувати кілька визначень Redis вхідних даних на стороні індексатора / споживача.

4. Я не можу відповісти на це, крім того, щоб сказати, що це здається, що ви намагаєтеся зробити багато з одним (можливо, недостатнім хостом).

Будь-який хороший процес масштабування починається з розбиття складених компонентів на окремі системи. Я не бачу, щоб ваші конфігурації були ніде, окрім місць, де "вузькі місця" logstash є у фільтрах. Залежно від кількості перетворень, які ви робите, це може вплинути на використання пам'яті процесів Logstash.

Logstash працює дуже багато, як легоси. Для виконання одного і того ж завдання можна використовувати цеглу 2х4 або дві цегли 2x2. За винятком випадків logstash, фактично міцніше використовувати менші цегли, ніж один великий цегла.

Деякі загальні поради, які ми зазвичай даємо, це:

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

• генерувати ваші журнали у форматі, який потребує якнайменшої фільтрації (json або оптимально формат json-події) Це не завжди можливо. Я написав додаток log4j, щоб зробити це ( https://github.com/lusis/zmq-appender ) і, врешті-решт, розбив макет шаблону у власне репо ( https://github.com/lusis/log4j-jsonevent-layout ). Це означає, що я не потребую жодної фільтрації в logstash для цих журналів. Я просто встановив тип введення на "json-подія"

Для apache можна спробувати такий підхід: http://cookbook.logstash.net/recipes/apache-json-logs/

• розбивати речі на декілька компонентів У кожній розмові, яку я робив про logstash, я описую це як "Unix" на стероїдах. Ви можете зробити трубопровід довгим або коротким, як вам подобається. Ви масштабуєте логсташ, переміщуючи навколо відповідальності горизонтально. Це може означати збільшення трубопроводу довше, але ми не говоримо про щось статистично актуальне з точки зору затримки накладних витрат. Якщо ви більше контролюєте свою мережу (тобто НЕ на EC2), ви можете робити дивовижні речі зі стандартною ізоляцією трафіку.

Також зауважте, що список розсилки logstash ДУЖЕ активний, тому завжди слід починати з нього. Очистіть конфігурації та вкажіть їх, оскільки це найкраще місце для початку.

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