AWS Distro for OpenTelemetry (ADOT)

解決する課題

可観測性（オブザーバビリティ）を整えようとすると、監視ベンダーや送り先ごとに別々のエージェントや SDK を入れることになりがちです。これは次の問題を生みます。

• 送り先を変えるたびにアプリの計装をやり直すことになり、ベンダーロックインに陥る
• メトリクス・トレース・ログでそれぞれ別の仕組みを使い、運用と設定が分散する
• オープンソースの OpenTelemetry をそのまま使うと、バージョン管理やサポートを自前で抱える

AWS Distro for OpenTelemetry（ADOT）は、ベンダー中立な標準である OpenTelemetry を AWS がテスト・検証・サポートして配布するものです。1度の計装で、X-Ray・CloudWatch・Amazon Managed Service for Prometheus など複数の送り先へデータを送れるようにします。

主要概念と用語

• OpenTelemetry（OTel）: メトリクス・トレース・ログを統一的に扱うための、ベンダー中立なオープンソースの可観測性標準
• ディストリビューション: OpenTelemetry 本体を AWS が検証・サポートしてパッケージ化したもの。それが ADOT
• テレメトリの3信号: メトリクス（数値の時系列）、トレース（リクエストの横断的な流れ）、ログ（イベント記録）の総称
• ADOT SDK / 自動計装: 言語ごとのライブラリ。アプリのコードに計装を組み込み、テレメトリを生成する
• ADOT コレクター: 収集（receiver）・加工（processor）・転送（exporter）を担うエージェント。OpenTelemetry Collector をベースにする
• レシーバー / プロセッサー / エクスポーター: コレクターのパイプライン構成要素。受信・変換・送信をそれぞれ担当する
• OTLP: OpenTelemetry Protocol。SDK とコレクター間、コレクター間でテレメトリを運ぶ標準プロトコル
• エクスポーター: 収集したデータを特定の送り先（X-Ray、CloudWatch、Prometheus など）の形式に変換して送る部品

仕様・制限・クォータ

• 主要なプログラミング言語向けの SDK と、コレクターのコンテナ／ディストリビューションが提供される
• 送信先は単一ではなく、X-Ray・CloudWatch（メトリクスやログ）・Amazon Managed Service for Prometheus など複数を同時に設定できる
• コレクターは EC2 上のエージェント、ECS や EKS のサイドカー／デーモン、Lambda のレイヤーなど、さまざまな実行形態で動かせる
• 実際の取り込み量・保持期間・クォータは、送信先となる各サービス側（X-Ray や CloudWatch など）の仕様に従う
• コレクター自体はリージョンをまたいで自由に転送できるが、送り先サービスのリージョン構成に合わせる必要がある

内部の仕組み

アプリに組み込んだ ADOT SDK（または自動計装）が、メトリクス・トレース・ログを生成し、OTLP で ADOT コレクターへ送ります。コレクターは3段のパイプラインで処理します。

• レシーバーで OTLP や Prometheus 形式などのデータを受け取る
• プロセッサーでバッチ化、属性の付与・除去、サンプリングなどの加工を行う
• エクスポーターで X-Ray、CloudWatch、Managed Prometheus など各送り先の形式へ変換して送信する

この構成により、アプリ側の計装は OpenTelemetry のまま固定しつつ、送り先の追加や差し替えはコレクターの設定変更だけで済みます。トレースは X-Ray へ、メトリクスは CloudWatch や Managed Prometheus へ、といった振り分けも1つのコレクターで実現できます。

設計パターン / ベストプラクティス

• コレクターをハブにする: アプリは OTLP でコレクターに送るだけにし、送り先の制御はコレクター設定に集約する
• 実行環境に合わせた配置: EKS ではデーモンセット、ECS ではサイドカー、Lambda ではレイヤー、と環境に応じてコレクターを配置する
• プロセッサーで属性を整える: 環境名やサービス名などの共通属性を付与し、不要なラベルやカーディナリティの高い値は除去する
• サンプリングでトレース量を制御: 重要なリクエストは記録率を上げ、ヘルスチェックなどは記録しないようにしてコストを抑える
• バッチ処理を有効に: バッチプロセッサーで送信をまとめ、送り先 API の呼び出し回数とオーバーヘッドを減らす

運用・監視

• テレメトリが届かない場合は、SDK の計装、コレクターの稼働、エクスポーター設定、IAM 権限を順に確認する
• コレクター自身のヘルスやパイプラインの処理状況を監視し、ドロップやキューの詰まりを早期に検知する
• 送り先が複数あるときは、どのエクスポーターで失敗しているかを切り分ける
• バージョン更新時は、SDK・コレクター・送り先の互換性を確認してから展開する

コスト

• ADOT 自体は OpenTelemetry のディストリビューションであり、課金の中心は送り先サービス側で発生する
• トレースは X-Ray、メトリクスは CloudWatch や Managed Prometheus、ログは CloudWatch Logs の料金体系に従う
• コレクターを EC2 や ECS／EKS で動かす場合は、そのコンピュートリソースのコストがかかる
• サンプリングや高カーディナリティの抑制で、送り先での取り込み量と課金を下げられる

セキュリティ

• コレクターやアプリには IAM ロールを付与し、各送り先への送信権限を最小権限で与える
• Managed Prometheus へ送る場合は **SigV4 署名（IAM 認証）**が必要になる点に注意する
• テレメトリに個人情報や認証情報を載せない。属性やメタデータに機密値を入れないようプロセッサーでマスク・除去する
• 送り先サービス側で保存時の**暗号化（KMS）**が適用される。API 操作の監査は CloudTrail で記録する

関連サービス・比較

トレースの送り先となる AWS X-Ray とよく対比されます。両者は競合ではなく、ADOT が計装と転送、X-Ray が保存と可視化という補完関係です。

ハンズオン / CLI例

# ECS タスク定義に ADOT コレクターをサイドカーとして登録する例
aws ecs register-task-definition \
  --family my-app-with-adot \
  --cli-input-json file://taskdef-with-adot-collector.json

# コレクターからの送信に使う IAM ロールを作成し、必要なポリシーを付与
aws iam create-role \
  --role-name adot-collector-role \
  --assume-role-policy-document file://ecs-trust-policy.json

aws iam attach-role-policy \
  --role-name adot-collector-role \
  --policy-arn arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess

aws iam attach-role-policy \
  --role-name adot-collector-role \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy