Verwalten des Elasticsearch-Arbeitsspeichers und Beheben von Problemen

Da Elastic Cloud Lösungen wie Observability, Security und Search bereitstellt, haben wir den Nutzerkreis von Elastic Cloud über reine Betriebsteams hinaus erweitert und schließen nun auch Dateningenieure, Sicherheitsteams und Berater mit ein. Als Support-Vertreter von Elastic habe ich es genossen, mit einer Vielzahl von Nutzern und Anwendungsfällen in Kontakt zu treten.

Durch den größer gewordenen Nutzerkreis erreichen mich zunehmend Fragen zur Verwaltung der Ressourcenzuweisung, insbesondere zur Fehlerbehebung beim Zuweisungsstatus und zur Vermeidung der Auslösung von Sicherungen (Circuit Breakers). Das kann ich absolut nachvollziehen! Als ich mit Elasticsearch anfing, hatte ich die gleichen Fragen. Damals hatte ich zum ersten Mal mit dem Verwalten von Java-Heaps und Zeitreihen-Datenbank-Shards und mit der Skalierung meiner eigenen Infrastruktur zu tun.

Als ich zu Elastic kam, fand ich es großartig, dass wir neben der Dokumentation auch Blogs und Tutorials hatten, damit ich schnell einsteigen konnte. Im ersten Monat fiel es mir aber schwer, mein theoretisches Wissen und die Fehlermeldungen, die ich über meine Ticket-Queue reinbekam, vernünftig in Einklang zu bringen. Irgendwann begriff ich, wie andere Support-Engineers auch, dass viele der gemeldeten Fehler lediglich Symptome von Zuweisungsproblemen waren und dass man den Nutzer:innen mit so um die sieben Links schnell dabei helfen konnte, ihre Ressourcenzuweisung erfolgreich zu verwalten.

Aus meiner Sicht als Support-Mitarbeiter werde ich die wichtigsten Links zur Theorie des Zuweisungsmanagements durchgehen, die wir an Nutzer senden, die häufigsten Symptome aufzeigen, die wir beobachten, und erläutern, wohin wir Nutzer leiten, damit sie ihre Konfigurationen anpassen und Probleme mit der Ressourcenzuweisung beheben können.

2. Als Elasticsearch-Umgebungsvariable in der Docker-Compose-Datei:

3. Über unsere Elastic Cloud Hosted > Deployment > Edit view. Hinweis: Das Dropdown-Menü weist physischen Speicher zu, und ungefähr die Hälfte wird dem Heap zugewiesen.

Wenn Sie derzeit Probleme mit der Performance Ihres Clusters haben, liegt es wahrscheinlich an den üblichen Verdächtigen:

• Konfigurationsprobleme: Unterdimensionierte Master-Knoten, keine ILM-Richtlinie
• Volumen induziert: Hohe Anfragegeschwindigkeit/-last, überlappende teure Abfragen/Schreibvorgänge

Und an: _cluster/health.

Wenn Shards einen Wert > 0 außerhalb von active_shards oder active_primary_shards melden, haben Sie eine Ursache für Performance-Probleme ausgemacht.

Wenn hier ein Problem gemeldet wird, lautet die Meldung meist unassigned_shards > 0. Handelt es sich bei diesen Shards um primäre Shards, meldet Ihr Cluster denStatus „rot“, handelt es sich hingegen nur um Replikate, meldet er den Status „gelb“. (Daher ist die Festlegung von Replikaten für Indizes wichtig – so kann der Cluster bei einem Problem wiederhergestellt werden, anstatt Datenverlust zu erleiden.) Nehmen wir an, wir haben denStatus „gelb“ mit einem einzelnen nicht zugewiesenen Shard. Zur Untersuchung würden wir mit _cat/shards prüfen, welcher Index-Shard Probleme verursacht.

Dies betrifft also unsere Nicht-System-Indexprotokolle, die einen nicht zugewiesenen Replikat-Shard haben. Sehen wir uns an, was die Probleme verursacht, indem wir _cluster/allocation/explain ausführen. (Profi-Tipp: Genau so gehen wir vor, wenn wir uns anden Support wenden.)

GET _cluster/allocation/explain?pretty&filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*

