Skalowanie Logstash (z redis / elasticsearch)

W klastrze ponad 12 centów serwerów 5.8 wdrożyłem logstash przy użyciu natywnego nadawcy logstash, który odsyła z /var/log/*/*.logpowrotem do centralnego serwera logstash.

Próbowaliśmy użyć rsyslogd jako nadawcy, ale z powodu błędu w module ImFile rsyslogd, jeśli zdalny koniec nie odpowiedział, dzienniki gromadziłyby się w pamięci.

Obecnie używamy Redis jako mechanizmu transportu, więc logstash01 ma redis uruchomione lokalnie, powiązane z IP dla VLAN dla tych dzienników.

Więc logstash-shipper wysyła do redis na logstash01. logstash01 wysyła do Elasticsearch działającego w osobnym procesie.

Oto, co widzimy. Elasticsearch ma 141 zablokowanych wątków. Śledzenie elementu nadrzędnego elasticsearch pokazuje:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Oto jstack z elasticsearch

Oto jstack z logstash

Więc .. Wczoraj wieczorem niektóre serwery (których logi są wyrzucane przez logstash) oszalały, ze średnimi obciążeniami ponad 500.

Na logstash01 jest to

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

Więc OOM-killer zabił serwer redis, co oznaczało, że logi piętrzyły się w pamięci na serwerach, które wysyłały różne rzeczy. Co w jakiś sposób oznacza, że ​​Apache robi swoje majtki. (Szczerze mówiąc, nie jestem pewien jak, po prostu zakładam, że śledzi dziennik) ..

Oto moja teoria tego, jak przebiegały wydarzenia:

1. Mieliśmy skok ruchu.
2. Wygenerowano ogromną liczbę dzienników.
3. Są one gromadzone w Redis, ponieważ logstash / elasticsearch wydaje się być w stanie obsłużyć 300-400 nowych zdarzeń / sekundę.
4. Redis wypełnił się całkowicie do tego stopnia, że ​​zabójca OOM zabił go bezsensownie.
5. Redis przestaje akceptować nowe przedmioty.
6. Przedmioty zaczynają się teraz gromadzić po stronie zdalnego hosta.
7. Wszystko idzie orzechy . Apache przestaje akceptować żądania. (Dlaczego?).

Pytania są następujące:

8. Dlaczego Apache wariuje, jeśli jest coś, co dostosowuje jego log. Czy to coś, co ogarnia go, blokuje apaczowi pisanie?

9. Czy istnieje rozsądny sposób na szybsze / lepsze / elastyczne wyszukiwanie elastyczne?

10. Czy istnieje rozsądny sposób, aby uczynić Redis odpornym i nie umrzeć z powodu bycia OOM

11. Czy jest jakaś podstawowa wada w sposobie konfiguracji? Czy wszyscy mają ten problem?

-- EDYTOWAĆ --

Niektóre specyfikacje @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

Twój post nie opisuje zbyt wiele specyfikacji (pamięć w indeksatorze LS, wolumin dziennika lub wiele innych), ale postaram się odpowiedzieć na twoje pytania najlepiej, jak potrafię. Oświadczenie: Jestem jednym z twórców logstash -

1. Oszalały Apache był prawdopodobnie efektem ubocznym procesu logstash działającego w górę. Na razie odłożyłem to na bok.

2. Dobrym sposobem na zrobienie ES f / b / s jest dodanie kolejnych węzłów ES. To naprawdę takie proste. Nawet automatycznie się odkrywają w zależności od topologii sieci. Po 17 latach w tej branży nigdy nie widziałem, żeby cokolwiek skalowało się w poziomie tak łatwo jak ElasticSearch.

3. Aby f / b / s Redis, nie używaj żadnego klastrowania redis. Nowsze wersje Logstash mogą wewnętrznie równoważić obciążenie w Redis. Wyjście Redis obsługuje listę hostów Redis w konfiguracji wtyczki, a obsługa zostanie wkrótce dodana po stronie wejściowej, aby ją dopasować. Tymczasem możesz użyć wielu definicji wejściowych Redis po stronie indeksatora / konsumenta.

4. Nie potrafię odpowiedzieć na to, mówiąc, że brzmi to tak, jakbyś próbował zrobić wiele z jednym (być może słabym hostem).

Każdy dobry proces skalowania rozpoczyna się od rozbicia kolokowanych komponentów na odrębne systemy. Nie widzę twoich konfiguracji nigdzie indziej niż w miejscach, w których „wąskie gardła” logstash są w filtrach. W zależności od liczby wykonanych transformacji może to mieć wpływ na wykorzystanie pamięci przez procesy Logstash.

Logstash działa podobnie jak legos. Możesz użyć klocka 2x4 lub dwóch klocków 2x2, aby wykonać to samo zadanie. Z wyjątkiem przypadku logstash, użycie mocniejszych cegieł jest mniejsze, niż jednej dużej cegły.

Niektóre ogólne porady, które zwykle udzielamy, to:

• wysyłaj dzienniki tak szybko, jak to możliwe od brzegu Jeśli możesz używać czystego transportu sieciowego zamiast zapisywać na dysku, to dobrze, ale nie jest wymagane. Logstash jest oparty na JVM i ma dobre i złe konsekwencje. Użyj alternatywnego nadawcy. Napisałem wersję opartą na pythonie ( https://github.com/lusis/logstash-shipper ), ale sugerowałbym, aby ludzie używali Beavera ( https://github.com/josegonzalez/beaver ).

• generuj logi w formacie, który wymaga jak najmniejszego filtrowania (format json lub optymalnie json-event) Nie zawsze jest to możliwe. Napisałem do tego log4j appender ( https://github.com/lusis/zmq-appender ) i ostatecznie złamałem układ wzorca w swoim własnym repozytorium ( https://github.com/lusis/log4j-jsonevent-layout ). Oznacza to, że nie muszę wykonywać ŻADNEGO filtrowania w logstash dla tych dzienników. Właśnie ustawiłem typ na wejściu na „json-event”

W przypadku apache możesz wypróbować to podejście: http://cookbook.logstash.net/recipes/apache-json-logs/

• dzielę rzeczy na wiele składników W każdym przemówieniu na temat logstash opisuję to jako rurkę unix na sterydach. Możesz zrobić rurociąg tak długo lub tak krótko, jak chcesz. Skalujesz logstash, przesuwając obowiązki w poziomie. Może to oznaczać wydłużenie rurociągu, ale nie mówimy o niczym istotnym statystycznie pod względem narzutu związanego z opóźnieniami. Jeśli masz większą kontrolę nad siecią (tj. NIE w EC2), możesz zrobić niesamowite rzeczy ze standardową izolacją ruchu.

Pamiętaj również, że lista mailingowa logstash jest BARDZO aktywna, więc zawsze powinieneś zacząć od niej. Odkażaj i konfiguruj konfiguracje, ponieważ to najlepsze miejsce na rozpoczęcie.

Są firmy (takie jak Sonian) skalujące ElasticSearch do poziomów petabajtów oraz firmy (takie jak Mailchimp i Dreamhost) skalujące Logstash do szalonych poziomów. To może być zrobione.