기본적으로 뉴렐릭은 APM 애플리케이션과 Elasticsearch 클러스터를 두 개의 분리되고 연결되지 않은 항목으로 모니터링합니다: 앱이 실제로 해당 클러스터를 호출한다는 것을 보여주는 것은 없습니다.
이 페이지는 Elasticsearch의 기본 OpenTelemetry 분산 추적을 사용하여 해당 격차를 해소합니다. Elasticsearch는 애플리케이션별 변경 없이 메트릭에 이미 사용하는 것과 동일한 OpenTelemetry 수집기(NRDOT 또는 OTel Collector Contrib)를 통해 자체 트레이스 스팬을 내보냅니다. 결과: 느린 트랜잭션은 이를 처리한 클러스터로 바로 연결됩니다.
내부적으로 애플리케이션과 Elasticsearch는 각각 동일한 요청의 일부를 단일 공유 트레이스에 제공합니다. 뉴렐릭은 양쪽이 함께 속해 있음을 인식하고 서비스-클러스터 관계를 자동으로 구축합니다.
팁
분산 추적은 APM을 Elasticsearch와 연관시키는 두 가지 방법 중 하나입니다. 전체 요청 수준의 세부 정보를 제공하지만, 추가 트레이스 데이터가 수집 볼륨에 추가됩니다. 클러스터가 관련 엔티티로 표시되기만 하면 되는 경우, 대신 APM 애플리케이션의 텔레메트리에 클러스터 이름으로 태그를 지정할 수 있습니다 ― 이는 모든 Elasticsearch 버전에서 작동하지만 엔드투엔드 트레이스 세부 정보는 생략합니다.
호환되는 계측
이 상관관계는 다음을 포함하여 W3C Trace Context 전파를 지원하는 모든 애플리케이션에서 작동합니다:
계측 방식을 혼합할 수 있습니다. 예를 들어, 뉴렐릭 APM 에이전트를 사용하는 자바 서비스와 OpenTelemetry SDK를 사용하는 파이썬 서비스는 모두 동일한 Elasticsearch 클러스터를 호출할 수 있으며, 각각 뉴렐릭에서 해당 클러스터에 올바르게 연결된 것으로 나타납니다.
설정은 두 부분으로 구성됩니다: Elasticsearch에서 추적을 켜고, 수집기에 트레이스 파이프라인을 추가하는 것입니다.
추적을 켜면 Elasticsearch는 자체 OpenTelemetry 스팬을 내보내고, traceparent 헤더를 통해 애플리케이션의 트레이스와 결합하며, 각각에 es.cluster.name을(를) 기록합니다. 뉴렐릭은 공유된 트레이스를 사용하여 관계를 자동으로 연결합니다.
배포와 일치하는 섹션을 확장하십시오.
Elasticsearch에서 추적 켜기
모든 노드의 elasticsearch.yml에 다음을 추가합니다. 그런 다음 (ES_JAVA_OPTS 또는 jvm.options을(를) 통해) -Dtelemetry.otel.traces.enabled=true을(를) 설정하고 각 노드를 다시 시작합니다:
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
수집기에 트레이스 파이프라인 추가
이제 Elasticsearch가 전송하는 트레이스를 수신하고, 그렇지 않을 경우 클러스터가 자신을 호출하는 것처럼 보이게 만드는 스팬을 필터링하도록 수집기를 구성하십시오. otlp 수신기와 filter/drop_rootless_es 및 transform/strip_es_host 프로세서를 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"
telemetry.tracing.sample_rate:1.0# default 0.001; lower for high volume
수집기에 트레이스 파이프라인 추가
이제 Elasticsearch가 전송하는 트레이스를 수신하고, 그렇지 않을 경우 클러스터가 자신을 호출하는 것처럼 보이게 만드는 스팬을 필터링하도록 수집기를 구성하십시오. 수집기 설정의 traces 파이프라인에 otlp 수신기와 filter/drop_rootless_es 및 transform/strip_es_host 프로세서를 추가하십시오. 수집기가 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"
업데이트된 구성을 적용한 다음, 수집기 파드가 이를 적용할 수 있도록 롤아웃하십시오. 수집기를 설치 할 때 사용한 것과 동일한 ConfigMap 파일, Deployment 이름 및 네임스페이스를 사용하십시오 — 예를 들어 매니페스트 기반 설치를 따른 경우 nr-k8s-otel-collector-deployment 입니다: