

# OTLP エンドポイント
<a name="CloudWatch-OTLPEndpoint"></a>

OpenTelemetry Protocol (OTLP) は、OpenTelemetry 用に設計された汎用テレメトリデータ配信プロトコルです。CloudWatch OpenTelemetry エンドポイントは HTTP 1.1 エンドポイントです。オープンテレメトリデータを CloudWatch に送信し始めるように OpenTelemetry コレクターを設定する必要があります。詳細については、「[開始方法](CloudWatch-OTLPGettingStarted.md)」を参照してください。

## ログエンドポイント
<a name="CloudWatch-LogsEndpoint"></a>

ログエンドポイントはパターン `https://logs.{{AWS リージョン}}.amazonaws.com/v1/logs` に従います。たとえば、`US West (Oregon) (us-west-2) Region` の場合、エンドポイントは `https://logs.us-west-2.amazonaws.com/v1/logs` になります。上記のエンドポイントを使用して、既存の `LogGroup` および `LogStream` にログを転送できます。ログデータを取り込むための `LogGroup` の設定の詳細については、「[Amazon CloudWatch Logs の概念](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogsConcepts.html)」を参照してください。

CloudWatch Logs OpenTelemetry エンドポイントを呼び出すときに、`x-aws-log-group` と `x-aws-log-stream` HTTP ヘッダーをそれぞれ `LogGroup` と `LogStream` の名前に設定して、`LogGroup` と `LogStream` を設定する必要があります。詳細については、「[開始方法](CloudWatch-OTLPGettingStarted.md)」を参照してください。エンドポイントは、署名 4 認証を使用して発信者を認証します。詳細については、「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。

ログイベントサイズが 1 MB を超えると、CloudWatch Logs は最大のフィールドから最大 10 個のフィールドに対して自動的に切り捨てを行います。各フィールドは、イベントの合計サイズをできるだけ 1 MB に近づけるために、必要に応じて切り捨てられます。超過部分はラージログオブジェクト (LLO) として保存され、LLO リファレンスシステムフィールドが追加されます。必要に応じて、`x-aws-truncatable-fields `HTTP ヘッダーを設定して、切り捨てる必要があるフィールドパスを指定できます。LLO は `GetLogObject` API を使用して取得およびストリーミングできます。詳細については、「[GetLogObject](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_GetLogObject.html)」を参照してください。1 MB を超えるログイベントと LLO エクスペリエンスのサポートは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (シドニー)、アジアパシフィック (ムンバイ)、米国東部 (オハイオ)、欧州 (アイルランド)、アジアパシフィック (東京)、アジアパシフィック (シンガポール) で利用できます。

## メトリクスエンドポイント
<a name="CloudWatch-MetricsEndpoint"></a>

メトリクスエンドポイントはパターン `https://monitoring.{{AWS Region}}.amazonaws.com/v1/metrics` に従います。たとえば、米国西部 (オレゴン) (us-west-2) リージョンの場合、エンドポイントは `https://monitoring.us-west-2.amazonaws.com/v1/metrics` になります。

CloudWatch へのメトリクスの送信を開始するには、OpenTelemetry コレクターを設定する必要があります。エンドポイントは、署名 4 認証を使用して発信者を認証します。詳細については、「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。

## トレースエンドポイント
<a name="CloudWatch-TracesEndpoint"></a>

トレースエンドポイントはパターン `https://xray.{{AWS Region}}.amazonaws.com/v1/traces` に従います。たとえば、米国西部 (オレゴン) (us-west-2) リージョンの場合、エンドポイントは `https://xray.us-west-2.amazonaws.com/v1/traces` になります。

CloudWatch へのトレースの送信を開始するには、OpenTelemetry コレクターを設定する必要があります。エンドポイントは、署名 4 認証を使用して発信者を認証します。詳細については、「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。

## RUM エンドポイント
<a name="CloudWatch-RUMEndpoint"></a>

RUM エンドポイントはパターン `https://dataplane.rum.{AWS Region}.amazonaws.com/v1/rum` に従います。例えば、米国西部 (オレゴン) リージョンでは、エンドポイントは `https://dataplane.rum.us-west-2.amazonaws.com/v1/rum` です。このエンドポイントは、CloudWatch RUM アプリケーションの*クライアント側のテレメトリデータ* (`eventName` があるトレースとログレコードのみ) を処理します。

