So lösen Sie das Problem langsamer Elasticsearch-Abfragen für eine bessere Benutzererfahrung

Von Philipp Kahr

Wichtiger Hinweis für Elasticsearch Service-Benutzer: Derzeit sind die in diesem Artikel beschriebenen Kibana-Setup-Änderungen auf die Cloud Console beschränkt und können nicht ohne manuelles Eingreifen unseres Support-Teams konfiguriert werden. Unser Technikteam arbeitet hart daran, die Einschränkungen dieser Einstellungen aufzuheben, damit alle unsere Benutzer internes APM aktivieren können. Lokale Bereitstellungen sind von diesem Problem nicht betroffen.

Das Erkennen und Beheben von Abfragen ist eine wichtige Fähigkeit, die jeder beherrschen muss, der Elasticsearch als Suchmaschine verwendet. Ob E-Commerce, Observability oder eine arbeitsplatzorientierte Suchlösung: Langsames Elasticsearch kann sich negativ auf die Benutzererfahrung auswirken.

Um langsame Elasticsearch-Abfragen zu lokalisieren, können Sie das langsame , das Abfragen erfasst, die bei einem bestimmten Schwellenwert ausgeführt werden. Den richtigen Schwellenwert für die langsame Protokollierung festzulegen, ist eine Herausforderung für sich. Beispielsweise kann eine Abfrage, die 500 Millisekunden dauert, bei voller Auslastung akzeptabel sein, bei geringer Auslastung ist dieselbe Abfrage jedoch möglicherweise nicht akzeptabel. Das langsame Protokoll unterscheidet nicht und protokolliert alles über 500 ms. Das langsame Protokoll erledigt seine Aufgabe gut und Sie können anhand von Schwellenwerten unterschiedliche Granularitätsebenen erfassen. Stattdessen kann die Ablaufverfolgung alle Abfragen untersuchen und feststellen, wie viele innerhalb eines bestimmten Schwellenwerts liegen.

Die Überwachung der Anwendungsleistung (APM) ist nicht mehr auf Ihre Anwendung beschränkt. Mithilfe der Instrumentierung in Elasticsearch können wir Elasticsearch jetzt als vollwertigen Dienst hinzufügen, anstatt als Abhängigkeit vom Anwendungsstapel. Auf diese Weise können wir einen detaillierteren Überblick über die Leistung erhalten als mit dem langsamen Protokoll.

Für die folgenden Beispiele ist unser Datenkorpus OpenWebText , das etwa 40 GB Klartext und etwa 8 Millionen einzelne Dokumente bereitstellt und lokal auf einem M1 Max Macbook mit 32 GB RAM läuft.

Lasst uns beginnen!

Die Aktivierung der Ablaufverfolgung in Elasticsearch erfolgt über statische Einstellungen (konfiguriert in elasticsearch.yml) und dynamische Einstellungen, die zur Laufzeit mit dem Befehl PUT _cluster/settings umgeschaltet werden können, wobei eine der dynamischen Einstellungen die Abtastrate ist. Bestimmte Einstellungen, wie z. B. die Abtastrate, können zur Laufzeit umgeschaltet werden. In elasticsearch.yml wollen wir Folgendes festlegen:

tracing.apm.enabled: true
tracing.apm.agent.server_url: "url of the APM server"

Das geheime Token (oder der API-Schlüssel) muss sich im Elasticsearch-Keystore befinden. Verwenden Sie den folgenden Befehl: „Elasticsearch-keystore“ add „Tracing.apm.secret_token“ oder „Tracing.apm.api_key“ . Das Keystore-Tool sollte in <Ihrem Elasticsearch-Installationsverzeichnis>/bin/elasticsearch-keystore zu finden sein. Danach müssen Sie Elasticsearch neu starten. Weitere Informationen zum Tracking finden Sie in unserer Tracking-Dokumentation .

Sobald APM aktiv ist, können wir uns die APM-Ansicht in Kibana ansehen und sehen, wie Elasticsearch automatisch verschiedene REST-API-Endpunkte erfasst. Hier konzentrieren wir uns auf den POST /{index}/_search-Aufruf, um zu sehen, was wir daraus machen können.

Wenn wir die einfache Abfrage direkt im Feld GET /{index}/_search untersuchen, sehen wir die folgende Wasserfallaufschlüsselung. Diese enthält interne Bereiche, die einen tieferen Einblick in die Aktivitäten von Elasticsearch hinter den Kulissen geben. Wir sehen die Gesamtdauer dieser Suche (86 Millisekunden).

Die der Abfrage beigefügten Metadaten umfassen ausführliche Informationen zu HTTP-Headern, Benutzeragenten, dem Standort des Elasticsearch-Knotens (Metadaten des Cloud-Anbieters, Hostname, Containerinformationen), einige Systeminformationen und URL-Details. Anhand einiger grundlegender Handelsinformationen können wir ein Linsendiagramm erstellen, das die durchschnittliche Handelsdauer darstellt und es uns ermöglicht, zu erkennen, ob ein Auf- oder Abwärtstrend vorliegt.

unsere Suchanwendung

Schön, dass Sie Slowlog nicht mehr verwenden müssen! Ich kann die Transaktionsdauer bestimmen und bestimmen, wie viele Suchanfragen bei jedem Schwellenwert beantwortet werden. Es gibt jedoch einen Rückschlag: Elasticsearch erfasst die gesendete Abfrage (was genau die Abfrage war) nicht. Daher wissen wir, dass die Abfrage lange dauert, wissen aber nicht, um welche Abfrage es sich handelt.

