Über einen Cluster von über 12 Centos 5.8-Servern habe ich Logstash mithilfe des nativen Logstash-Versenders bereitgestellt, der /var/log/*/*.log
an 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:
- Wir hatten eine Verkehrsspitze.
- Eine immense Menge von Protokollen wurde generiert.
- Diese häufen sich in Redis, da logstash / elasticsearch nur 300-400 neue Ereignisse pro Sekunde verarbeiten kann.
- Redis war bis zu dem Punkt voll, an dem der OOM-Killer ihn sinnlos abgeschlachtet hatte.
- Redis akzeptiert keine neuen Artikel mehr.
- Auf der Seite der Remote-Hosts häufen sich jetzt Objekte an.
- Alles wird verrückt . Apache akzeptiert keine Anfragen mehr. (Warum?).
Fragen sind diese:
Warum wird Apache verrückt, wenn es nur etwas gibt, das sein Protokoll verfolgt? Ist es das, was Apache am Schreiben hindert?
Gibt es einen vernünftigen Weg, um die Elasticsuche schneller / besser / belastbarer zu machen?
Gibt es eine vernünftige Möglichkeit, Redis belastbar zu machen und nicht zu sterben, weil man OOM hat?
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
quelle
Antworten:
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 -
Apache Going Nuts war wahrscheinlich eine Nebenwirkung des Logstash-Prozesses. Ich würde das fürs Erste beiseite legen.
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.
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.
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/
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.
quelle