翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
HTTP エンドポイントを介したログ取り込み
Amazon CloudWatch Logs には、シンプルな HTTP POST リクエストを使用して CloudWatch Logs に直接ログを送信できる HTTP エンドポイントが用意されています。これらのエンドポイントは、SigV4 トークン認証とベアラートークン認証の両方をサポートしています。
重要
AWS SDK 統合が可能なすべての本稼働ワークロードには、SigV4 認証を使用することをお勧めします。SigV4 は短期認証情報を使用し、最も強力なセキュリティ体制を提供します。ベアラートークン (API キー) 認証は、 AWS SDK 統合をサポートしていないサードパーティーのログフォワーダーなど、SigV4 が不可能なシナリオを対象としています。詳細については、IAM ユーザーガイドの「長期アクセスキーの代替」を参照してください。
CloudWatch Logs は、次の HTTP 取り込みエンドポイントをサポートしています。
| Endpoint | パス | Content-Type | 形式 |
|---|---|---|---|
| OpenTelemetry Logs | /v1/logs |
application/json、または application/x-protobuf |
OTLP JSON または Protobuf |
| HLC Logs | /services/collector/event |
application/json |
HLC 形式 |
| ND-JSON Logs | /ingest/bulk |
application/json、または application/x-ndjson |
改行で区切られた JSON |
| Structured JSON Logs | /ingest/json |
application/json |
JSON オブジェクトまたは配列 |
一般的な動作
すべての HTTP 取り込みエンドポイントは、次の動作を共有します。
認証
すべてのエンドポイントは、SigV4 トークン認証とベアラートークン認証の両方をサポートしています。
SigV4 (推奨) – 標準 AWS 署名バージョン 4 の署名。アプリケーションまたはインフラストラクチャが AWS SDK をサポートしている場合、またはリクエストに署名できる場合は常に SigV4 を使用します。SigV4 は短期認証情報を使用し、最も安全な認証方法です。
-
ベアラートークン –
Authorization: Bearer <ACWL token>ヘッダーを使用します。トークンは有効な ACWL ベアラートークンである必要があります。セットアップ手順については、「」を参照してくださいベアラートークン認証の設定。
logs:PutLogEventsおよびlogs:CallWithBearerTokenIAM アクセス許可が必要です。
ロググループとログストリーム
ヘッダー経由で提供:
x-aws-log-groupおよびx-aws-log-streamクエリパラメータ
?logGroup=<name>&logStream=<name>は、OTLP を除くすべてのエンドポイントでもサポートされています。同じパラメータにクエリパラメータとヘッダーの両方を使用することはできません。
ロググループとログストリームの両方が必要です。
レスポンス
成功: 本文
HTTP 200付き{}検証エラー:
HTTP 400認証の失敗:
HTTP 401
HTTP 取り込みエンドポイントの比較
| 機能 | HLC ログ | ND-JSON ログ | 構造化 JSON ログ | OpenTelemetry ログ |
|---|---|---|---|---|
| パス | /services/collector/event |
/ingest/bulk |
/ingest/json |
/v1/logs |
| Content-Type | application/json |
application/json 、、または application/x-ndjson |
application/json |
application/json 、、または application/x-protobuf |
| タイムスタンプフィールド | "time" (秒) |
"timestamp" (ミリ秒) |
"timestamp" (ミリ秒) |
"timeUnixNano" (ナノ秒) |
| 必須フィールド | "event" |
なし | なし | OTLP 構造 ("resourceLogs") |
| 部分的な成功レスポンス | いいえ | はい | はい | はい |
| クエリパラメータのサポート | はい | はい | はい | いいえ (ヘッダーのみ) |
| エンティティメタデータ | はい | はい | あり | なし |
| プリミティブを受け入れます | いいえ | あり | なし | いいえ |
| ラインベースの解析 | いいえ | あり | なし | いいえ |
| Protobuf のサポート | いいえ | なし | なし | はい |
| Retry-After ヘッダー | いいえ | なし | なし | はい |
エンドポイントの選択
HLC 形式を使用しますか? HLC ログを使用します。既存の HLC ペイロードは最小限の変更で機能します。
ストリーミングline-by-lineログ ND-JSON ログを使用します。1 行に 1 つのイベントを出力するログパイプラインに最適です。最も柔軟性が高い — 任意の JSON 値タイプを受け入れます。
構造化された JSON ペイロードを送信しますか? 構造化 JSON ログを使用します。正しい形式の JSON オブジェクトまたは配列を生成するアプリケーションに最適です。
OpenTelemetry を既に使用していますか? OpenTelemetry Logs を使用します。OTLP JSON または Protobuf 形式を受け入れ、再試行セマンティクスを使用した部分的な成功レスポンスをサポートします。