Testen wir eine Beispielsuchanwendung. In diesem Beispiel verwenden wir eine einfache Flask-Anwendung mit zwei Routen: search_single und search_phrase, die match- und match_phrase- Abfragen in Elasticsearch darstellen . Beispielsweise können wir die folgende Abfrage verwenden:

{
  "query": {
    "match": {
      "content": "support"
    }
  }
}

Und

{
  "query": {
    "match_phrase": {
      "content": "support protest"
    }
  }
}

Der folgende Flask-Code implementiert die Route search_single. „search_phrase“ ist sehr ähnlich, außer dass „match_phrase“ anstelle von „match“ verwendet wird.

@app.route("/search_single", methods=["GET"])
def search_single():
    query = request.args.get("q", "")
    if not query.strip():
        return jsonify({"error": "No search query provided"}), 400
    try:
        result = es.search(
            index=ES_INDEX, query={"match": {"content": query}}
        )

        hits = result["hits"]["hits"]
        response = []
        for hit in hits:
            response.append(
                {
                    "score": hit["_score"],
                    "content": hit["_source"]["content"],
                }
            )
        
        return jsonify(response)

Wenn ich fertig bin, kann ich jetzt „curl -XGET „http://localhost:5000/search_single?q=‘microphone‘“ aufrufen, um nach dem Begriff „Mikrofon“ zu suchen.

Wir haben APM in erster Linie zur Beobachtung zu unserer Suchanwendung hinzugefügt, aber unser APM-Agent erfasst ausgehende Anfragen und reichert sie mit Metadateninformationen an. In unserem Fall enthält span.db.statement Elasticsearch-Abfragen. Im folgenden Beispiel sucht jemand nach „window“.

Setze sie zusammen

In meinem Flask-Dienst habe ich die Abfragegröße auf 5.000 festgelegt, was bedeutet, dass Elasticsearch mir bis zu 5.000 passende Dokumente in einer einzigen JSON-Antwort liefern sollte. Das ist eine große Zahl, und die meiste Zeit wird damit verbracht, so viele Dokumente von der Festplatte abzurufen. Nachdem ich es in die Top-100-Dokumente geändert habe, kann ich durch Vergleich schnell erkennen, was im Dashboard passiert.

Durch die Anzeige von Transaktionen in der APM-Ansicht und die Aktivierung der Funktion „Critical Path Lab“ wird ein Overlay erstellt, das uns zeigt, wo die Anwendung ihre Zeit verbringt.

Danach habe ich ein Dashboard mit den Feldern „transaktion.duration.us“, „es_query_took“ und „transaktion.name“ erstellt. Zu den allgemeinen KQL-Filtern gehören „service.name“, „processor.event: Transaction“ und „transaction.name: POST /{index}/_search“.

Zusätzlicher Tipp: Gehen Sie zu „Ansichtsverwaltung“ > wählen Sie die Ansicht aus, die den APM-Datenfluss enthält > wählen Sie das Feld „transaction.duration.us“ aus > und ändern Sie das Format in „Dauer“. Jetzt wird es automatisch in einer für Menschen lesbaren Ausgabe statt in Mikrosekunden gerendert.

Mithilfe der Lens-Anmerkungsfunktion können wir im mittleren Lens sehen, dass die Umstellung auf 100 Dokumente die durchschnittliche Suchtransaktion erheblich verringert hat. Sehen Sie sich außerdem die Gesamtzahl der Datensätze in der oberen rechten Ecke an. Da wir schneller suchen können, haben wir einen höheren Durchsatz! Ich mag Histogramme sehr, deshalb habe ich in der Mitte der oberen Zeile ein Histogramm mit der Transaktionsdauer auf der X-Achse und der Anzahl der Datensätze auf der Y-Achse erstellt. Außerdem stellt APM Metriken bereit, sodass wir jederzeit feststellen können, wie viel CPU-%-Auslastung stattfindet, zusammen mit der JVM-Heap-Nutzung, der Nicht-Heap-Nutzung, der Thread-Anzahl und vielen weiteren nützlichen Informationen.

 

abschließend

Dieser Blogbeitrag zeigt Ihnen, wie wichtig es ist, Elasticsearch als instrumentierte Anwendung zu nutzen und Engpässe leichter zu erkennen. Darüber hinaus können Sie die Transaktionsdauer als Messgröße für die Anomalieerkennung verwenden, Ihre Anwendung A/B-Tests durchführen und sich nie wieder fragen, ob sich Elasticsearch schneller anfühlt, da Sie jetzt über die Daten verfügen, um diese Frage zu beantworten. Darüber hinaus können alle vom Benutzeragenten für die Abfrage gesammelten Metadaten Ihnen bei der Fehlerbehebung helfen.

Von hier aus können Dashboards und Datenansichten importiert werden.

Warnen Sie
vor Problemen mit der Transaktionsdauer in Elasticsearch. Dieses Problem wurde in der kommenden Version 8.9.1 behoben. Zuvor verwendet die Transaktion den falschen Takt, was die Gesamtdauer durcheinander bringt.

Die Veröffentlichung und der Zeitpunkt der in diesem Artikel beschriebenen Features oder Funktionen liegen im alleinigen Ermessen von Elastic. Derzeit nicht verfügbare Features oder Funktionen werden möglicherweise nicht rechtzeitig oder überhaupt nicht bereitgestellt.

Weiterlesen: So beheben Sie langsame Elasticsearch-Abfragen für eine bessere Benutzererfahrung | Elastic-Blog