このエンドポイントを使用するには、モバイルプラットフォーム (Android/iOS) で [RUM アプリケーションモニター](CloudWatch-RUM-get-started-create-app-monitor.md)を作成し、生成されたコードスニペットを使用してアプリケーションを計測する必要があります。スニペットは、このエンドポイントで設定された RUM モバイル SDK をプルします。SDK をさらに設定して、RUM がそれに応じてテレメトリを収集するようにできます。

エンドポイントは、認証されたリクエストと認証されていないリクエストの両方をサポートします。認証されたリクエストに AWS Signature Version 4 (SigV4) を使用することも、モバイルアプリケーションからの認証されていないアクセスを許可するリソースベースのポリシーを使用することもできます。

SDK で定義されている認証モデルの詳細については、以下を参照してください。
+ iOS アプリケーション - [AWS Distro for OpenTelemetry (ADOT) iOS SDK](https://github.com/aws-observability/aws-otel-swift)。
+ Android アプリケーション - [AWS Distro for OpenTelemetry (ADOT) Android SDK](https://github.com/aws-observability/aws-otel-android)。

## エンドポイントの制限と規制
<a name="CloudWatch-LimitsandRestrictions"></a>

この表は、メトリクス、トレース、およびログの一般的なエンドポイントの制限を示しています。


| 制限 | Endpoint | 追加情報 | 
| --- | --- | --- | 
| 必要なコレクター拡張機能 | [sigv4authextension](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/sigv4authextension) | OTLP エンドポイントにメトリクスまたはトレースを送信するには、sigv4authextension を使用する必要があります | 
| サポートされるプロトコル | HTTP | エンドポイントは HTTP のみをサポートし、gRPC はサポートしません。 | 
| サポートされる OTLP バージョン: | OTLP 1.x |   | 
| ペイロード形式 | バイナリ、JSON | エンドポイントは、バイナリ形式と JSON 形式を使用してリクエストを受け入れます。 | 
| 圧縮方法 | gzip、なし | エンドポイントは gzip のみをサポートし、圧縮メソッドはサポートしません | 

この表は、トレースのエンドポイントの制限の一覧です。


| 制限 | トレースエンドポイント | 追加情報 | 
| --- | --- | --- | 
| 最大非圧縮バイト数/リクエスト | 5 MB | OTLP エンドポイントは、ペイロードが非圧縮の場合、5MB を超えるリクエストを拒否します。 | 
| 最大イベント/リクエスト | 10,000 スパン | バッチの最大スパン数は 10,000 です。この制限を超えると、API コールが拒否されます。 | 
| 単一のリソースとスコープのサイズ | 16 KB | 各一意のリソースと対応するスコープのサイズは 16 KB を超えることはできません。いずれかのリソースに対してこの制限を超えると、API コール全体が拒否されます。 | 
| 単一スパンの最大サイズ | 200 KB | 200KB を超えるスパンはエンドポイントによって拒否されます。 | 
| スパン作成タイムスタンプ | 2 時間先、過去 14 日 | バッチ内のどのスパンも、2 時間以上先または 14 日以上過去にすることはできません。 | 
| イベント/リクエストにおける時間のずれの最大値 | 24 時間 |   | 

この表は、メトリクスのエンドポイントの制限の一覧です。


| 制限 | メトリクスエンドポイント | 追加情報 | エラーコード | 
| --- | --- | --- | --- | 
| 最大 TPS | 500 | アカウントごとに許可されている 1 秒あたりに実行できるリクエストの最大数。 | 429 | 
| 新しい系列の最大作成レート | 1,000,000 | 10 分間に作成できる新しい系列の最大数。この制限は、既存のメトリクスのデータポイントの取り込みではなく、新しいメトリクス名の作成にのみ適用されます。 | 429 - リクエスト内のすべてのメトリクスがスロットリングされます。200 - リクエスト内のメトリクスが部分的にスロットリングされます | 
| 最大リクエストサイズ | 1 MB | リクエストの最大非圧縮サイズ。 | 400 | 
| データポイントの最大数 | 1,000 | 1 回のリクエストで送信されるデータポイントの最大数。この数は、ResourceMetrics、ScopeMetrics、メトリクス全体の合計です。 | 400 | 
| 最大メタデータサイズ | 40 KB | データポイントあたりの系列で許容される、すべてのラベルとラベル値を合わせた最大サイズ。 | 400 - リクエスト内のすべてのメトリクスが無効です。200 - リクエスト内のメトリクスが部分的に無効です | 
| 最大ラベル数 | 150 | データポイントあたりの Resource/Scope/Datapoint 属性全体のラベルの最大数。 | 400 - リクエスト内のすべてのメトリクスが無効です。200 - リクエスト内のメトリクスが部分的に無効です | 

この表は、ログのエンドポイントの制限の一覧です。



- ** 最大非圧縮バイト数/リクエスト**
  - **ログエンドポイント:** 1 MB / **追加情報:** OTLP エンドポイントは、ペイロードが非圧縮の場合、1MB を超えるリクエストを拒否します。<br />最大リクエストサイズは、プロトコルバッファによってシリアル化されたバイナリデータの解凍と逆シリアル化後、1,048,576 バイトです。このサイズは、UTF-8 のすべてのイベントメッセージの合計に各ログイベントにつき 26 バイトを加算して計算されます。
  - **ログエンドポイント:** 20 MB<br />米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (シドニー)、アジアパシフィック (ムンバイ)、米国東部 (オハイオ)、欧州 (アイルランド)、アジアパシフィック (東京)、アジアパシフィック (シンガポール) の各リージョンでのみ利用できます。 / **追加情報:** OTLP ペイロードが解凍され、JSON 形式からデコードされた後、最大リクエストサイズは 20 MB (20,971,520 バイト) です。<br />最大 1 MB のログの場合 – これらのログは、クエリやライブテールを含むすべての CloudWatch Logs 機能にフルアクセスできます。<br />1 MB を超えるログの場合 – 超過部分はラージログオブジェクト (LLO) として処理されます。

- **1 秒あたりのリクエスト数**
  - **ログエンドポイント:** 5000
  - **追加情報:** リージョン、アカウント、1 秒あたり 5000 件のリクエスト。Service Quotas サービスを使用して、1 秒あたりのスロットリングクォータの引き上げをリクエストできます。

- ** 単一のリソースとスコープのサイズ**
  - **ログエンドポイント:** 16 KB
  - **追加情報:** 各一意のリソースと対応するスコープのサイズは 16 KB を超えることはできません。いずれかのリソースに対してこの制限を超えると、API コール全体が拒否されます。

- ** 単一の LogEvent サイズ **
  - **ログエンドポイント:** 1 MB
  - **追加情報:** LogEvent のサイズは、LogRecord、Scope、Resource のサイズの合計として計算されます。このクォータは変更できません。

- **ログ作成のタイムスタンプ**
  - **ログエンドポイント:** 2 時間先、過去 14 日
  - **追加情報:** バッチのログレコードは、時系列の順序である必要はありません。ただし、バッチのログレコードは 2 時間以上先と 14 日以上過去にすることはできません。また、どのログレコードもロググループの保持期間より前にすることはできません。

- ** イベント/リクエストにおける時間のずれの最大値**
  - **ログエンドポイント:** 24 時間
  - **追加情報:**  

- ** 最大イベント/リクエスト**
  - **ログエンドポイント:** 10,000 ログ
  - **追加情報:** バッチの最大ログイベント数は 10,000 です。この制限を超えると、API コールが拒否されます。

- ** 最大ラージログオブジェクト/リクエスト**
  - **ログエンドポイント:** 1 ログレコード<br />米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (シドニー)、アジアパシフィック (ムンバイ)、米国東部 (オハイオ)、欧州 (アイルランド)、アジアパシフィック (東京)、アジアパシフィック (シンガポール) の各リージョンで利用できます。
  - **追加情報:** ログイベント内のコンテンツが 1 MB を超える場合、超過したコンテンツは LLO として保存されます。1 つのリクエストにつき、ログレコードの数は 1 つに制限されます。

- ** 最大ラージログオブジェクト/レコード**
  - **ログエンドポイント:** 10 個の LLO<br />米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト)、アジアパシフィック (シドニー)、アジアパシフィック (ムンバイ)、米国東部 (オハイオ)、欧州 (アイルランド)、アジアパシフィック (東京)、アジアパシフィック (シンガポール) の各リージョンで利用できます。
  - **追加情報:** 1 つのログレコードには、最大 10 個の LLO を含めることができます。



**注記**  
ログのアカウント制限は、SDK と新しいログエンドポイント間で共有されます。