Splunk Observability Cloud の Go インストルメンテーションのトラブルシューティング 🔗
Splunk Distribution of OpenTelemetry Go を使用して Go アプリケーションをインストルメンテーションしているときに、Splunk Observability Cloud にデータが表示されない場合は、以下のトラブルシューティング手順に従ってください。
Go OpenTelemetryの問題のトラブルシューティングの手順 🔗
以下の手順は、Go インストルメンテーションの問題のトラブルシューティングに役立ちます:
デバッグロギングを有効にする 🔗
デバッグロギングは、Go インストルメンテーションの冗長性を高めます。これは問題のトラブルシューティングに役立ちます。デバッグロギングを有効にするには、環境変数 OTEL_LOG_LEVEL
を debug
に設定します。
export OTEL_LOG_LEVEL="debug"
この環境変数の出力がいつまでもオンのままだとシステムに過負荷をかける可能性があるため、問題解決後は必ず環境変数の設定を解除してください。
スパンの欠落をチェックする 🔗
Goインストルメンテーションは、いくつかの理由によりスパンをドロップする可能性があります。以下の手順に従って、インストルメンテーションが有効なスパンをドロップしていないことを確認してください。
サービスのすべてのスパンが欠けている 🔗
サービスのスパンが Splunk Observability Cloud に表示されない場合は、以下を実行してください:
数分待ってから、もう一度確認してください。テレメトリパイプラインに遅れが生じている可能性があります。
サービス名が Splunk Observability Cloud で
unknown_service
接頭辞付きで表示されるかどうかを確認します。たとえば、unknown_service:go
。その場合は、OTEL_SERVICE_NAME
環境変数をサービス名に設定し、アプリケーションを再起動します。デバッグログに以下のようなメッセージがないか確認してください:
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
の値が常に最大バッチサイズと等しい場合、インストルメンテーションがエクスポートできるよりも速くスパンを作成している可能性があります。システムに十分なリソースがある場合は、バッチサイズとキューサイズを大きくしてください。例: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"
この問題を解決するには、以下の条件が真であることを確認します:
ターゲット・エンドポイントは起動しており、コネクションを受信しています。
ターゲット・エンドポイントは接続サービスから到達可能です。
代替値を提供する場合、ターゲットエンドポイントは正しいです。
Splunk Observability Cloudをご利用のお客様で、Splunk Observability Cloudでデータを確認できない場合は、以下の方法でサポートを受けることができます。
Splunk Observability Cloudをご利用のお客様
Submit a case in the Splunk Support Portal .
Contact Splunk Support .
見込み客および無料トライアルユーザー様
Splunk Answers のコミュニティサポートで質問し、回答を得る
Splunk #observability ユーザーグループの Slack チャンネルに参加して、世界中の顧客、パートナー、Splunk 社員とのコミュニケーションを図る。参加するには、Get Started with Splunk Community マニュアルの チャットグループ を参照してください。