オブザーバビリティ入門者に知っておいてほしいOpenTelemetryのトラブルシューティング

　この連載は、オブザーバビリティという言葉を聞いたことはあるが具体的なイメージを持っていないエンジニア向けにOpenTelemetryについて紹介するものです。概要理解から導入方法まで一通り理解いただける連載となります。第5回では、OpenTelemetryを設定していくにあたって、よくあるトラブルとその対処方法を紹介していきます。

対象読者

　この連載では以下の読者を想定しています。

• オブザーバビリティやOpenTelemetryに興味がある人
• SREやDevOps、Platform Engineeringに取り組んでいるエンジニア
• バックエンド開発者、クラウドエンジニア、インフラエンジニア

OpenTelemetryを設定してみた！ でもデータが見えない？？

　前回までの連載で以下のようなテーマを扱ってきました。

• 第1回：オブザーバビリティとは何か、OpenTelemetryとは何か
• 第2回：オブザーバビリティを支えるテレメトリーデータとは何か、どう活用するか
• 第3回：OpenTelemetry Collectorによって、どのようにデータを扱うか
• 第4回：実践！OpenTelemetryでの計装

　まだご覧になっていない方は、是非ご一読ください。

　第5回となる今回は、ここで起こるトラブルとその対応に注目します。

　さて、第3回のガイドに従ってOpenTelemetry Collectorを設定し、第4回の内容に沿ってアプリケーションに計装を行い、SDKを設定しました。「よしよしこれで、分析バックエンドの画面を開くとアプリケーションの様子が見れるように……あれ？ 真っ白じゃん？」ということはたびたび起こります。つまり、どこかで何かがうまく動いていなくて、結果的にテレメトリーデータ（トレース、メトリクス、ログなど）が見れないのです。

　こんなとき、どのようにすればよいでしょうか？ オブザーバビリティのシステムが思った通りに動いていないトラブルに対応する時もまた、オブザーバブルに進めることが重要です。このようなトラブルに対応するため、OpenTelemetryの各コンポーネントは各種テレメトリーデータを出力しており、オブザーバビリティの基本的なプラクティスを踏襲しながら状況を調査できます。

　では、テレメトリーデータ転送のアーキテクチャーを基に、どこから何を確認していけばいいかを確認していきましょう。

テレメトリーデータ生成と転送のアーキテクチャー

　テレメトリーデータの確認は、下流（分析バックエンド）から上流（SDKなどのデータ生成元）へ進めるのがおすすめです。まずバックエンドでデータが確認できれば以降の問題を除外でき、効率的に調査範囲を絞れるからです。また、バックエンドはシステム全体の動作確認の基準になり、部分的な成功も確認しやすいため、上流の問題を正しく特定できます。さらに、バックエンドにはログや可視化ツールが整備されていることが多く、スムーズにデバッグができます。