Collector が想定通りに動作しない

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

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

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

• OS がサポートされていることを確認します。詳細については、「Collector の要件」および「OpenTelemetry’s Operating System」を参照してください。

• Linux を使用している場合は、インストーラスクリプトを使用した Collector for Linux のインストールの説明に従って、systemd がインストールされていることを確認します。

• プラットフォームがコンテナ化された環境で実行されていないことを確認します。

• 詳細については、インストールログを確認してください。

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

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

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

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

• 誤った設定。例：キューサイズが使用可能なメモリより大きく設定されている。

• インフラ リソースの制限。例：Kubernetes。

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

実行中の設定を抽出する

実行中の設定を抽出すると、構成ファイルの内容をログに保存または格納し、問題のトラブルシューティングに使用できます。次のポートにアクセスして、実行中の設定を抽出できます。

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

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

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

Collector にデータの問題が発生している

Splunk Observability Cloud のデフォルトダッシュボードを使用して、データ損失や CPU リソースなどのパラメータを追跡する Collector の内部メトリクスを監視できます。ダッシュボードにアクセスするには、[Dashboards]、[OpenTelemetry Collector]、[OpenTelemetry Collector] の順に移動します。

詳細は、以下のトピックを参照してください：

• Collector の内部メトリクス

• OpenTelemetry プロジェクトドキュメント内の https://opentelemetry.io/docs/collector/internal-telemetry

Collector がデータをドロップしています

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

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

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

Collector がデータを受信していない

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

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

• レシーバー設定の問題

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

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

Collector がデータを処理できない

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

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

• トレースデータ（テールサンプリングを除く）のプロセッサは、個別のスパンでのみ動作します。Collector が正しく設定されていることを確認します。

Collector がデータをエクスポートできない

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

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

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

• 認証情報が正しくない

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

プロキシを使用する必要がある場合は、「Configure proxy settings for the 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] スパンタグを挿入します。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 を実行します。

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

続いて、出力を [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

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

エラーコードとメッセージ

HTTP エラーコードを受信している

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

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

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

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

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

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

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

ポート8888との競合

ポート 8888 と競合する場合は、以下の領域を調整してポート 8889 に変更する必要があります。

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

   service:
     telemetry:
       metrics:
         readers:
           - pull: 
               exporter:
                 prometheus:
                   host: '0.0.0.0'
                   port: 8889
                   without_scope_info: true
                   without_units: true
                   without_type_suffix: true

2. 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チャートを使用している場合は、コンフィギュレーションと公開ポートの両方のチャート値を更新してコンフィギュレーションを修正してください。