Logstash'i Ölçeklendirme (redis / elasticsearch ile)

12'den fazla centos 5.8 sunucusundan oluşan bir kümede, logstash'ı /var/log/*/*.logmerkezi bir logstash sunucusuna geri gönderen yerel logstash göndericisini kullanarak dağıttım.

Gönderici olarak rsyslogd kullanmayı denedik, ancak rsyslogd'ın ImFile modülündeki bir hata nedeniyle, uzak uç cevap vermezse, günlükler bellekte birikir.

Şu anda taşıma mekanizması olarak Redis kullanıyoruz, bu nedenle logstash01 yerel olarak çalışan redislere sahip ve bu günlükler için VLAN için IP'ye bağlı.

Yani logstash-nakliyeci logstash01'deki yeniden gönderime gönderir. logstash01, ayrı bir işlemde çalışan Elasticsearch'e gönderir.

İşte gördüğümüz şey. Elasticsearch adlı kullanıcı 141 adet konuya sahip. Elasticsearch üst öğesinin izlenmesi şunları gösterir:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

İşte elasticsearch'ten jstack

İşte logstash'ın jstack'ı

Dün gece, (günlükleri logtastas tarafından kuyruklanan) bazı web sunucuları kuruydu ve yük ortalamaları 500'ün üzerinde.

Logstash01 üzerinde bu var

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

OOM katili sonra geliyordu günlükleri .. şeyler nakliye Hangi edildi sunucularında bellekte yığılı Redis-sunucu, öldürülen Yani nasılsa apache bir büküm kendi kısa pantolon aldığını demektir. (Açıkçası, nasıl olduğundan emin değilim, sadece kütüğü izlediğini varsayıyorum) ..

Olaylarımın nasıl geliştiğine dair teorim budur:

1. Trafik ani yükseldik.
2. Çok büyük miktarda günlük oluşturuldu.
3. Bunlar, logstash / elasticsearch'ün sadece 300-400 yeni olayla başa çıkabildiği için Redis'te birikti.
4. Redis tamamen OOM-katilinin anlamsızca katledildiği noktaya kadar dolmuştu.
5. Redis, yeni öğeleri kabul etmeyi durdurur.
6. Öğeler artık uzak ana bilgisayarlar tarafında birikmeye başlıyor.
7. Herşey deliriyor . Apache istekleri kabul etmeyi durdurur. (Neden?).

Sorular:

8. Günlüğünde bir şey varsa neden apache çıldırır? Onu takip eden şey apache'nin yazmasını engelliyor mu?

9. Elastics aramasını daha hızlı / daha iyi / esnek hale getirmenin akılcı bir yolu var mı?

10. Redis'i dayanıklı hale getirmenin ve OOM olduğu için ölmemenin akılcı bir yolu var mı?

11. Her şeyi kurma şeklimde temel bir kusur var mı, yoksa herkesin bu sorunu var mı?

-- DÜZENLE --

@Lusis için bazı özellikler.

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

Gönderiniz özelliklerde çok fazla tanımlamıyor (LS indeksleyicisindeki bellek, günlük hacmi veya daha fazlası) ama önce sorularınızı en iyi şekilde cevaplamaya çalışacağım. Feragatname: Logstash geliştiricilerinden biriyim -

1. Apache'nin kuruyemişleri muhtemelen logstash sürecinin bir yan etkisiydi. Şimdilik bir kenara koyardım.

2. ES f / b / s yapmanın akıllı yolu, daha fazla ES düğümü eklemektir. Cidden bu kadar kolay. Ağ topolojisine bağlı olarak birbirlerini otomatik olarak keşfederler. Bu sektörde 17 yıl geçtikten sonra, yatay olarak Elastik Arama kadar kolay bir şey görmedim.

3. F / b / s Redis için herhangi bir redis kümelemesi kullanmayın. Logstash'ın daha yeni sürümleri dahili olarak Redis yük dengeleme yapabilir. Redis çıkışı, eklenti yapılandırmasındaki Redis ana bilgisayarlarının bir listesini destekler ve bununla eşleşmek için giriş tarafına da destek eklemek üzeredir. Arada, dizinleyici / tüketici tarafında birden çok Redis giriş tanımı kullanabilirsiniz.

4. Bunu tek bir (muhtemelen güçsüz bir ev sahibi) ile çok şey yapmaya çalıştığınızı söyleyerek ötesine cevap veremem.

Herhangi bir iyi ölçeklendirme işlemi, kollokasyona tabi bileşenlerin farklı sistemlere bölünmesiyle başlar. Yapılandırmalarınızın hiçbir yerde gisttiğini görmüyorum, ancak logstash 'darboğazlarının' filtrelerde olduğu yerler. Kaç dönüşüm yaptığınıza bağlı olarak Logstash işlemlerinin bellek kullanımı üzerinde bir etkisi olabilir.

Logstash legolara çok benzer. Aynı görevi gerçekleştirmek için 2x4 tuğla veya iki 2x2 tuğla kullanabilirsiniz. Logstash hariç, aslında tek bir büyük tuğladan daha küçük tuğla kullanmak daha sağlamdır.

Normalde verdiğimiz bazı genel tavsiyeler:

• günlükleri kenardan olabildiğince hızlı bir şekilde gönderin Diske yazmak yerine saf ağ aktarımını kullanabiliyorsanız, bu güzel ancak gerekli değildir. Logstash JVM tabanlıdır ve bunun iyi ve kötü sonuçları vardır. Alternatif bir nakliyeci kullanın. Ben bir python tabanlı bir yazdım ( https://github.com/lusis/logstash-shipper ) ama millet bunun yerine Beaver kullanın öneririz ( https://github.com/josegonzalez/beaver ).

• günlüklerinizi olabildiğince az filtreleme gerektiren bir biçimde oluşturun (json veya en iyi şekilde json-event biçimi) Bu her zaman mümkün değildir. Bunu yapmak için bir log4j ekleyicisi yazdım ( https://github.com/lusis/zmq-appender ) ve sonunda desen düzenini kendi repo'suna ( https://github.com/lusis/log4j-jsonevent-layout ) çıkardım. ). Bu, bu günlükler için günlükte HERHANGİ bir filtreleme yapmak zorunda olmadığım anlamına gelir. Girişteki türü sadece 'json-event' olarak ayarladım

Apache için bu yaklaşımı deneyebilirsiniz: http://cookbook.logstash.net/recipes/apache-json-logs/

• logstash hakkında yaptığım her konuşmada, steroidler üzerinde bir unix borusu olarak tanımlarım. Boru hattını istediğiniz kadar uzun veya kısa yapabilirsiniz. Sorumlulukları yatay olarak kaydırarak logstash'ı ölçeklendirirsiniz. Bu, boru hattını daha uzun yapmak anlamına gelebilir, ancak gecikme yükü açısından istatistiksel olarak alakalı bir şeyden bahsetmiyoruz. Ağınız üzerinde daha fazla kontrole sahipseniz (yani EC2'de DEĞİL), standart trafik izolasyonu ile şaşırtıcı şeyler yapabilirsiniz.

Ayrıca logstash posta listesinin ÇOK aktif olduğunu unutmayın, bu yüzden her zaman orada başlamalısınız. Başlangıç ​​için en iyi yer olduğu için yapılandırmalarınızı sterilize edin ve ısıtın.

ElastikSearch'i petabayt düzeylerine ölçekleyen şirketler (Mailchimp ve Dreamhost gibi) Logstash'ı deli düzeylere ölçekleyen şirketler var. Yapılabilir.