トレーシングエージェントの選択

適切なエージェントの選択

AWS は、トレース収集のための 2 つのツールセットを直接サポートしています（さらに豊富なオブザーバビリティパートナーも利用できます）。

• AWS Distro for OpenTelemetry（通称 ADOT）
• X-Ray のSDKとデーモン

どのツールまたはツールの組み合わせを使用するかの選択は、オブザーバビリティソリューションを発展させていく上で行わなければならない重要な意思決定です。これらのツールは相互に排他的ではなく、必要に応じて組み合わせて使用することができます。この選択にはベストプラクティスがあります。ただし、まず OpenTelemetry (OTEL) の現状を理解する必要があります。

OTEL は、オブザーバビリティシグナリングにおける現在の業界標準仕様であり、3 つのコアシグナルタイプそれぞれの定義を含んでいます: メトリクス、トレース、ログ。ただし、OTEL は以前から存在していたわけではなく、OpenMetrics や OpenTracing などの以前の仕様から発展してきました。オブザーバビリティベンダーは近年、OpenTelemetry Line Protocol (OTLP) のサポートを公式に開始しています。

AWS X-Ray と CloudWatch は OTEL 仕様よりも以前から存在しており、他の主要なオブザーバビリティソリューションも同様です。ただし、AWS X-Ray サービスは ADOT を使用して OTEL トレースを容易に受け入れます。ADOT には、X-Ray に直接テレメトリを送信するための統合機能がすでに組み込まれており、他の ISV ソリューションへの送信も可能です。

トランザクショントレーシングソリューションには、シグナルを収集するためにエージェントと基盤となるアプリケーションへの統合が必要です。これにより、テスト、メンテナンス、アップグレードが必要なライブラリという形で技術的負債が生じ、さらに将来的にソリューションを変更する場合には再ツール化が必要になる可能性があります。

X-Ray に含まれる SDK は、AWS が提供する緊密に統合されたインストルメンテーションソリューションの一部です。ADOT は、X-Ray が多数のトレーシングソリューションの 1 つに過ぎない、より広範な業界ソリューションの一部です。どちらのアプローチを使用しても X-Ray でエンドツーエンドのトレーシングを実装できますが、最も適切なアプローチを判断するために、両者の違いを理解することが重要です。

備考

以下の場合は、AWS Distro for OpenTelemetry を使用してアプリケーションをインストルメント化することをお勧めします。

• コードを再インストルメント化することなく、複数の異なるトレーシングバックエンドにトレースを送信できる機能。たとえば、X-Ray コンソールから Zipkin への移行を希望する場合、変更が必要なのはコレクターの設定のみであり、アプリケーションコードはそのまま維持されます。

• 各言語向けの多数のライブラリインストルメンテーションのサポート。OpenTelemetry コミュニティによってメンテナンスされています。

備考

以下の場合は、アプリケーションのインストルメンテーションに X-Ray SDK を選択することをお勧めします。

• 緊密に統合されたシングルベンダーソリューション。

• Node.js、Python、Ruby、または .NET を使用する場合、X-Ray コンソールからサンプリングルールを設定し、複数のホストにわたって自動的に使用する機能を含む、X-Ray 集中サンプリングルールとの統合