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/*/*.log
powrotem 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
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:
- Mieliśmy skok ruchu.
- Wygenerowano ogromną liczbę dzienników.
- Są one gromadzone w Redis, ponieważ logstash / elasticsearch wydaje się być w stanie obsłużyć 300-400 nowych zdarzeń / sekundę.
- Redis wypełnił się całkowicie do tego stopnia, że zabójca OOM zabił go bezsensownie.
- Redis przestaje akceptować nowe przedmioty.
- Przedmioty zaczynają się teraz gromadzić po stronie zdalnego hosta.
- Wszystko idzie orzechy . Apache przestaje akceptować żądania. (Dlaczego?).
Pytania są następujące:
Dlaczego Apache wariuje, jeśli jest coś, co dostosowuje jego log. Czy to coś, co ogarnia go, blokuje apaczowi pisanie?
Czy istnieje rozsądny sposób na szybsze / lepsze / elastyczne wyszukiwanie elastyczne?
Czy istnieje rozsądny sposób, aby uczynić Redis odpornym i nie umrzeć z powodu bycia OOM
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
źródło
Odpowiedzi:
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 -
Oszalały Apache był prawdopodobnie efektem ubocznym procesu logstash działającego w górę. Na razie odłożyłem to na bok.
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.
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.
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/
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.
źródło