Menskalakan Logstash (dengan redis / elasticsearch)

Lebih dari satu cluster lebih dari 12 centos 5.8 server, saya menggunakan logstash menggunakan pengirim logstash asli, yang mengirimkan /var/log/*/*.logkembali ke server logstash pusat.

Kami mencoba menggunakan rsyslogd sebagai pengirim, tetapi karena bug dalam modul ImFile rsyslogd, jika ujung remote tidak menjawab, log akan menumpuk di memori.

Kami saat ini menggunakan Redis sebagai mekanisme transportasi, jadi logstash01 telah redis berjalan secara lokal, terikat ke IP untuk VLAN untuk log ini.

Jadi logstash-shipper mengirim ke redis di logstash01. logstash01 mengirimkan ke Elasticsearch yang berjalan dalam proses terpisah.

Inilah yang kami lihat. Elasticsearch memiliki 141 utas yang diblokir. Memutar induk elasticsearch menunjukkan:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Ini jstack dari elasticsearch

Ini jstack dari logstash

Jadi .. Tadi malam, beberapa server web (yang log-nya diekor oleh logstash) menjadi gila, dengan rata-rata memuat lebih dari 500.

Di logstash01, ini dia

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

Jadi pembunuh-OOM membunuh redis-server, yang kemudian berarti log menumpuk di memori pada server yang mengirimkan barang-barang .. Yang entah bagaimana berarti apache mendapatkan celana dalam putaran. (Terus terang, saya tidak yakin bagaimana, saya hanya berasumsi itu mengikuti log) ..

Ini adalah teori saya tentang bagaimana peristiwa terjadi:

1. Kami mengalami lonjakan lalu lintas.
2. Sejumlah besar log dihasilkan.
3. Ini menumpuk di Redis, sebagai logstash / elasticsearch hanya tampaknya mampu menangani 300-400 peristiwa baru / detik.
4. Redis telah mengisi sepenuhnya ke titik di mana pembunuh OOM membantai tanpa alasan.
5. Redis berhenti menerima item baru.
6. Item sekarang mulai menumpuk di sisi host jarak jauh.
7. Semuanya jadi gila . Apache berhenti menerima permintaan. (Mengapa?).

Pertanyaannya adalah ini:

8. Mengapa apache menjadi gila jika hanya ada sesuatu yang mengekor lognya. Apakah itu hal tailing yang memblokir apache dari tulisan?

9. Apakah ada cara yang waras untuk membuat elasticsearch lebih cepat / lebih baik / tangguh?

10. Apakah ada cara yang waras untuk membuat redis tangguh dan tidak mati karena menjadi OOM

11. Apakah ada kelemahan mendasar dalam cara saya mengatur semuanya, atau apakah semua orang memiliki masalah ini?

- EDIT -

Beberapa spesifikasi untuk @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

Posting Anda tidak banyak menjelaskan spesifikasi (memori pada pengindeks LS, volume log, atau banyak lainnya), tetapi saya akan mencoba dan menjawab pertanyaan Anda sebaik mungkin. Penafian: Saya salah satu pengembang logstash -

1. Apache yang gila kemungkinan merupakan efek samping dari proses logstash bertindak. Saya akan mengesampingkan itu untuk saat ini.

2. Cara waras untuk membuat ES f / b / s adalah menambahkan lebih banyak node ES. Serius itu mudah. Mereka bahkan menemukan secara otomatis satu sama lain tergantung pada topologi jaringan. Setelah 17 tahun di industri ini, saya belum pernah melihat skala apa pun secara horizontal semudah ElasticSearch.

3. Untuk f / b / s Redis, jangan gunakan pengelompokan redis. Versi Logstash yang lebih baru dapat melakukan Redis loadbalancing secara internal. Output Redis mendukung daftar host Redis di konfigurasi plugin dan dukungan akan ditambahkan ke sisi input juga agar sesuai dengan itu. Untuk sementara, Anda dapat menggunakan beberapa definisi input Redis pada sisi pengindeks / konsumen.

4. Saya tidak bisa menjawab ini selain mengatakan bahwa sepertinya Anda mencoba melakukan banyak hal dengan satu (mungkin host yang kurang bertenaga).

Setiap proses penskalaan yang baik dimulai dengan memecah komponen collocated ke dalam sistem yang berbeda. Saya tidak melihat konfigurasi Anda ada di mana pun tetapi tempat di mana 'bottleneck' logstash ada di filter. Bergantung pada berapa banyak transformasi yang Anda lakukan, hal itu dapat berdampak pada penggunaan memori proses Logstash.

Logstash sangat mirip lego. Anda bisa menggunakan bata 2x4 atau Anda bisa menggunakan dua batu bata 2x2 untuk menyelesaikan tugas yang sama. Kecuali dalam kasus logstash, sebenarnya lebih kuat untuk menggunakan batu bata yang lebih kecil daripada batu bata besar.

Beberapa saran umum yang biasanya kami berikan adalah:

• mengirimkan log secepat mungkin dari tepi Jika Anda dapat menggunakan transportasi jaringan murni alih-alih menulis ke disk, itu bagus tetapi tidak diperlukan. Logstash berbasis JVM dan yang memiliki implikasi baik dan buruk. Gunakan pengirim alternatif. Saya menulis yang berbasis python ( https://github.com/lusis/logstash-shipper ) tetapi saya menyarankan agar orang menggunakan Beaver sebagai gantinya ( https://github.com/josegonzalez/beaver ).

• buat log Anda dalam format yang membutuhkan pemfilteran sesedikit mungkin (format json atau optimal json-event) Ini tidak selalu mungkin. Saya menulis append log4j untuk melakukan ini ( https://github.com/lusis/zmq-appender ) dan akhirnya memecah tata letak pola menjadi repo sendiri ( https://github.com/lusis/log4j-jsonevent-layout ). Ini berarti saya tidak perlu melakukan filtering APAPUN di logstash untuk log tersebut. Saya hanya mengatur tipe pada input ke 'json-event'

Untuk apache, Anda dapat mencoba pendekatan ini: http://cookbook.logstash.net/recipes/apache-json-logs/

• memecah hal-hal menjadi beberapa komponen Dalam setiap pembicaraan yang saya lakukan tentang logstash, saya menggambarkannya sebagai pipa unix pada steroid. Anda dapat membuat pipa sepanjang atau sesingkat yang Anda suka. Anda skala logstash dengan mengalihkan tanggung jawab secara horizontal. Ini mungkin berarti membuat saluran pipa lebih lama tetapi kami tidak berbicara tentang apa pun yang relevan secara statistik dalam hal overhead latensi. Jika Anda memiliki kontrol lebih besar atas jaringan Anda (mis. BUKAN pada EC2), Anda dapat melakukan beberapa hal luar biasa dengan isolasi lalu lintas standar.

Perhatikan juga bahwa milis logstash SANGAT aktif sehingga Anda harus selalu mulai dari sana. Sanitasi dan gabungkan konfigurasi Anda karena itulah tempat terbaik untuk memulai.

Ada perusahaan (seperti Sonian) yang melakukan penskalaan ElasticSearch ke tingkat petabyte dan perusahaan (seperti Mailchimp dan Dreamhost) melakukan penskalaan Logstash ke tingkat yang gila juga. Itu bisa dilakukan.