Leitfaden zum Upgrade auf Logstash 2.2

By
Andrew Cholakian

Hallo Logstashers! In diesem Post gehen wir auf Erwägungen zum Upgrade auf Logstash 2.2.0. ein. Konkret geht es um die Vermeidung von Situationen, bei denen ein neues Programmverhalten (und auch ein Wenig das in Kürze behobene Fehlverhalten des Output-Plugins von Elasticsearch) eine unerwartet große Anzahl an Datei-Handles benötigt. Außerdem geht der Post auf einige neue Einstellungsmöglichkeiten in 2.2.0 ein. Um den Benutzern beim Upgrade auf 2.2.0 zu helfen, haben wir hier außerdem einen neuen Bereich mit Dokumentation bereitgestellt.

Die gute Nachricht: Logstash 2.2 bringt eine Reihe bedeutender Leistungssteigerungen! Die Kehrseite der Medaille jedoch ist: Eine der vorgenommenen Änderungen an den Voreinstellungen in Logstash kann bei einigen Konfigurationen zu Problemen führen. Zum Beispiel wurde uns bekannt, dass Logstash-Berichte viel mehr Datei-Handles als in der vorherigen Version benötigen.

Lasst uns näher auf diese Änderungen eingehen.

Worker Units

Logstash 2.2 kennt zwei Typen von Workern: Pipeline-Worker (vormals Filter-Worker) und Output-Worker. In früheren Logstash-Versionen liefen die Filter und Outputs in getrennten Threads. Bei 2.2 haben wir das Threading-Modell vereinheitlicht und die Threads von Filter- und Output-Workern in einem gemeinsamen „Pipeline“-Worker-Thread zusammengeführt. Dadurch haben wir die Leistung bedeutend gesteigert. Das Konzept des Output-Workers bleibt erhalten, doch anstatt direkt in einen Thread zu mappen, erfolgt das Mapping in einen Pool verfügbarer Output-Objekte. Währen der Ausführung greifen die Pipeline-Worker auf diese Objekte zu und geben sie anschließend wieder zurück.

Ihr werdet bemerken, dass ihr -w höher als früher einstellen müsst und tatsächlich kann Logstash insgesamt mehr Threads benötigen als zuvor. Das ist so allerdings beabsichtigt! Ihr werdet bemerken, dass ihr mehr Threads habt, die jedoch weniger Arbeit verrichten. Natürlich kann eine beachtliche Zahl von ihnen inaktiv im I/O-Zustand „Wait“ verharren, doch verrichten sie ihre Arbeit jetzt weitaus effizienter bei weniger Kontext-Switching. Zum Verändern der Einstellung -w erhöht ihr diese einfach, durchaus auf ein Vielfaches der Zahl der Cores auf eurem System (bedenkt, dass diese Threads oft inaktiv sind), bis ihr beobachtet, dass der Durchsatz sinkt. -w ist so voreingestellt, dass der Wert mit der Zahl der Cores des Systems übereinstimmt.

Events im Batch

Es gibt zudem eine neue Batch-Größen-Einstellung -b, die ihr auf ähnliche Weise einstellen könnt. Bitte lest unseren vorangegangenen Post, der diese Option detaillierter erklärt. Diese Batch-Größe entspricht nun auch der voreingestellten Flush-Größe für den Output von Elasticsearch. Die Option flush_size verändert nun nur noch die maximale Flush-Größe und gibt nicht mehr die Mindest-Flush-Größe vor.

Neue Pipeline und Outputs

Bei unseren Performance-Tests haben wir festgestellt, dass die Erhöhung der Zahl der Output-Worker, die im Gleichtakt mit den Pipeline-Workern bleiben, uns beachtliche Zugewinne bei der Performance eingebracht hat. Doch für unseren Elasticsearch-Output ist dies mit einem unerwünschten Programmverhalten verbunden, das bislang nicht zutage getreten war. Wenn ihr nämlich mehrere Output-Worker von Elasticsearch verwendet, werden diese nicht denselben Backend-Connection-Pool teilen. Das bedeutet, dass ihr bei 5 Backend-ES-Instanzen und 5 Workern auf bis zu 5*5=25 Verbindungen kommt! Wenn ihr 40 ES-Knoten habt, wird der Effekt noch verstärkt!

Wir verstehen, dass die gegenwärtige Situation in manchen Fällen nicht ideal ist. Die Lösung ist nicht das Verhalten von Logstash-Core zu verändern, sondern den Elasticsearch-Output zu veranlassen, Verbindungen im neuen Pipelinemodell verantwortungsvoll zu verwenden. Wir planen eine neue Version in der Serie 2.2, bei der dieses Problem behoben ist. Gegenwärtig arbeiten wir an einer Fehlerbehebung für dieses Problem, die lediglich einen Plugin-Upgrade notwendig machen wird. Doch bis dahin solltet ihr die Zahl der ES-Output-Worker eher niedrig halten. Um das Problem in 2.2 zu umgehen, stellt eine ausdrücklich niedrige Worker-Anzahl ein: Versucht es mit 1 oder 2 Workern.

Feedback

Ich hoffe, ich konnte ein paar Aspekte rund um unsere neue Pipeline-Architektur und den Upgrade auf 2.2 klären. Wir freuen uns auf eure Rückmeldungen! Ihr erreicht uns stets auf Twitter (@elastic), über unser Forum oder ihr könnt bei allen Problemen auf GitHub Issues melden.