Collectorに問題がなければ、SDKの動作を確認する
Collectorの様子を確認し、Collector自身には問題がないことがわかりました。つまり、エクスポーターは動作し、エラーログもなく、設定に問題もなく、レシーバーがテレメトリーデータを受信していない。そうなると、テレメトリーデータのもう一つ上流、SDKの動作を確認していく必要があります。
SDKもまた、デフォルトではinfoレベルのログを出力しており、エクスポートに失敗するようなことが起きたときには、その旨のログが記録されます。たとえばJava SDKの場合は、次のようなログが出力されます。
Picked up JAVA_TOOL_OPTIONS: -javaagent:/home/splunk/spring-petclinic/opentelemetry-javaagent.jar
…
（中略）
…
[otel.javaagent 2024-12-10 09:29:19:022 +0000] [OkHttp http://localhost:4318/...] ERROR io.opentelemetry.exporter.internal.http.HttpExporter - Failed to export logs. The request could not be executed. Full error message: Failed to connect to localhost/127.0.0.1:4318
java.net.ConnectException: Failed to connect to localhost/127.0.0.1:4318
at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
…
出力先のURLが正しいか（上記の場合はlocalhost:4318のようです）、その先のサービスは起動しているか（上記の場合には同じホストでCollectorが起動しているか、受け付けるポートは正しいか）などを確認していきましょう。
また、それぞれのSDKで、現在どんな設定で動作しているのかをデバッグログとして出力することもできます。Java SDKの場合は、javaの起動オプションに-Dotel.javaagent.debug=trueを追加すると、たとえば次のようなログが記録されるようになり、ログの処理がどのように設定されているかがわかります。
logRecordProcessor=BatchLogRecordProcessor{logRecordExporter=OtlpHttpLogRecordExporter{exporterName=otlp, type=log, endpoint=http://localhost:4318/v1/logs, timeoutNanos=10000000000, proxyOptions=null, compressorEncoding=null, connectTimeoutNanos=10000000000, exportAsJson=false, headers=Headers{User-Agent=OBFUSCATED}, retryPolicy=RetryPolicy{maxAttempts=5, initialBackoff=PT1S, maxBackoff=PT5S, backoffMultiplier=1.5}, memoryMode=REUSABLE_DATA}, scheduleDelayNanos=1000000000, maxExportBatchSize=512, exporterTimeoutNanos=30000000000}}
まとめ
いかがでしたでしょうか？
本番アプリケーションのトラブル対応の目的でOpenTelemetryを導入するわけですが、OpenTelemetry自身にもトラブルが発生することは少なくありません。本記事では、代表的なトラブルである「テレメトリーデータが来ない」を取り上げて、どのように調査し、対応していくのかを紹介しました。
他にも、分散トレース特有のトラブルがしばしば発生します。たとえば、トレースが伝搬されない、もしくは1つの巨大なトレースが出来上がるなどはよく起こる事象です。そのときはスパン生成やトレース伝搬の仕組みをベースに状況を確認していくことになりますが、これについてはまた別の機会でご紹介できればと思います。
オブザーバビリティに関する仕組みのトラブルシュートに使うのもまたオブザーバビリティです。しかし、その性格上（もしくは多重の投資を防ぐために）、オブザーバビリティに関するオブザーバビリティ環境が整備されることはあまり多くありません。トラブルがあったり何か気になる挙動があるときには、基本に立ち返り、メトリクスやログを確認しに行くことが求められます。OpenTelemetryの各コンポーネントは、そのための仕組みを備えています。
本記事にあるような情報、もしくはさらなるトラブルシュートに関しては、OpenTelemetryのウェブサイトや、GitHubのリポジトリにも掲載されています。困ったことがあれば、ぜひ参照してみてください。
