Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
Par défaut, New Relic monitore votre application APM et votre cluster Elasticsearch comme deux éléments distincts et non connectés : rien ne vous indique que l'application appelle réellement ce cluster.
Cette page comble cette lacune en utilisant le tracing distribué OpenTelemetry natif d’Elasticsearch. Elasticsearch exporte ses propres spans de trace via le même collecteur OpenTelemetry (NRDOT ou Collecteur Otel Contrib) que vous utilisez déjà pour les métriques, sans aucune modification par application. Le résultat : une transaction lente vous mène directement au cluster qui l’a servie.
Sous le capot, votre application et Elasticsearch apportent chacun leur part de la même requête à une seule trace partagée. New Relic reconnaît que les deux côtés vont ensemble, et crée automatiquement la relation service-cluster pour vous.
Conseil
Le tracing distribué est l’une des deux façons de corréler l’APM avec Elasticsearch. Il vous donne des détails complets au niveau de la requête, mais les données de trace supplémentaires s’ajoutent à votre volume d’ingestion. Si vous avez seulement besoin que le cluster apparaisse comme une entité associée, vous pouvez plutôt ajouter un tag à la télémétrie de votre application APM avec le nom de votre cluster ; cela fonctionne sur n’importe quelle version d’Elasticsearch, mais ignore les détails de la trace de bout en bout.
Instrumentation compatible
Cette corrélation fonctionne avec n’importe quelle application qui prend en charge la propagation du contexte W3C Trace Context, y compris :
Les applications instrumentées par le SDK OpenTelemetry (n’importe quel langage)
Agents New Relic APM (Go, Java, .NET, Node.js, Python, Ruby, PHP) avec le tracing distribué activé
Vous pouvez combiner les approches d’instrumentation. Par exemple, un service Java utilisant un agent New Relic APM, et un service Python utilisant le SDK OpenTelemetry peuvent tous deux appeler le même cluster Elasticsearch, et chacun apparaît correctement lié à celui-ci dans New Relic.
Elasticsearch 9.4 ou version ultérieure, car l’exportation native de trace OTLP nécessite cette version
Un collecteur OpenTelemetry (Collecteur Otel Contrib ou NRDOT) déjà en cours d’exécution et accessible depuis vos nœuds Elasticsearch. Si vous n’en avez pas encore installé un, suivez l’ installation auto-hébergée ou l’ installation Kubernetes.
Applications instrumentées envoyant des requests à Elasticsearch, en utilisant l’une des approches d’instrumentation compatibles listées ci-dessus, avec le tracing distribué activé
La configuration comporte deux parties : activer le tracing dans Elasticsearch, et ajouter un pipeline de trace à votre collecteur.
Une fois que vous avez activé le tracing, Elasticsearch émet ses propres spans OpenTelemetry, rejoint la trace de votre application via l’en-tête traceparent, et ajoute es.cluster.name sur chacune d’elles. New Relic utilise cette trace partagée pour établir la relation automatiquement.
Développez la section qui correspond à votre déploiement.
Activez le tracing dans Elasticsearch
Ajoutez ce qui suit à elasticsearch.yml sur chaque nœud. Ensuite, définissez -Dtelemetry.otel.traces.enabled=true (via ES_JAVA_OPTS ou jvm.options) et redémarrez chaque nœud :
telemetry.tracing.enabled:true
telemetry.export.endpoint: http://YOUR_COLLECTOR_HOST:4317# localhost if the collector runs on this node
telemetry.tracing.sample_rate:1.0# default 0.001; lower for high volume
Ajouter un pipeline de trace à votre collecteur
Configurez maintenant le collecteur pour recevoir les traces qu’Elasticsearch envoie, et pour filtrer les spans qui, autrement, donneraient l’impression que le cluster s’appelle lui-même. Ajoutez le récepteur otlp et les processeurs filter/drop_rootless_es et transform/strip_es_host à un pipeline traces :
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
# Drop Elasticsearch's own parentless spans (health checks, metrics-scrape calls) so the cluster isn't linked to itself
filter/drop_rootless_es:
error_mode: ignore
traces:
span:
-'instrumentation_scope.name == "elasticsearch" and IsRootSpan()'
# Remove Elasticsearch's own node address so New Relic doesn't resolve it back to the cluster
transform/strip_es_host:
error_mode: ignore
trace_statements:
-context: span
statements:
- delete_key(attributes, "http.request.headers.host") where instrumentation_scope.name == "elasticsearch"
- delete_key(attributes, "server.address") where instrumentation_scope.name == "elasticsearch"
Remplacez <collector-service> par le nom du service de votre collecteur (par exemple, nrdot-collector, ou otelcol-contrib) :
bash
$
sudo systemctl restart <collector-service>
Vérifier que les spans arrivent
Confirmez qu’Elasticsearch envoie des traces taggées avec le nom de votre cluster :
FROM Span SELECTcount(*)WHERE es.cluster.name ='<elasticsearch-cluster-name>' SINCE 30 minutes ago
La clause SINCE définit jusqu’où la requête remonte dans le temps. Ajustez-la en fonction de votre situation ; par exemple, SINCE 2 hours ago si vous avez activé le tracing plus tôt et que vous souhaitez vérifier une fenêtre plus longue.
Activez le tracing dans les pods Elasticsearch
Ajoutez ce qui suit à elasticsearch.yml (ConfigMap, valeurs Helm, ou ECK nodeSets). Ensuite, définissez -Dtelemetry.otel.traces.enabled=true via ES_JAVA_OPTS, et déployez les pods :
telemetry.tracing.sample_rate:1.0# default 0.001; lower for high volume
Ajouter un pipeline de trace à votre collecteur
Configurez maintenant le collecteur pour recevoir les traces qu’Elasticsearch envoie, et pour filtrer les spans qui, autrement, donneraient l’impression que le cluster s’appelle lui-même. Ajoutez le récepteur otlp et les processeurs filter/drop_rootless_es et transform/strip_es_host à un pipeline traces dans la configuration de votre collecteur. Assurez-vous que le collecteur expose le port gRPC 4317:
receivers:
otlp:
protocols:
grpc:
endpoint: 0.0.0.0:4317
processors:
# Drop Elasticsearch's own parentless spans (health probes, metrics-scrape calls) so the cluster isn't linked to itself
filter/drop_rootless_es:
error_mode: ignore
traces:
span:
-'instrumentation_scope.name == "elasticsearch" and IsRootSpan()'
# Remove Elasticsearch's own node address so New Relic doesn't resolve it back to the cluster
transform/strip_es_host:
error_mode: ignore
trace_statements:
-context: span
statements:
- delete_key(attributes, "http.request.headers.host") where instrumentation_scope.name == "elasticsearch"
- delete_key(attributes, "server.address") where instrumentation_scope.name == "elasticsearch"
Appliquez la configuration mise à jour, puis déployez les pods du collecteur pour qu’ils la prennent en compte. Utilisez le même fichier ConfigMap, le nom Deployment, et l’espace de nommage que vous avez utilisés lorsque vous avez installé le collecteur — par exemple, nr-k8s-otel-collector-deployment si vous avez suivi l’installation basée sur le manifeste :
Si vous avez déployé le collecteur avec Helm, réexécutez helm upgrade avec vos valeurs mises à jour au lieu de kubectl apply.
Vérifier que les spans arrivent
Confirmez qu’Elasticsearch envoie des traces taggées avec le nom de votre cluster :
FROM Span SELECTcount(*)WHERE es.cluster.name ='<elasticsearch-cluster-name>' SINCE 30 minutes ago
La clause SINCE définit jusqu’où la requête remonte dans le temps. Ajustez-la en fonction de votre situation ; par exemple, SINCE 2 hours ago si vous avez activé le tracing plus tôt et que vous souhaitez vérifier une fenêtre plus longue.
Consultez vos traces
Une fois que les spans circulent, vous pouvez effectuer des requêtes, et inspecter la carte des services corrélée. Consultez Afficher les traces distribuées, et la corrélation APM pour obtenir des exemples de requêtes, et savoir où trouver la carte des services dans New Relic.
Dépannage
Si vous ne voyez pas de spans, si le cluster montre une relation avec lui-même, ou si les applications ne sont pas liées au cluster, consultez la section sur la corrélation APM et le tracing distribué du guide de dépannage.