Splunk OpenTelemetry Collector のトラブルシューティング 🔗

注意

Splunk only provides best-effort support for the upstream OpenTelemetry Collector.

Splunk Distribution of OpenTelemetry Collector に関する以下の問題と回避策を参照してください。

To understand how the Collector implements security see セキュリティガイドライン、アクセス許可、依存関係.

To learn about the Collector’s internal logs and other telemetry refer to the OpenTelemetry project Internal telemetry documentation.

The Collector isn’t behaving as expected 🔗

Collector はこのセクションで説明されている問題を経験する可能性があります。

The Collector or td-agent service isn’t working 🔗

Collectorまたはtd-agentサービスのいずれかがインストールされておらず、設定されていない場合は、以下の点を確認して問題を解決してください：

OSがサポートされていることを確認してください。詳しくは Collector 要件と OpenTelemetryのOS を参照してください。
インストーラ・スクリプトを使用して Linux 用 Collector をインストールします。で説明しているように、systemd がインストールされていることを確認します（Linux を使用している場合）。
プラットフォームがコンテナ化された環境で実行されていないことを確認します。
インストールログで詳細を確認する

The Collector exits or restarts 🔗

The Collector might exit or restart for the following reasons:

memory_limiter プロセッサーの欠落または設定ミスによるメモリ圧迫
負荷に対して不適切なサイズ
不適切な設定。例えば、キューのサイズが使用可能なメモリより大きく設定されています。
インフラストラクチャリソースの制限。例えば、Kubernetes

Restart the Splunk Distribution of the OpenTelemetry Collector and check the configuration.

The Collector doesn’t start in Windows Docker containers 🔗

カスタムビルドされたWindowsベースのDockerコンテナでプロセスが開始できず、「サービスプロセスがサービスコントローラーに接続できませんでした」というエラーメッセージが表示されることがあります。

この場合、NO_WINDOWS_SERVICE=1 環境変数を設定して、Splunk Distribution of OpenTelemetry Collector を Windows サービスとして実行しようとせず、対話型ターミナルで実行しているかのように起動させる必要があります。

実行中の設定を抽出する 🔗

実行中の構成を抽出すると、構成ファイルの内容がログに保存または保存され、問題のトラブルシューティングに使用できます。これらのポートにアクセスすることで、実行中の構成を抽出できます：

http://localhost:55554/debug/configz/initial
http://localhost:55554/debug/configz/effective

Linuxの場合、サポート・バンドル・スクリプトがこの情報を取得します。インストーラ・スクリプトについてはインストーラ・スクリプトを使用して Linux 用 Collector をインストールします。を参照してください。この機能は、主に Zookeeper のような、運用中に起動時の設定が変更される可能性があるリモート設定オプションを使用している場合に便利です。

The Collector is experiencing data issues 🔗

You can monitor internal Collector metrics tracking parameters such as data loss or CPU resources in Splunk Observability Cloud’s default dashboards at Dashboards > OpenTelemetry Collector > OpenTelemetry Collector.

To learn more see:

Collector の内部メトリクス
Internal telemetry in the OpenTelemetry project documentation

The Collector is dropping data 🔗

データが落ちる理由は様々ですが、最も多いのは以下の理由です：

The Collector is improperly sized, resulting in the Splunk Distribution of the OpenTelemetry Collector being unable to process and export the data as fast as it is received. See サイジングとスケーリング for sizing guidelines.
エクスポート先が利用できないか、データの受け入れが遅すぎます。ドロップを軽減するには、batch プロセッサーを構成します。さらに、有効化されたエクスポーターでキュー再試行オプションを設定する必要がある場合もあります。

The Collector isn’t receiving data 🔗

The Collector might not receive data for the following reasons:

ネットワーク設定の問題
レシーバー設定の問題
レシーバーはレシーバーセクションで定義されていますが、パイプラインではアクティブ化されていません。
クライアントの設定が間違っている

The Collector can’t process data 🔗

The Collector might not process data for the following reasons:

属性プロセッサーは、スパンの「タグ」に対してのみ機能します。スパン名は、スパン・プロセッサーによって処理されます。
トレースデータのプロセッサー ( テールサンプリングを除く ) は、個別のスパンでのみ動作します。コレクタが適切に構成されていることを確認してください。

The Collector can’t export data 🔗

The Collector might be unable to export data for the following reasons:

ファイアウォール、DNS、プロキシ対応などのネットワーク構成に関する問題
エクスポーターの設定が正しくない
認証情報が正しくない
デスティネーションが利用できない

プロキシを使用する必要がある場合は、Collectorのプロキシ設定を構成するを参照してください。

データ転送（ゲートウェイ）モードでメトリクスとメタデータが利用できない 🔗

データ転送（ゲートウェイ）モードでCollectorを手動でデプロイしてもメトリクスとメタデータが表示されない場合は、エージェント構成にSignalFxエクスポーターを使用するパイプラインが欠けている可能性があります。以下の手順に従って、構成を確認してください：

ゲートウェイがポート6060と9943のリクエストをリッスンできることを確認します。
エージェント構成に、パイプライン内の signalfx エクスポーターがあることを確認します。次の例は、 signalfx エクスポーターと、それを使用してメトリクスを送信するパイプラインを示しています：

