Docs » Splunk Observability Cloud でサポートされているインテグレーション » バックエンドアプリケーションをインストルメンテーションして、スパンを Splunk APM に送信する » Splunk Observability Cloud けに Go アプリケーションをインストルメンテーションする » Splunk Observability Cloud の Go インストルメンテーションのトラブルシューティング

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

Splunk Distribution of OpenTelemetry Go を使用して Go アプリケーションをインストルメンテーションしているときに、Splunk Observability Cloud にデータが表示されない場合は、以下のトラブルシューティング手順に従ってください。

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

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

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

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

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

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

デバッグロギングは、Go インストルメンテーションの冗長性を高めます。これは問題のトラブルシューティングに役立ちます。デバッグロギングを有効にするには、環境変数 OTEL_LOG_LEVELdebug に設定します。

export OTEL_LOG_LEVEL="debug"

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

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

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

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

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

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

  2. サービス名が Splunk Observability Cloud で unknown_service 接頭辞付きで表示されるかどうかを確認します。たとえば、unknown_service:go 。その場合は、OTEL_SERVICE_NAME 環境変数をサービス名に設定し、アプリケーションを再起動します。

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

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

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

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

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

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

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

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

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

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

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

    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=128
    

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

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

    # 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. 代替値を提供する場合、ターゲットエンドポイントは正しいです。

Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。

Splunk Observability Cloudをご利用のお客様

見込み客および無料トライアルユーザー様

  • Splunk Answers のコミュニティサポートで質問し、回答を得る

  • Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。

This page was last updated on 2024年05月29日.