Elasticsearch OpenTelemetry 통합 문제 해결

$
sudo systemctl status otelcol-contrib

• 서비스가 비활성화된 경우 서비스를 시작하십시오. sudo systemctl start otelcol-contrib
• 서비스 이용에 실패한 경우, 설정 오류를 수정하고 다시 시작하십시오. sudo systemctl restart otelcol-contrib

$
sudo journalctl -u otelcol-contrib.service -f

로그 출력을 검토하고 근본 원인(예: 연결 문제, 인증 실패 또는 권한 문제)을 해결하십시오.

오류 예시: dial tcp [::1]:9200: connect: connection refused

• config.yaml

  의 endpoint 이 Elasticsearch 호스트 및 포트와 일치하는지 확인하십시오.
• 수집기 호스트에서 Elasticsearch가 실행 중이고 접근 가능한지 확인하십시오.

오류 예시: permanent error: 403 Forbidden

1. /etc/systemd/system/otelcol-contrib.service.d/environment.conf 에서 NEWRELIC_LICENSE_KEY 확인합니다.

2. systemd 다시 로드하고 수집기를 재시작하세요.

   bash

   카피

   $
   sudo systemctl daemon-reload
   $
   sudo systemctl restart otelcol-contrib

오류 샘플: permission denied 또는 cannot open file

1. Elasticsearch 그룹에 수집기 사용자를 추가합니다.
   bash

   카피

   $
   sudo usermod -a -G elasticsearch otelcol-contrib

2. 수집기를 재시작하세요: sudo systemctl restart otelcol-contrib

$
# Unsecured cluster
$
curl -I http://localhost:9200
$

$
# With authentication
$
curl -u username:password -k https://localhost:9200

클러스터가 정상인지, 자격 증명이 유효한지, 방화벽 또는 보안 설정에서 액세스가 허용되는지 확인하십시오.

• 모든 메트릭 파이프라인에 resourcedetection 프로세서가 포함되어 있는지 확인하십시오.

• resource/cluster_name_override

  프로세서를 통해 elasticsearch.cluster.name 설정되었는지 확인합니다.

• filelog

  수신 경로가 올바르고 절대 경로인지 확인하십시오.
• 로그 파이프라인에 filelog 수신자와 otlphttp 수출자가 모두 포함되어 있는지 확인하십시오.

$
# Verify your Elasticsearch pods have the required label
$
kubectl get pods -n <namespace> -l app=elasticsearch --show-labels

반환되는 파드가 없으면 Elasticsearch 파드에 필수 app=elasticsearch 레이블이 누락된 것입니다. receiver_creator는 일치하는 레이블이 없으면 파드를 검색할 수 없습니다.

• StatefulSet/배포의 경우 파드 템플릿에 레이블을 추가합니다:

  spec:
    template:
      metadata:
        labels:
          app: elasticsearch

  카피
• 기존 파드의 경우 라벨을 추가하고 다시 시작합니다:
  bash

  카피

  $
  kubectl label pods -l <your-selector> app=elasticsearch -n <namespace>
  $
  kubectl rollout restart statefulset/elasticsearch -n <namespace>

• 사용자 지정 레이블을 사용하는 경우, 레이블과 일치하도록 values.yaml의 수신자 규칙을 업데이트하십시오:

  rule: type == "pod" && labels["app"] == "your-custom-label"

  카피

$
kubectl get pods -n newrelic
$
kubectl describe pod <collector-pod-name> -n newrelic

• 파드 이벤트에서 오류를 확인하세요: kubectl describe pod

• 수집기 로그 검토:

  bash

  카피

  $
  kubectl logs -n newrelic -l app.kubernetes.io/name=opentelemetry-collector

• 시크릿이 존재하는지 확인합니다:

  bash

  카피

  $
  kubectl get secret newrelic-licenses -n newrelic

• 리소스 제한이 너무 낮지 않은지 확인하십시오.

$
# Check collector logs for discovery errors
$
kubectl logs -n newrelic -l app.kubernetes.io/name=opentelemetry-collector | grep "receiver_creator"

• RBAC 권한이 올바르게 설정되었는지 확인하세요:

  bash

  카피

  $
  kubectl get clusterrole | grep opentelemetry
  $
  kubectl describe clusterrole <role-name>

• 수집기에 파드, 노드 및 엔드포인트를 감시할 수 있는 권한이 있는지 확인하세요.

• 구성에서 k8s_observer 확장이 활성화되어 있는지 확인합니다.

$
# Check network policies
$
kubectl get networkpolicies -n <namespace>
$

$
# Test connectivity from collector to Elasticsearch
$
kubectl exec -n newrelic <collector-pod> -- curl http://<es-pod-ip>:9200

• 네트워크 정책이 newrelic 네임스페이스에서 Elasticsearch 네임스페이스로의 트래픽을 허용하는지 확인합니다.
• Elasticsearch 파드가 올바른 포트를 노출하는지 확인합니다(기본값: 9200)
• 방화벽 규칙이 파드 간 통신을 차단하지 않는지 확인하세요.

