Par Philipp Kahr
Remarque importante pour les utilisateurs d'Elasticsearch Service : actuellement, les modifications de configuration de Kibana décrites dans cet article sont limitées à Cloud Console et ne peuvent pas être configurées sans l'intervention manuelle de notre équipe d'assistance. Notre équipe d'ingénieurs travaille dur pour supprimer les restrictions sur ces paramètres afin que tous nos utilisateurs puissent activer l'APM interne. Les déploiements sur site ne sont pas affectés par ce problème.
L'identification et le dépannage des requêtes sont des compétences essentielles à maîtriser pour quiconque utilise Elasticsearch comme moteur de recherche. Qu'il s'agisse de commerce électronique, d'observabilité ou d'une solution de recherche axée sur le lieu de travail, la lenteur d'Elasticsearch peut avoir un impact négatif sur l'expérience utilisateur.
Pour identifier les requêtes Elasticsearch lentes, vous pouvez utiliser le slow log , qui capture les requêtes exécutées à un certain seuil. Obtenir le bon seuil de journal lent est un défi en soi. Par exemple, une requête qui prend 500 millisecondes peut être acceptable à pleine charge, mais la même requête peut ne pas l'être à faible charge. Le journal lent ne fait pas de différence et enregistre tout ce qui dépasse 500 ms. Le journal lent fait bien son travail et vous pouvez capturer différents niveaux de granularité en fonction de seuils. Au lieu de cela, le traçage peut examiner toutes les requêtes et déterminer combien se situent dans un certain seuil.
La surveillance des performances des applications (APM) n'est plus limitée à votre application. En utilisant l'instrumentation dans Elasticsearch, nous pouvons désormais ajouter Elasticsearch en tant que service à part entière plutôt qu'en tant que dépendance de la pile d'applications. De cette façon, nous pouvons obtenir une vue plus granulaire des performances que le journal lent.
Pour les exemples ci-dessous, notre corpus de données est OpenWebText , qui fournit environ 40 Go de texte brut et environ 8 millions de documents individuels, exécutés localement sur un Macbook M1 Max avec 32 Go de RAM.
commençons!
L'activation du traçage dans Elasticsearch se fait via des paramètres statiques (configurés dans elasticsearch.yml ) et des paramètres dynamiques, qui peuvent être basculés lors de l'exécution à l'aide de la commande PUT _cluster/settings, où l'un des paramètres dynamiques est le taux d'échantillonnage. Certains paramètres, tels que la fréquence d'échantillonnage, peuvent être modifiés lors de l'exécution. Dans elasticsearch.yml, nous souhaitons définir les éléments suivants :
tracing.apm.enabled: true
tracing.apm.agent.server_url: "url of the APM server"Le jeton secret (ou clé API) doit se trouver dans le magasin de clés Elasticsearch. Utilisez la commande suivante elasticsearch-keystore add Tracing.apm.secret_token ou Tracing.apm.api_key L'outil keystore doit se trouver dans <votre répertoire d'installation elasticsearch>/bin/elasticsearch-keystore . Après cela, vous devez redémarrer Elasticsearch. Vous trouverez plus d'informations sur le suivi dans notre documentation de suivi .
Une fois l'APM actif, nous pouvons consulter la vue APM dans Kibana et voir qu'Elasticsearch capture automatiquement divers points de terminaison de l'API REST. Ici, nous allons nous concentrer sur l'appel POST /{index}/_search pour voir ce que nous pouvons en tirer.
En inspectant la requête simple directement sur la zone GET /{index}/_search, nous voyons la répartition en cascade suivante. Celui-ci contient des étendues internes qui donnent un aperçu plus approfondi de ce que fait Elasticsearch dans les coulisses. On voit la durée totale de cette recherche (86 millisecondes).
Les métadonnées accompagnant la requête incluent des informations détaillées sur les en-têtes HTTP, l'agent utilisateur, l'emplacement du nœud Elasticsearch (métadonnées du fournisseur de cloud, nom d'hôte, informations sur le conteneur), certaines informations système et les détails de l'URL. En utilisant certaines informations commerciales de base, nous pouvons créer un graphique de lentille qui trace la durée moyenne des échanges et nous permet de voir s'il y a une tendance à la hausse ou à la baisse.
notre application de recherche
C'est bien de ne plus avoir besoin d'utiliser slowlog ! Je peux déterminer la durée de la transaction et déterminer le nombre de recherches auxquelles il est répondu à n'importe quel seuil. Cependant, il y a un revers - Elasticsearch ne capture pas la requête envoyée (quelle était exactement la requête), donc nous savons que la requête prend beaucoup de temps, mais nous ne savons pas quelle était la requête.
Testons un exemple d'application de recherche. Dans cet exemple, nous utiliserons une simple application Flask avec deux routes : search_single et search_phrase qui représenteront les requêtes match et match_phrase dans Elasticsearch . Par exemple, nous pouvons utiliser la requête suivante :
{
"query": {
"match": {
"content": "support"
}
}
}et
{
"query": {
"match_phrase": {
"content": "support protest"
}
}
}Le code Flask suivant implémente la route search_single. search_phrase est très similaire sauf qu'il utilise match_phrase au lieu de match.
@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)Une fois prêt, je peux maintenant appeler curl -XGET "http://localhost:5000/search_single?q='microphone'" pour rechercher le terme "microphone".
Nous avons principalement ajouté APM à notre application de recherche pour l'observation, mais notre agent APM capture les demandes sortantes et les enrichit avec des informations de métadonnées. Dans notre cas, span.db.statement contient des requêtes Elasticsearch. Dans l'exemple ci-dessous, quelqu'un recherche window.
les assembler
Dans mon service Flask, j'ai défini la taille de la requête sur 5 000, ce qui signifie qu'Elasticsearch devrait me fournir jusqu'à 5 000 documents correspondants dans une seule réponse JSON. Il s'agit d'un nombre important, et la plupart du temps est consacré à la récupération de ce nombre de documents sur le disque. Après l'avoir changé en 100 meilleurs documents, je peux rapidement identifier ce qui se passe dans le tableau de bord par comparaison.
L'affichage des transactions dans la vue APM et l'activation de la fonctionnalité de laboratoire du chemin critique créent une superposition qui nous montre où l'application passe son temps.
Après cela, j'ai créé un tableau de bord avec les champs transaction.duration.us, es_query_took, transaction.name. Les filtres KQL généraux incluent service.name, processor.event : transaction, transaction.name : POST /{index}/_search.
Conseil supplémentaire : accédez à Gestion des vues > sélectionnez la vue contenant le flux de données APM > sélectionnez le champ transaction.duration.us > et modifiez le format en durée. Maintenant, il le rend automatiquement en sortie lisible par l'homme au lieu de microsecondes.
En utilisant la fonction d'annotation Lens, nous pouvons voir dans l'objectif central que le passage à 100 documents a considérablement réduit la transaction de recherche moyenne. Non seulement cela, regardez le nombre total d'enregistrements dans le coin supérieur droit. Comme nous pouvons rechercher plus rapidement, nous avons un débit plus élevé ! J'aime beaucoup les histogrammes, j'ai donc créé un histogramme au milieu de la ligne du haut avec la durée de la transaction sur l'axe X et le nombre d'enregistrements sur l'axe Y. En outre, APM fournit des métriques afin que nous puissions déterminer à tout moment le pourcentage d'utilisation du processeur, ainsi que le tas JVM, l'utilisation hors tas, le nombre de threads et bien d'autres informations utiles.
en conclusion
Cet article de blog vous montre à quel point il est important d'utiliser Elasticsearch comme une application instrumentée et d'identifier plus facilement les goulots d'étranglement. De plus, vous pouvez utiliser la durée des transactions comme métrique pour la détection des anomalies, tester votre application A/B et ne plus jamais vous demander si Elasticsearch se sent plus rapide car vous disposez désormais des données pour répondre à cette question. De plus, toutes les métadonnées collectées de l'agent utilisateur à la requête peuvent vous aider à résoudre les problèmes.
Les tableaux de bord et les vues de données peuvent être importés à partir d' ici .
Avertir
des problèmes de durée de transaction dans Elasticsearch. Ce problème a été corrigé dans la prochaine version 8.9.1. Avant cela, la transaction utilise la mauvaise horloge, ce qui perturbe la durée globale.La publication et le calendrier de toute fonctionnalité ou fonctionnalité décrite dans cet article sont à la seule discrétion d'Elastic. Toute fonctionnalité ou fonctionnalité non disponible actuellement peut ne pas être livrée à temps ou pas du tout.