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

  プロセッサがすべてのメトリクス パイプラインに含まれていることを確認してください。

• elasticsearch.cluster.name

  が resource/cluster_name_override プロセッサ経由で設定されていることを確認します。

• 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 の receiver ルールを更新してください：

  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"

• filelogレシーバーのパスが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.