오류 예시: permanent error: 403 Forbidden

• 시크릿에 올바른 라이선스 키가 포함되어 있는지 확인하세요:

  bash

  카피

  $
  kubectl get secret newrelic-licenses -n newrelic -o jsonpath='{.data.NEWRELIC_LICENSE_KEY}' | base64 -d

• OTLP 엔드포인트가 해당 리전에 올바른지 확인하세요.

• 수집기 파드에 시크릿이 마운트되어 있는지 확인합니다:

  bash

  카피

  $
  kubectl describe pod <collector-pod> -n newrelic | grep -A5 "Environment"

• mode: daemonset

  를 사용 중인지 확인합니다(배포 모드에서는 노드 로그에 액세스할 수 없습니다)

• 볼륨 마운트가 올바르게 구성되었는지 확인하세요:

  bash

  카피

  $
  kubectl describe pod <collector-pod> -n newrelic | grep -A10 "Mounts"

• 파일 로그 수신기 경로가 Elasticsearch 파드 로그와 일치하는지 확인합니다:

  bash

  카피

  $
  kubectl exec -n newrelic <collector-pod> -- ls /var/log/pods/*/elasticsearch*/*.log

• 수집기에 호스트 로그 디렉터리에 대한 읽기 권한이 있는지 확인하십시오.

• values.yaml에 K8S_CLUSTER_NAME 환경 변수가 설정되어 있는지 확인합니다.

• resource/cluster

  프로세서가 메트릭 파이프라인에 있는지 확인합니다.

• 확인할 쿼리:

  FROM Metric SELECT * WHERE metricName LIKE 'elasticsearch.%' LIMIT 1

  카피

  k8s.cluster.name 속성이 존재하는지 확인합니다.

FROM Span SELECT count(*) WHERE es.cluster.name = '<elasticsearch-cluster-name>' SINCE 30 minutes ago

• Native OTLP trace export requires Elasticsearch 9.4 or later. Confirm your version with curl http://localhost:9200 .
• Verify all three settings are present in elasticsearch.yml : telemetry.tracing.enabled: true , telemetry.export.endpoint , and telemetry.tracing.sample_rate .
• Confirm the JVM system property -Dtelemetry.otel.traces.enabled=true is set (in jvm.options or ES_JAVA_OPTS ), then restart Elasticsearch.
• The default telemetry.tracing.sample_rate is 0.001 (0.1%). Raise it while validating so spans appear quickly.

• Confirm the collector has an otlp receiver with the gRPC protocol enabled on 0.0.0.0:4317 , and that the endpoint is reachable from the Elasticsearch nodes.
• Confirm a traces pipeline exists and includes the otlp receiver and the otlphttp exporter.
• Check the collector logs for OTLP receiver or export errors.

A self-loop appears when Elasticsearch spans reach New Relic that can't be attributed to a calling application. There are two common sources:

• Parentless (root) Elasticsearch spans — spans with no parent application span, such as Kubernetes health probes or the Elasticsearch metrics receiver's own scrape calls ( _nodes/stats , _cluster/health , and similar). Because they aren't part of an application's trace, New Relic has no calling service and draws the relationship on the cluster itself.

• The node's own address — Elasticsearch server spans carry http.request.headers.host (and server.address ), which New Relic resolves back to the cluster.

  해결

  Add both processors to the traces pipeline, then restart the collector. filter/drop_rootless_es drops the parentless Elasticsearch spans (application-driven spans always have a parent, so they're kept), and transform/strip_es_host removes the address attributes:

  processors:
    filter/drop_rootless_es:
      error_mode: ignore
      traces:
        span:
          - 'instrumentation_scope.name == "elasticsearch" and IsRootSpan()'
    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"
  # traces pipeline: processors: [filter/drop_rootless_es, transform/strip_es_host, batch]

  카피

  Existing self-loops clear on their own once the corrected spans arrive and the previous relationship expires (this can take up to about 75 minutes).

• Make sure your applications are instrumented and propagate the W3C traceparent header on their Elasticsearch calls. Most modern Elasticsearch clients do this automatically when the application is instrumented with OpenTelemetry.
• Open a distributed trace that includes an Elasticsearch call and confirm the application spans and Elasticsearch spans share the same trace.
• Give the relationship a few minutes to build. New Relic re-evaluates entity relationships periodically.

• The traces path keys on es.cluster.name (stamped by Elasticsearch on its spans) and the metrics path on elasticsearch.cluster.name . The elasticsearchreceiver reports elasticsearch.cluster.name automatically from the value Elasticsearch returns, so both derive from the same cluster.name and resolve to one entity — no extra collector configuration needed.
• Don't force the metrics cluster name to a fixed value. If your collector config sets it with a resource processor (for example a resource/cluster_name_override that hardcodes the name), remove that override — otherwise metrics and traces resolve to two different entities and the correlated entity shows no metrics data.
• Make sure your Elasticsearch cluster.name is unique within your New Relic account so it maps to a single, unambiguous entity.