:emphasize-lines: 2,3,4,5,14

exporters:
  signalfx:
      access_token: "${SPLUNK_ACCESS_TOKEN}"
      api_url: "http://${SPLUNK_GATEWAY_URL}:6060"
      ingest_url: "http://${SPLUNK_GATEWAY_URL}:9943"
      sync_host_metadata: true
      correlation:
  # Other exporters

service:
  extensions: [health_check, http_forwarder, zpages]
  pipelines:
      metrics/internal:
            receivers: [prometheus/internal]
            processors: [memory_limiter, batch, resourcedetection]
            exporters: [signalfx]
      # Other pipelines

APMでホスト・メトリクスをレポートする 🔗

APMサービスに関連するインフラストラクチャ・メトリクスを表示するために、関連データをキャプチャして送信するには、resource/add_environment プロセッサーを構成に追加します。

このプロセッサーは、すべてのスパンに deployment.environment span タグを挿入します。APM チャートでは、環境スパンタグが正しく設定されている必要があります。インストルメンテーションでこのスパンタグを設定するが、それができない場合は、このプロセッサーを使用して、必要な deployment.environment スパンタグ値を挿入することができます。

例：

processors:
  resourcedetection:
    detectors: [system,env,gce,ec2]
    override: true
  resource/add_environment:
    attributes:
      - action: insert
        value: staging
        key: deployment.environment

コマンドラインからメトリクスデータをチェックする 🔗

ホストのメトリクスが正しく収集および処理されているかどうかを確認するには、コマンドラインから curl または同様のツールを使用して、Collector に生データを照会できます。

Linuxでは、ターミナルで curl http://localhost:8888/metrics を実行します。
On Windows, run "Invoke-WebRequest -URI http://localhost:8888/metrics" in PowerShell.

その後、出力を grep （Linux）または Select-String （Windows）にパイプし、データをフィルターすることができます。例えば、curl http://localhost:8888/metrics | grep service_instance_id はサービス・インスタンスIDを取得します。

トレース収集の問題 🔗

合成データを送信して Collector をテストする 🔗

Collectorをテストして、アプリケーションをインストルメンテーションせずにスパンを受信できることを確認できます。デフォルトでは、Collector は JSON 経由でトレースデータを受信できる Zipkin レシーバーを有効にします。

UIをテストするには、次の例に示すように、POSTリクエストを送信するか、このディレクトリにJSONを貼り付けます。

curl -OL https://raw.githubusercontent.com/openzipkin/zipkin/master/zipkin-lens/testdata/yelp.json
curl -X POST localhost:9411/api/v2/spans -H'Content-Type: application/json' -d @yelp.json

注釈

Collector に到達するように、localhost フィールドを適宜更新してください。

応答がない場合は、リクエストが正常に送信されたことを意味します。curlコマンドに -v を渡して確認することもできます。

Error codes and messages 🔗

「パターンが一致しません」というエラーメッセージが表示されます。 🔗

「パターンが一致しません」のようなエラーメッセージが表示された場合、このメッセージはFluentdからのもので、<parser> 、ログメッセージに基づいてマッチできなかったことを意味します。その結果、ログメッセージは収集されません。Fluentd の設定を確認し、必要に応じて更新してください。

HTTPエラーコードを受信しています 🔗

HTTPリクエストが正常に完了しなかった場合、以下のHTTPエラーコードが表示されることがあります。

エラーコード	説明
`401 (UNAUTHORIZED)`	設定されたアクセストークンまたはレルムが正しくありません。
`404 (NOT FOUND)`	エンドポイントやパス、ネットワーク、ファイアウォール、ポートの問題など、コンフィギュレーション・パラメータに誤りがあります。
`429 (TOO MANY REQUESTS)`	送信されるトラフィック量に対して組織がプロビジョニングされていません。トラフィックを減らすか、容量の増加を要求します。
`503 (SERVICE UNAVAILABLE)`	Check the status page.

「bind：すでに使用されているアドレス」というエラーメッセージが表示されます。 🔗

「bind：すでに使用されているアドレス」のようなエラーメッセージが表示される場合は、現在のコンフィギュレーションが必要とするポートを別のリソースがすでに使用しています。このリソースは別のアプリケーションや、JaegerやZipkinのようなトレースツールである可能性があります。別のポートを使うように設定を変更することができます。

これらのエンドポイントやポートを変更することができます：

レシーバー・エンドポイント
拡張機能のエンドポイント
メトリクスアドレス（ポート8888の場合）

ポート8888との競合 🔗

ポート8888と競合する場合は、ポート8889に変更する必要があります：

サービスセクションにテレメトリ設定を追加します：

service:
  telemetry:
    metrics:
      address: ":8889"

receivers.prometheus/internal のポートを 8888 から 8889 に更新します：

receivers:
  prometheus/internal:
    config:
      scrape_configs:
      - job_name: 'otel-collector'
        scrape_interval: 10s
        static_configs:
        - targets: ['0.0.0.0:8889']

Kubernetesでこのエラーメッセージが表示され、Helmチャートを使用している場合は、設定と公開ポートの両方のチャート値を更新して設定を修正してください。

このページは 2024年11月26日に最終更新されました。

Related Topics