Scaling Logstash (mit Redis / Elasticsearch)

Über einen Cluster von über 12 Centos 5.8-Servern habe ich Logstash mithilfe des nativen Logstash-Versenders bereitgestellt, der /var/log/*/*.logan einen zentralen Logstash-Server zurücksendet.

Wir haben versucht, rsyslogd als Versender zu verwenden, aber aufgrund eines Fehlers im ImFile-Modul von rsyslogd stauten sich die Protokolle im Speicher auf, wenn die Gegenstelle nicht antwortete.

Wir verwenden derzeit Redis als Transportmechanismus, daher wird in logstash01 Redis lokal ausgeführt und für diese Protokolle an die IP des VLAN gebunden.

Logstash-shipper sendet also logstash01 an redis. logstash01 sendet in einem separaten Prozess an Elasticsearch.

Hier ist was wir sehen. Elasticsearch hat 141 blockierte Threads. Wenn Sie das übergeordnete Element "elasticsearch" spannen, wird Folgendes angezeigt:

futex(0x7f4ccd1939d0, FUTEX_WAIT, 26374, NULL

Hier ist der Jstack von elasticsearch

Hier ist der Jstack von Logstash

Also .. Letzte Nacht sind einige der Webserver (deren Logs von Logstash beschnitten werden) durchgedreht, mit einer durchschnittlichen Last von über 500.

Auf logstash01 gibt es das

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

So OOM-Killer getötet redis-Server, der dann im Speicher auf den Servern gemeint Protokolle angehäuft , die Sachen Versand wurden .. Welche irgendwie bedeuten , dass Apache seine Schlüpfer in einem Twist bekommt. (Ehrlich gesagt, ich bin mir nicht sicher, wie, ich gehe einfach davon aus, dass es das Protokoll verfolgt) ..

Dies ist meine Theorie, wie sich die Ereignisse entwickelten:

1. Wir hatten eine Verkehrsspitze.
2. Eine immense Menge von Protokollen wurde generiert.
3. Diese häufen sich in Redis, da logstash / elasticsearch nur 300-400 neue Ereignisse pro Sekunde verarbeiten kann.
4. Redis war bis zu dem Punkt voll, an dem der OOM-Killer ihn sinnlos abgeschlachtet hatte.
5. Redis akzeptiert keine neuen Artikel mehr.
6. Auf der Seite der Remote-Hosts häufen sich jetzt Objekte an.
7. Alles wird verrückt . Apache akzeptiert keine Anfragen mehr. (Warum?).

Fragen sind diese:

8. Warum wird Apache verrückt, wenn es nur etwas gibt, das sein Protokoll verfolgt? Ist es das, was Apache am Schreiben hindert?

9. Gibt es einen vernünftigen Weg, um die Elasticsuche schneller / besser / belastbarer zu machen?

10. Gibt es eine vernünftige Möglichkeit, Redis belastbar zu machen und nicht zu sterben, weil man OOM hat?

11. Gibt es einen grundlegenden Fehler in der Art und Weise, wie ich alles eingerichtet habe, oder hat jeder dieses Problem?

- BEARBEITEN -

Einige Spezifikationen für @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

Ihr Beitrag beschreibt nicht viel in Bezug auf Spezifikationen (Speicher auf dem LS-Indexer, Protokollvolumen oder vieles mehr), aber ich werde versuchen, Ihre Fragen so gut wie möglich zu beantworten. Haftungsausschluss: Ich bin einer der Logstash-Entwickler -

1. Apache Going Nuts war wahrscheinlich eine Nebenwirkung des Logstash-Prozesses. Ich würde das fürs Erste beiseite legen.

2. Die vernünftige Möglichkeit, ES f / b / s zu erstellen, besteht darin, weitere ES-Knoten hinzuzufügen. So einfach ist das im Ernst. Sie erkennen sich je nach Netzwerktopologie sogar gegenseitig automatisch. Nach 17 Jahren in dieser Branche war die horizontale Skalierung noch nie so einfach wie bei ElasticSearch.

3. Verwenden Sie für f / b / s-Redis kein Redis-Clustering. Neuere Versionen von Logstash können den Lastausgleich intern durchführen. Die Redis-Ausgabe unterstützt eine Liste von Redis-Hosts in der Plugin-Konfiguration, und die Unterstützung wird bald auch auf der Eingabeseite hinzugefügt, um dem zu entsprechen. In der Zwischenzeit können Sie mehrere Redis-Eingabedefinitionen auf der Indexer- / Verbraucherseite verwenden.

4. Ich kann das nicht ohne zu sagen beantworten, dass es so klingt, als würden Sie versuchen, mit einem einzelnen (möglicherweise unterlasteten Host) zu viel zu tun.

Jeder gute Skalierungsprozess beginnt mit der Aufteilung der zusammengestellten Komponenten in verschiedene Systeme. Ich sehe deine Configs nirgendwo anders als an den Stellen, an denen Logstash-Engpässe in Filtern sind. Abhängig von der Anzahl der durchgeführten Transformationen kann sich dies auf die Speichernutzung von Logstash-Prozessen auswirken.

Logstash funktioniert ähnlich wie Legos. Sie können entweder einen 2x4-Stein oder zwei 2x2-Steine ​​verwenden, um dieselbe Aufgabe zu erfüllen. Außer im Fall von Logstash ist es tatsächlich robuster, kleinere Steine ​​als einen einzelnen großen Stein zu verwenden.

Einige allgemeine Ratschläge, die wir normalerweise geben, sind:

• Versenden Sie Protokolle so schnell wie möglich von der Kante aus. Wenn Sie den reinen Netzwerktransport verwenden können, anstatt auf die Festplatte zu schreiben, ist dies nett, aber nicht erforderlich. Logstash ist JVM-basiert und das hat gute und schlechte Auswirkungen. Verwenden Sie einen alternativen Versender. Ich habe eine Python-basierte Version geschrieben ( https://github.com/lusis/logstash-shipper ), aber ich würde vorschlagen, dass die Leute stattdessen Beaver verwenden ( https://github.com/josegonzalez/beaver ).

• Generieren Sie Ihre Protokolle in einem Format, das so wenig Filterung wie möglich erfordert (JSON oder optimal JSON-Ereignisformat). Dies ist nicht immer möglich. Ich habe dazu einen log4j-Appender geschrieben ( https://github.com/lusis/zmq-appender ) und schließlich das Pattern-Layout in ein eigenes Repo aufgeteilt ( https://github.com/lusis/log4j-jsonevent-layout) ). Dies bedeutet, dass ich für diese Protokolle KEINE Filterung im Logstash durchführen muss. Ich habe den Typ bei der Eingabe auf 'json-event' gesetzt

Für Apache können Sie diesen Ansatz ausprobieren: http://cookbook.logstash.net/recipes/apache-json-logs/

• Dinge in mehrere Komponenten aufteilen In jedem Vortrag, den ich über Logstash geführt habe, beschreibe ich es als eine Unix-Pipe für Steroide. Sie können die Pipeline beliebig lang oder kurz machen. Sie skalieren den Logstash, indem Sie die Zuständigkeiten horizontal verschieben. Dies kann bedeuten, dass die Pipeline länger wird, wir sprechen jedoch nicht über statistisch relevante Aspekte des Latenzaufwands. Wenn Sie mehr Kontrolle über Ihr Netzwerk haben (z. B. NICHT bei EC2), können Sie einige erstaunliche Dinge mit der Standard-Verkehrsisolierung tun.

Beachten Sie auch, dass die Logstash-Mailingliste SEHR aktiv ist, sodass Sie immer dort beginnen sollten. Bereinigen und erstellen Sie Ihre Konfigurationsdateien, da dies der beste Ausgangspunkt ist.

Es gibt Firmen (wie Sonian), die ElasticSearch auf Petabyte-Level skalieren, und Firmen (wie Mailchimp und Dreamhost), die Logstash ebenfalls auf Wahnsinns-Level skalieren. Es kann getan werden.