Docs » Splunk Distribution of the OpenTelemetry Collector の利用開始 » Collector のトラブルシューティング » Splunk OpenTelemetry Collector のトラブルシューティング

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

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

注釈

GitHub にあるOpenTelemetry Project のトラブルシューティングのドキュメント も参照してください。

Collector が期待通りに動作しない 🔗

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

Collector またはtd-agentサービスが動作していない 🔗

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

Collector が終了または再起動する 🔗

以下の理由でコレクタが終了または再起動することがあります：

  • memory_limiter プロセッサーの欠落または設定ミスによるメモリ圧迫

  • 負荷に対して不適切なサイズ

  • 不適切な設定。例えば、キューのサイズが使用可能なメモリより大きく設定されています。

  • インフラストラクチャリソースの制限。例えば、Kubernetes

Splunk Distribution of OpenTelemetry Collector を再起動し、設定を確認します。

WindowsのDockerコンテナでコレクタが起動しない 🔗

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

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

コレクタにデータの問題が発生している 🔗

Splunk Observability Cloud のデフォルトダッシュボード Dashboards > OpenTelemetry Collector > OpenTelemetry Collector では、データ損失や CPU リソースなどのパラメータを追跡する Collector 内部メトリクスを監視できます。これらのメトリクスの詳細については、OpenTelemetry GitHub リポジトリの モニタリング を参照してください。

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

コレクタがデータをドロップしている 🔗

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

  • コレクタのサイズが不適切なため、Splunk Distribution of OpenTelemetry Collector がデータの受信と同じ速さでデータを処理およびエクスポートできません。サイズに関するガイドラインは サイジングとスケーリング を参照してください。

  • エクスポート先が利用できないか、データの受け入れが遅すぎます。ドロップを軽減するには、batch プロセッサーを構成します。さらに、有効化されたエクスポーターでキュー再試行オプションを設定する必要がある場合もあります。

コレクタがデータを受信していない 🔗

コレクタは、以下の理由でデータを受信しないことがあります：

  • ネットワーク設定の問題

  • レシーバー設定の問題

  • レシーバーはレシーバーセクションで定義されていますが、パイプラインではアクティブ化されていません。

  • クライアントの設定が間違っている

詳しくは OpenTelemetry プロジェクトの GitHub リポジトリにあるログや Troubleshooting zPages を確認してください。Splunk はアップストリームの OpenTelemetry Collector に対してベストエフォートサポートしか提供していないことに注意してください。

コレクタがデータを処理できない 🔗

コレクタは、以下の理由でデータを処理しないことがあります：

  • 属性プロセッサーは、スパンの「タグ」に対してのみ機能します。スパン名は、スパン・プロセッサーによって処理されます。

  • トレースデータのプロセッサー ( テールサンプリングを除く ) は、個別のスパンでのみ動作します。コレクタが適切に構成されていることを確認してください。

コレクタがデータをエクスポートできない 🔗

コレクタは以下の理由でデータをエクスポートできないことがあります：

  • ファイアウォール、DNS、プロキシ対応などのネットワーク構成に関する問題

  • エクスポーターの設定が正しくない

  • 認証情報が正しくない

  • デスティネーションが利用できない

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

詳しくは OpenTelemetry プロジェクトの GitHub リポジトリにあるログや Troubleshooting zPages を確認してください。Splunk はアップストリームの OpenTelemetry Collector に対してベストエフォートサポートしか提供していないことに注意してください。

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

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

  1. ゲートウェイがポート6060と9943のリクエストをリッスンできることを確認します。

  2. エージェント構成に、パイプライン内の 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

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

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

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

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

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

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

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

  • Linuxでは、ターミナルで curl http://localhost:8888/metrics を実行します。

  • Windowsでは、PowerShellで "Invoke-WebRequest -URI https://localhost:8888/metrics" を実行します。

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

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

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

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

  • レシーバー・エンドポイント

  • 拡張機能のエンドポイント

  • メトリクスアドレス（ポート8888の場合）

ポート8888との競合 🔗

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

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

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

  1. 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チャートを使用している場合は、設定と公開ポートの両方のチャート値を更新して設定を修正してください。

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

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

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

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

エラーコード

説明

401 (UNAUTHORIZED)

設定されたアクセストークンまたはレルムが正しくありません。

404 (NOT FOUND)

エンドポイントやパス、ネットワーク、ファイアウォール、ポートの問題など、コンフィギュレーション・パラメータに誤りがあります。

429 (TOO MANY REQUESTS)

送信されるトラフィック量に対して組織がプロビジョニングされていません。トラフィックを減らすか、容量の増加を要求します。

503 (SERVICE UNAVAILABLE)

Log Observer を使っている場合、HECv1 がどのように応答するかによって、これは 429 (TOO MANY REQUESTS) エラーコードと同じになります。そうでなければ、ステータスページを確認してください。

トレース収集の問題 🔗

Collector のトレース収集に関する一般的な問題をいくつか紹介します。

合成データを送信して 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 を渡して確認することもできます。

This page was last updated on 2024年04月16日.