Diese Fehlermeldung verweist auf data_hot, das Teil einer Verwaltung des Indexlebenszyklus (ILM)-Richtlinie ist und darauf hinweist, dass unsere ILM-Richtlinie mit unseren aktuellen Indexeinstellungen nicht übereinstimmt. In diesem Fall liegt die Ursache dieses Fehlers darin, dass eine heiß-warm-ILM-Richtlinie eingerichtet wurde, ohne dass bestimmte heiß-warm-Knoten vorhanden sind. (Ich musste garantieren, dass etwas fehlschlägt, daher zeige ich hier absichtlich Fehlerbeispiele. Weitere Informationen finden Sie in diesem Beispiel-Fehlerbehebungsvideo zur Lösung.)

Wenn Sie diesen Befehl ausführen, obwohl keine nicht zugewiesenen Shards vorhanden sind, erhalten Sie einen 400-Fehler mit der Meldung keine unzugewiesenen Shards gefunden, die erklärt werden können, da nichts zu berichten ist.Wenn eine nicht-logische Ursache vorliegt (z. B. ein temporärer Netzwerkfehler wie Node hat Cluster während der Zuteilung verlassen), können Sie das praktische _cluster/reroute von Elastic verwenden.

Diese Anfrage ohne Anpassungen startet einen asynchronen Hintergrundprozess, der versucht, alle aktuellen state:UNASSIGNED Shards zuzuweisen. (Seien Sie nicht wie ich und warten Sie, bis der Vorgang abgeschlossen ist, bevor Sie den Entwickler kontaktieren, denn ich dachte, es würde sofort passieren und zufällig eskalieren, gerade rechtzeitig, damit sie sagen können, dass nichts mehr falsch ist.) Weitere Informationen finden Sie in diesem Fehlerbehebungsvideo zur Überwachung des Zuteilungsstatus.

Um dies zu untersuchen, sehen Sie sich Ihren heap.percent an, entweder durch Aufrufen von _cat/nodes:

Oder falls Sie es zuvor aktiviert haben, navigieren Sie zu Kibana > Stack Monitoring.

Wenn Sie sich vergewissert haben, dass die für die Arbeitsspeicher-Sicherungen festgelegten Werte erreicht wurden, sollten Sie darüber nachdenken, die Größe Ihres Heaps vorübergehend zu erhöhen, um sich eine Atempause für Ihre Untersuchungen zu verschaffen. Bei der Untersuchung der Ursache sollten Sie Ihre Audit-Logging, Slow-Logging, Cluster-Logs oder die elasticsearch.log auf die vorangegangenen aufeinanderfolgenden Ereignisse durchsuchen. Sie suchen nach:

• aufwändigen Abfragen, insbesondere:
  • Aggregationen mit hohen Bucket-Zahlen
    • Ich kam mir so dumm vor, als mir dämmerte, dass Suchen vorübergehend einen bestimmten Teil des Heaps zuweisen,bevor sie die Abfrage auf der Grundlage der Suchgröße oder der Bucket-Dimensionen ausführen, sodass eine Einstellung von 10.000.000 meinem Ops-Team wirklich Kopfzerbrechen bereitet hat.
  • nicht-optimierte Mappings
    • Außerdem kam ich mir dumm vor, weil ich dachte, dass es beim hierarchischen Reporting einfacher wäre zu suchen, als wenn die Daten alle „geflattet“ wären (ist es nicht!).
• Volumen/Tempo der Anfrage: Normalerweise Batch- oder asynchrone Abfragen

Oder Sie können es aus _nodes/stats:

Wo:

Ein mögliches Symptom dafür ist eine hohe Frequenz und lange Dauer von Garbage-Collector-Ereignissen (gc-Ereignissen) in elasticsearch.log:

Wenn sich dies bestätigt, müssen Sie entweder die Skalierung Ihres Clusters oder die Verringerung der Anforderungen an den Cluster in Betracht ziehen. Dabei sollten Sie Folgendes untersuchen/erwägen:

• Erhöhung der Heap-Ressourcen (Heap/Knoten; Anzahl Knoten)
• Shards reduzieren (unnötige/alte Daten löschen; ILM verwenden, um Daten in Warm-/Kalt-Speicher auszulagern, und so die Shards zu verkleinern; Replikate für Daten deaktivieren, deren Verlust unerheblich ist)

Ursprünglich veröffentlicht am 27. April 2021; aktualisiert am 5. November 2024.

Die Entscheidung über die Veröffentlichung der in diesem Blogeintrag beschriebenen Leistungsmerkmale und Features sowie deren Zeitpunkt liegt allein bei Elastic. Es ist möglich, dass noch nicht verfügbare Leistungsmerkmale oder Features nicht rechtzeitig oder überhaupt nicht veröffentlicht werden.