Splunk Observability Cloud の Go インストルメンテーションのトラブルシューティング

Go OpenTelemetryの問題のトラブルシューティングの手順

以下の手順は、Go インストルメンテーションの問題のトラブルシューティングに役立ちます：

1. デバッグロギングを有効にします。

2. スパンの欠落をチェックする。

3. エンドポイントが正しいことを確認する。

デバッグロギングを有効にする

デバッグロギングにより、Go インストルメンテーションの詳細レベルが向上します。これは、問題のトラブルシューティングに役立ちます。デバッグロギングを有効にするには、OTEL_LOG_LEVEL 環境変数を debug に設定します。

export OTEL_LOG_LEVEL="debug"

この環境変数の出力がいつまでもオンのままだとシステムに過負荷をかける可能性があるため、問題解決後は必ず環境変数の設定を解除してください。

スパンの欠落をチェックする

Go インストルメンテーションは、いくつかの理由によりスパンをドロップする可能性があります。以下の手順に従って、インストルメンテーションが有効なスパンをドロップしていないことを確認してください。

サービスのすべてのスパンが欠けている

サービスのスパンが Splunk Observability Cloud に表示されない場合は、以下を実行してください。

1. 数分間待ってから、もう一度確認してください。テレメトリパイプラインに遅延が生じている可能性があります。

2. サービス名が Splunk Observability Cloud で unknown_service プレフィックス付きで表示されているかどうかを確認します。たとえば、unknown_service:go のようになります。このような場合は、 OTEL_SERVICE_NAME 環境変数をサービスの名前に設定して、アプリケーションを再起動します。

3. デバッグログに以下のようなメッセージがないか確認してください：

   TEXTCopy

   exporting spans {"count": 154, "total_dropped": 0}

   exporting spans {"count": 154, "total_dropped": 0}

   ログメッセージの count の値は、指定されたバッチでエクスポートされたスパンの数です：

   • count が 0 よりも大きい場合、インストルメンテーションはスパンをエクスポートしています。この場合、Collector の構成を確認してください。「Collector のトラブルシューティング」を参照してください。

   • count が 0 と等しい場合、インストルメンテーションはスパンをエクスポートしていません。span.End() メソッドを呼び出してすべてのスパンが終了していることを確認してください。

サービスからいくつかのスパンが欠落している

デバッグロギングを有効にしたら、以下のようなメッセージがないかログをチェックします：

exporting spans {"count": 364, "total_dropped": 1320}

total_dropped の値は、インストルメンテーションによってドロップされたスパンの累積数です。この値がゼロより大きい場合、バッチスパンプロセッサが、キューが一杯になった時に新しいスパンをドロップしています。

バッチ・スパン・プロセッサーは、次のような場合にスパンをドロップすることがあります：

• ログメッセージの count の値が常に最大バッチサイズと等しい場合、インストルメンテーションがエクスポートできるよりも速くスパンを作成している可能性があります。システムに十分なリソースがある場合は、バッチサイズとキューサイズを大きくしてください。例：

  BASHCopy

  export OTEL_BSP_MAX_EXPORT_BATCH_SIZE=1024 export OTEL_BSP_MAX_QUEUE_SIZE=20480 # Don't increase the queue size if the system has limited memory

  export OTEL_BSP_MAX_EXPORT_BATCH_SIZE=1024
  export OTEL_BSP_MAX_QUEUE_SIZE=20480
  # Don't increase the queue size if the system has limited memory

  ネットワークで使用できる帯域幅が限られている場合は、エクスポートバッチサイズを小さくしてください。例：

  BASHCopy

  export OTEL_BSP_MAX_EXPORT_BATCH_SIZE=128

  export OTEL_BSP_MAX_EXPORT_BATCH_SIZE=128

  そうすることで、エクスポートの頻度が上がり、キューの消耗が早くなる可能性があります。

• count の値が一貫して最大バッチサイズと等しくない場合は、ターゲットへの接続が安定しており、十分な帯域幅があることを確認してください。エクスポートのタイムアウトを短くし、エクスポートのサイズと頻度を減らして、キューサイズを増やすこともできます。例：

  BASHCopy

  # 5s export timeout. export OTEL_BSP_EXPORT_TIMEOUT=5000 # 30s maximum time between exports. export OTEL_BSP_SCHEDULE_DELAY=30000 export OTEL_BSP_MAX_QUEUE_SIZE=5120 export OTEL_BSP_MAX_EXPORT_BATCH_SIZE=128

  # 5s export timeout.
  export OTEL_BSP_EXPORT_TIMEOUT=5000
  # 30s maximum time between exports.
  export OTEL_BSP_SCHEDULE_DELAY=30000
  export OTEL_BSP_MAX_QUEUE_SIZE=5120
  export OTEL_BSP_MAX_EXPORT_BATCH_SIZE=128

  キューサイズの増加に対応するために十分なメモリリソースをシステムに割り当ててください。エクスポート設定を変更すると、インストルメンテーションでエクスポートバッチ全体がドロップされ、時間がかかりすぎる可能性があります。

エンドポイントが正しいことを確認する

次のようなログに記録されたエラーメッセージが表示される場合は、エクスポーターがエンドポイントに接続できない可能性があります：

2022/03/02 20:29:29 context deadline exceeded
2022/03/02 20:29:29 max retry time elapsed: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp: missing address"

この問題を解決するには、以下の条件が真であることを確認します：

1. ターゲット・エンドポイントは起動しており、コネクションを受信しています。

2. ターゲット・エンドポイントは接続サービスから到達可能です。

3. 代替値を提供する場合、ターゲットエンドポイントは正しいです。