# Telemetry API を使用して拡張機能のリアルタイムテレメトリデータにアクセスする
Telemetry API を使用することで、拡張機能はテレメトリデータを Lambda から直接受信できます。Lambda は、関数の初期化および呼び出し中に、ログ、プラットフォームメトリクス、およびプラットフォームトレースなどのテレメトリを自動的に取得します。Telemetry API により、拡張機能はこのテレメトリデータを Lambda からほぼリアルタイムで直接取得できます。
Lambda 実行環境内で、Lambda 拡張機能をテレメトリストリームにサブスクライブできます。サブスクライブ後、Lambda は自動的にすべてのテレメトリデータを拡張機能に送信します。その後、そのデータを処理およびフィルターして、Amazon Simple Storage Service (Amazon S3) バケットや、サードパーティのオブザーバビリティツールプロバイダーなどの目的の宛先に送信することができます。
以下の図は、Extensions API と Telemetry API が、実行環境内から拡張機能を Lambda にリンクする方法を示しています。さらに Runtime API も、ランタイムと関数を Lambda に接続します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
**重要**
Lambda Telemetry API は、Lambda Log API に取って代わる API です。**Logs API は引き続き完全に機能しますが、今後は Telemetry API のみを使用することをお勧めします。**拡張機能は、Telemetry API または Logs API のいずれかを使用して、テレメトリストリームにサブスクライブできます。これらの API のいずれかを使用してサブスクライブした後で、もう一方の API を使用してサブスクライブしようとすると、エラーが返されます。
**Lambda マネージドインスタンススキーマのバージョンの要件**
Lambda マネージドインスタンスは、テレメトリ API の `2025-01-29` スキーマバージョンのみをサポートします。マネージドインスタンス関数のテレメトリストリームにサブスクライブする場合は、サブスクリプションリクエストで `"schemaVersion": "2025-01-29"` を使用する**必要があります**。以前のスキーマバージョンを使用すると、Lambda によってイベントが拒否されます。
`2025-01-29` スキーマバージョンは下位互換性があり、Lambda マネージドインスタンスと Lambda (デフォルト) 関数の両方で使用できます。両方のデプロイモデル間で互換性を確保するために、すべての新しい拡張機能にこのバージョンを使用することをお勧めします。
拡張機能は、Telemetry API を使用して 3 つの異なるテレメトリストリームにサブスクライブできます。
+ **プラットフォームテレメトリ** – 実行環境ランタイムライフサイクル、拡張機能ライフサイクル、および関数の呼び出しに関連するイベントとエラーを説明するログ、メトリクス、およびトレース。
+ **関数ログ** – Lambda 関数コードが生成するカスタムログ。
+ **拡張機能ログ** – Lambda 拡張機能コードが生成するカスタムログ。
**注記**
Lambda は、拡張機能がテレメトリストリームにサブスクライブしている場合でも、ログとメトリクスを CloudWatch に送信し、トレースを X-Ray に送信 (トレーシングをアクティブ化している場合) します。
**Topics**
+ [
## Telemetry API を使用した拡張機能の作成
](#telemetry-api-creating-extensions)
+ [
## 拡張機能の登録
](#telemetry-api-registration)
+ [
## テレメトリリスナーの作成
](#telemetry-api-listener)
+ [
## 宛先プロトコルの指定
](#telemetry-api-destination)
+ [
## メモリの使用量とバッファリングの設定
](#telemetry-api-buffering)
+ [
## Telemetry API へのサブスクリプションリクエストの送信
](#telemetry-api-subscription)
+ [
## インバウンド Telemetry API メッセージ
](#telemetry-api-messages)
+ [
# Lambda Telemetry API リファレンス
](telemetry-api-reference.md)
+ [
# Lambda Telemetry API `Event` スキーマリファレンス
](telemetry-schema-reference.md)
+ [
# Lambda Telemetry API `Event` オブジェクトの OpenTelemetry スパンへの変換
](telemetry-otel-spans.md)
+ [
# Lambda Logs API を使用する
](runtimes-logs-api.md)
## Telemetry API を使用した拡張機能の作成
Lambda 拡張機能は、実行環境で独立したプロセスとして実行されます。拡張機能は、関数の呼び出しが完了した後も引き続き実行できます。拡張機能は別個のプロセスであるため、関数コードとは異なる言語で記述することができます。拡張機能は、Golang や Rust などのコンパイルされた言語を使用して記述することが推奨されます。そうすることで、拡張機能は、サポートされているランタイムとの互換性がある自己完結型のバイナリになります。
以下の図は、Telemetry API を使用してテレメトリデータを受信し、処理する拡張機能を作成するための 4 ステッププロセスを説明しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/telemetry-api-creation-steps.png)
以下は、各ステップの詳しい説明です。
1. [Lambda 拡張機能 API を使用した拡張機能の作成](runtimes-extensions-api.md) を使用して拡張機能を登録します。これによって、この後のステップで必要になる `Lambda-Extension-Identifier` が提供されます。拡張機能の登録方法に関する詳細については、「[拡張機能の登録](#telemetry-api-registration)」を参照してください。
1. テレメトリリスナーを作成します。これは、基本的な HTTP または TCP サーバーにすることができます。Lambda は、テレメトリリスナーの URI を使用してテレメトリデータを拡張機能に送信します。詳細については、「[テレメトリリスナーの作成](#telemetry-api-listener)」を参照してください。
1. Telemetry API 内の Subscribe API を使用して、拡張機能を目的のテレメトリストリームにサブスクライブします。このステップには、テレメトリリスナーの URI が必要になります。詳細については、「[Telemetry API へのサブスクリプションリクエストの送信](#telemetry-api-subscription)」を参照してください。
1. テレメトリリスナー経由で Lambda からテレメトリデータを取得します。このデータには、Amazon S3、または外部のオブザーバビリティサービスへのデータのディスパッチなど、あらゆるカスタム処理を実行できます。
**注記**
Lambda 関数の実行環境は、その[ライフサイクル](runtimes-extensions-api.md#runtimes-extensions-api-lifecycle)の一環として、複数回起動および停止できます。一般的に、拡張機能コードは関数の呼び出し中に実行されるとともに、シャットダウンフェーズ中にも最大 2 秒間実行されます。テレメトリがリスナーに届いた時点でバッチ処理することをお勧めします。次に、`Invoke` および `Shutdown` ライフサイクルイベントを使用して、各バッチを目的の送信先に送信します。
## 拡張機能の登録
テレメトリデータにサブスクライブする前に、Lambda 拡張機能を登録する必要があります。登録は、[拡張機能の初期化フェーズ](runtimes-extensions-api.md#runtimes-extensions-api-reg)中に行われます。以下は、拡張機能を登録するための HTTP リクエストの例です。
```
POST http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register
Lambda-Extension-Name: lambda_extension_name
{
'events': [ 'INVOKE', 'SHUTDOWN']
}
```
リクエストが成功すると、サブスクライバーは HTTP 200 成功レスポンスを受信します。レスポンスヘッダーには、`Lambda-Extension-Identifier` が含まれています。レスポンスボディには、関数のその他のプロパティが含まれています。
```
HTTP/1.1 200 OK
Lambda-Extension-Identifier: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
{
"functionName": "lambda_function",
"functionVersion": "$LATEST",
"handler": "lambda_handler",
"accountId": "123456789012"
}
```
詳細については、「[拡張機能 API リファレンス](runtimes-extensions-api.md#runtimes-extensions-registration-api)」を参照してください。
## テレメトリリスナーの作成
Lambda 拡張機能には、Telemetry API からの受信リクエストを処理するリスナーが必要です。以下のコードは、Golang でのテレメトリリスナーの実装例です。
```
// Starts the server in a goroutine where the log events will be sent
func (s *TelemetryApiListener) Start() (string, error) {
address := listenOnAddress()
l.Info("[listener:Start] Starting on address", address)
s.httpServer = &http.Server{Addr: address}
http.HandleFunc("/", s.http_handler)
go func() {
err := s.httpServer.ListenAndServe()
if err != http.ErrServerClosed {
l.Error("[listener:goroutine] Unexpected stop on Http Server:", err)
s.Shutdown()
} else {
l.Info("[listener:goroutine] Http Server closed:", err)
}
}()
return fmt.Sprintf("http://%s/", address), nil
}
// http_handler handles the requests coming from the Telemetry API.
// Everytime Telemetry API sends log events, this function will read them from the response body
// and put into a synchronous queue to be dispatched later.
// Logging or printing besides the error cases below is not recommended if you have subscribed to
// receive extension logs. Otherwise, logging here will cause Telemetry API to send new logs for
// the printed lines which may create an infinite loop.
func (s *TelemetryApiListener) http_handler(w http.ResponseWriter, r *http.Request) {
body, err := ioutil.ReadAll(r.Body)
if err != nil {
l.Error("[listener:http_handler] Error reading body:", err)
return
}
// Parse and put the log messages into the queue
var slice []interface{}
_ = json.Unmarshal(body, &slice)
for _, el := range slice {
s.LogEventsQueue.Put(el)
}
l.Info("[listener:http_handler] logEvents received:", len(slice), " LogEventsQueue length:", s.LogEventsQueue.Len())
slice = nil
}
```
## 宛先プロトコルの指定
Telemetry API を使用してテレメトリを受信するためにサブスクライブするときは、宛先 URI だけでなく、宛先プロトコルも指定できます。
```
{
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
}
```
Lambda は、テレメトリの受信のために 2 つのプロトコルを受け入れます。
+ **HTTP** (推奨) – Lambda は、テレメトリを JSON 形式のレコードの配列としてローカル HTTP エンドポイント (`http://sandbox.localdomain:${PORT}/${PATH}`) に配信します。`$PATH` パラメータはオプションです。Lambda は HTTP のみをサポートし、HTTPS はサポートしません。Lambda は、POST リクエストを通じてテレメトリを配信します。
+ **TCP** – Lambda は、テレメトリを[改行区切りの JSON (NDJSON) 形式](https://github.com/ndjson/ndjson-spec)で TCP ポートに配信します。
**注記**
TCP ではなく、HTTP を使用することが強く推奨されます。TCP を使用する場合、Lambda プラットフォームはテレメトリをアプリケーションレイヤーにいつ配信するかを確認できません。このため、拡張機能がクラッシュすると、ログが失われる可能性があります。HTTP にこの制限はありません。
サブスクライブしてテレメトリを受信する前に、ローカル HTTP リスナーまたは TCP ポートを確立します。セットアップ中は、以下の点に注意してください。
+ Lambda がログを送信するのは実行環境内の宛先のみです。
+ Lambda は、リスナーがない場合、または POST リクエストにエラーが発生した場合は、テレメトリの送信を再試行します (バックオフも実施)。テレメトリリスナーがクラッシュした場合は、Lambda が実行環境を再起動した後でテレメトリの受信を再開します。
+ Lambda はポート 9001 を予約しています。他のポート番号の制限や推奨事項はありません。
## メモリの使用量とバッファリングの設定
実行環境でのメモリ使用量は、サブスクライバーの数に比例して直線的に増加します。各サブスクリプションがテレメトリデータを格納するために新しいメモリバッファを開始するため、サブスクリプションはメモリリソースを消費します。バッファメモリ使用量は、実行環境の全体的なメモリ消費量の一部としてカウントされます。
Telemetry API を使用してテレメトリを受信するようにサブスクライブするときは、テレメトリデータをバッファして、バッチ形式でサブスクライバーに配信できます。メモリの使用量を最適化できるように、バッファリング設定を指定することが可能です。
```
{
"buffering": {
"maxBytes": 256*1024,
"maxItems": 1000,
"timeoutMs": 100
}
}
```
| パラメータ | 説明 | デフォルトと制限 |
| --- | --- | --- |
| `maxBytes` | メモリでバッファするテレメトリの最大量 (バイト単位)。 | デフォルト: 262,144 最小: 262,144 最大: 1,048,576 |
| `maxItems` | メモリでバッファするイベントの最大数。 | デフォルト: 10,000 最小: 1,000 最大: 10,000 |
| `timeoutMs` | バッチをバッファする最大時間 (ミリ秒単位)。 | デフォルト: 1,000 最小: 25 最大: 30,000 |
バッファーを設定するときは、次の点に注意してください。
+ 入力ストリームのいずれかが閉じられている場合、Lambda はログをフラッシュします。これは、ランタイムがクラッシュした場合などに発生する可能性があります。
+ 各サブスクライバーは、サブスクリプションリクエストで独自のバッファリング設定をカスタマイズできます。
+ バッファリング設定のコンポーネントが `maxBytes` の場合、データを読み取るためのバッファーサイズを決定する際には、受信ペイロードのサイズを `2 * maxBytes + metadataBytes` と想定してください。考慮すべき `metadataBytes` 量を判断するには、以下のメタデータを確認してください。Lambda は、以下のようなメタデータを各レコードに追加します。
```
{
"time": "2022-08-20T12:31:32.123Z",
"type": "function",
"record": "Hello World"
}
```
+ サブスクライバーが着信テレメトリを十分な速さで処理できない場合、あるいは関数コードが大量のログボリュームを生成する場合、Lambda は、メモリ使用率を制限内に収めるためにレコードをドロップする可能性があります。この状況が発生すると、Lambda は `platform.logsDropped` イベントを送信します。
## Telemetry API へのサブスクリプションリクエストの送信
Lambda 拡張機能は、Telemetry API にサブスクリプションリクエストを送信することで、テレメトリデータを受信するためにサブスクライブできます。サブスクリプションリクエストには、拡張機能がサブスクライブするイベントのタイプに関する情報が含まれている必要があります。これに加えて、リクエストには[配信先情報](#telemetry-api-destination)と[バッファリング設定](#telemetry-api-buffering)を含めることができます。
サブスクリプションリクエストを送信する前に、拡張機能 ID (`Lambda-Extension-Identifier`) が必要になります。[Extensions API を使用して拡張機能を登録](#telemetry-api-registration)すると、API レスポンスから拡張機能 ID を取得できます。
サブスクリプションは、[拡張機能の初期化フェーズ](runtimes-extensions-api.md#runtimes-extensions-api-reg)中に行われます。以下は、プラットフォームテレメトリ、関数ログ、および拡張機能ログの 3 つのテレメトリストリームすべてにサブスクライブするための HTTP リクエストの例です。
```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry HTTP/1.1
{
"schemaVersion": "2025-01-29",
"types": [
"platform",
"function",
"extension"
],
"buffering": {
"maxItems": 1000,
"maxBytes": 256*1024,
"timeoutMs": 100
},
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
}
```
リクエストが成功すると、サブスクライバーが HTTP 200 成功レスポンスを受信します。
```
HTTP/1.1 200 OK
"OK"
```
## インバウンド Telemetry API メッセージ
Telemetry API を使用してサブスクライブすると、拡張機能は POST リクエストで Lambda からのテレメトリ受信を自動的に開始します。各 POST リクエスト本文には `Event` オブジェクトの配列が含まれています。それぞれの `Event` には以下のスキーマがあります。
```
{
time: String,
type: String,
record: Object
}
```
+ `time` プロパティは、Lambda プラットフォームがイベントを生成した時刻を定義します。これは、イベントが実際に発生した時刻とは異なります。`time` の文字列値は、ISO 8601 形式のタイムスタンプです。
+ `type` プロパティは、イベントタイプを定義します。以下の表には、可能な値のすべてが説明されています。
+ `record` プロパティは、テレメトリデータが含まれる JSON オブジェクトを定義します。この JSON オブジェクトのスキーマは、`type` に応じて異なります。
**同時呼び出しによるイベントの順序付け**
[Lambda マネージドインスタンスの場合](lambda-managed-instances.md)、同じ実行環境内で複数の関数呼び出しを同時に実行できます。この場合、`platform.start` イベントと `platform.report` イベントの順序は、異なる同時呼び出し間で保証されません。拡張機能は、並行して実行される複数の呼び出しからのイベントを処理する必要があり、シーケンシャル順序を引き受けません。
イベントを特定の呼び出しに適切に属性付けるには、拡張機能はこれらのプラットフォームイベントに存在する `requestId` フィールドを使用する必要があります。各呼び出しには一意のリクエスト ID があり、その呼び出しのすべてのイベントで一貫性が保たれるため、拡張機能はイベントが異なる順序で到着した場合でもイベントを正しく関連付けることができます。
以下の表は、すべての `Event` オブジェクトタイプと、各イベントタイプの [Telemetry API `Event` スキーマリファレンス](telemetry-schema-reference.md)へのリンクをまとめたものです。
| Category | イベントタイプ | 説明 | イベントレコードスキーマ |
| --- | --- | --- | --- |
| プラットフォームイベント | `platform.initStart` | 関数の初期化が開始されました。 | [`platform.initStart`](telemetry-schema-reference.md#platform-initStart) スキーマ |
| プラットフォームイベント | `platform.initRuntimeDone` | 関数の初期化が完了しました。 | [`platform.initRuntimeDone`](telemetry-schema-reference.md#platform-initRuntimeDone) スキーマ |
| プラットフォームイベント | `platform.initReport` | 関数の初期化のレポートです。 | [`platform.initReport`](telemetry-schema-reference.md#platform-initReport) スキーマ |
| プラットフォームイベント | `platform.start` | 関数の呼び出しが開始されました。 | [`platform.start`](telemetry-schema-reference.md#platform-start) スキーマ |
| プラットフォームイベント | `platform.runtimeDone` | ランタイムが、成功または失敗のいずれかでイベントの処理を終了しました。 | [`platform.runtimeDone`](telemetry-schema-reference.md#platform-runtimeDone) スキーマ |
| プラットフォームイベント | `platform.report` | 関数の呼び出しのレポートです。 | [`platform.report`](telemetry-schema-reference.md#platform-report) スキーマ |
| プラットフォームイベント | `platform.restoreStart` | ランタイムの復元が開始されました。 | [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart) スキーマ |
| プラットフォームイベント | `platform.restoreRuntimeDone` | ランタイムの復元が完了しました。 | [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone) スキーマ |
| プラットフォームイベント | `platform.restoreReport` | ランタイムの復元のレポート。 | [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport) スキーマ |
| プラットフォームイベント | `platform.telemetrySubscription` | 拡張機能が Telemetry API にサブスクライブしました。 | [`platform.telemetrySubscription`](telemetry-schema-reference.md#platform-telemetrySubscription) スキーマ |
| プラットフォームイベント | `platform.logsDropped` | Lambda がログエントリをドロップしました。 | [`platform.logsDropped`](telemetry-schema-reference.md#platform-logsDropped) スキーマ |
| 関数ログ | `function` | 関数コードからのログ行です。 | [`function`](telemetry-schema-reference.md#telemetry-api-function) スキーマ |
| 拡張ログ | `extension` | 拡張コードからのログ行です。 | [`extension`](telemetry-schema-reference.md#telemetry-api-extension) スキーマ |
# Lambda Telemetry API リファレンス
Lambda Telemetry API エンドポイントを使用して、拡張機能をテレメトリーストリームにサブスクライブします。Telemetry API エンドポイントは、`AWS_LAMBDA_RUNTIME_API` 環境変数から取得できます。API リクエストを送信するには、API バージョン (`2022-07-01/`) と `telemetry/` を付加します。例えば、次のようになります。
```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```
サブスクリプションレスポンスバージョン `2025-01-29` の OpenAPI Specification (OAS) 定義については、以下を参照してください。
+ **HTTP** – [telemetry-api-http-schema.zip](samples/events_http_schema_v2025_01_29.zip)
+ **TCP** – [telemetry-api-tcp-schema.zip](samples/events_tcp_schema_v2025_01_29.zip)
**Topics**
+ [
## Subscribe
](#telemetry-subscribe-api)
## Subscribe
Lambda 拡張機能は、テレメトリーストリームにサブスクライブするために Subscribe API リクエストを送信できます。
+ **パス** – `/telemetry`
+ **メソッド** – `PUT`
+ **ヘッダー**。
+ `Content-Type`: `application/json`
+ **リクエストボディパラメータ**
+ **schemaVersion**
+ Required: Yes
+ タイプ: 文字列
+ 有効な値: `"2025-01-29"`、`"2022-12-13"`、または `"2022-07-01"`
+ **注:** Lambda マネージドインスタンスには `"2025-01-29"` が必要です。このバージョンは、Lambda (デフォルト) 関数と下位互換性があります。
+ **destination** – テレメトリイベントの宛先とイベント配信のプロトコルを定義する設定。
+ 必須: はい
+ 型: オブジェクト
```
{
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
```
+ **protocol** – Lambda がテレメトリデータを送信するために使用するプロトコル。
+ Required: Yes
+ 型: 文字列
+ 有効な値: `"HTTP"`\$1`"TCP"`
+ **URI** – テレメトリデータの送信先になる URI。
+ Required: Yes
+ タイプ: 文字列
+ 詳細については、「[宛先プロトコルの指定](telemetry-api.md#telemetry-api-destination)」を参照してください。
+ **types** – 拡張機能がサブスクライブするテレメトリのタイプ。
+ 必須: はい
+ 型: 文字列の配列
+ 有効な値: `"platform"`\$1`"function"`\$1`"extension"`
+ **buffering** – イベントバッファリングの設定。
+ 必須: いいえ
+ 型: オブジェクト
```
{
"buffering": {
"maxItems": 1000,
"maxBytes": 256*1024,
"timeoutMs": 100
}
}
```
+ **MaxItems** – メモリでバッファするイベントの最大数。
+ 必須: いいえ
+ タイプ: 整数
+ デフォルト: 1,000
+ 最小: 1,000
+ 最大: 10,000
+ **maxBytes** – メモリでバッファするテレメトリの最大量 (バイト単位)。
+ 必須: いいえ
+ タイプ: 整数
+ デフォルト: 262,144
+ 最小: 262,144
+ 最大: 1,048,576
+ **timeoutMs** - バッチをバッファーする最大時間（ミリ秒単位）。
+ 必須: いいえ
+ タイプ: 整数
+ デフォルト: 1,000
+ 最小: 25
+ 最大: 30,000
+ 詳細については、「[メモリの使用量とバッファリングの設定](telemetry-api.md#telemetry-api-buffering)」を参照してください。
### Subscribe API リクエストの例
```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry HTTP/1.1
{
"schemaVersion": "2025-01-29",
"types": [
"platform",
"function",
"extension"
],
"buffering": {
"maxItems": 1000,
"maxBytes": 256*1024,
"timeoutMs": 100
},
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
}
```
Subscribe リクエストが正常に実行されると、拡張機能が HTTP 200 成功レスポンスを受信します。
```
HTTP/1.1 200 OK
"OK"
```
Subscribe リクエストが失敗すると、拡張機能がエラーレスポンスを受信します。例えば、次のようになります。
```
HTTP/1.1 400 OK
{
"errorType": "ValidationError",
"errorMessage": "URI port is not provided; types should not be empty"
}
```
以下は、拡張機能が受信できる追加のレスポンスコードです。
+ 200 – リクエストが正常に完了しました
+ 202 – リクエストが受理されました。ローカルテスト環境でのサブスクリプションリクエストレスポンス
+ 400 – 不正なリクエスト
+ 500 – サービスエラー
# Lambda Telemetry API `Event` スキーマリファレンス
Lambda Telemetry API エンドポイントを使用して、拡張機能をテレメトリーストリームにサブスクライブします。Telemetry API エンドポイントは、`AWS_LAMBDA_RUNTIME_API` 環境変数から取得できます。API リクエストを送信するには、API バージョン (`2022-07-01/`) と `telemetry/` を付加します。例えば、次のようになります。
```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```
サブスクリプションレスポンスバージョン `2025-01-29` の OpenAPI Specification (OAS) 定義については、以下を参照してください。
+ **HTTP** – [telemetry-api-http-schema.zip](samples/events_http_schema_v2025_01_29.zip)
+ **TCP** – [telemetry-api-tcp-schema.zip](samples/events_tcp_schema_v2025_01_29.zip)
以下の表は、Telemetry API がサポートするすべての `Event` オブジェクトタイプをまとめたものです。
| Category | イベントタイプ | 説明 | イベントレコードスキーマ |
| --- | --- | --- | --- |
| プラットフォームイベント | `platform.initStart` | 関数の初期化が開始されました。 | [`platform.initStart`](#platform-initStart) スキーマ |
| プラットフォームイベント | `platform.initRuntimeDone` | 関数の初期化が完了しました。 | [`platform.initRuntimeDone`](#platform-initRuntimeDone) スキーマ |
| プラットフォームイベント | `platform.initReport` | 関数の初期化のレポートです。 | [`platform.initReport`](#platform-initReport) スキーマ |
| プラットフォームイベント | `platform.start` | 関数の呼び出しが開始されました。 | [`platform.start`](#platform-start) スキーマ |
| プラットフォームイベント | `platform.runtimeDone` | ランタイムが、成功または失敗のいずれかでイベントの処理を終了しました。 | [`platform.runtimeDone`](#platform-runtimeDone) スキーマ |
| プラットフォームイベント | `platform.report` | 関数の呼び出しのレポートです。 | [`platform.report`](#platform-report) スキーマ |
| プラットフォームイベント | `platform.restoreStart` | ランタイムの復元が開始されました。 | [`platform.restoreStart`](#platform-restoreStart) スキーマ |
| プラットフォームイベント | `platform.restoreRuntimeDone` | ランタイムの復元が完了しました。 | [`platform.restoreRuntimeDone`](#platform-restoreRuntimeDone) スキーマ |
| プラットフォームイベント | `platform.restoreReport` | ランタイムの復元のレポート。 | [`platform.restoreReport`](#platform-restoreReport) スキーマ |
| プラットフォームイベント | `platform.telemetrySubscription` | 拡張機能が Telemetry API にサブスクライブしました。 | [`platform.telemetrySubscription`](#platform-telemetrySubscription) スキーマ |
| プラットフォームイベント | `platform.logsDropped` | Lambda がログエントリをドロップしました。 | [`platform.logsDropped`](#platform-logsDropped) スキーマ |
| 関数ログ | `function` | 関数コードからのログ行です。 | [`function`](#telemetry-api-function) スキーマ |
| 拡張ログ | `extension` | 拡張コードからのログ行です。 | [`extension`](#telemetry-api-extension) スキーマ |
**Contents**
+ [
## Telemetry API `Event` オブジェクトタイプ
](#telemetry-api-events)
+ [
### `platform.initStart`
](#platform-initStart)
+ [
### `platform.initRuntimeDone`
](#platform-initRuntimeDone)
+ [
### `platform.initReport`
](#platform-initReport)
+ [
### `platform.start`
](#platform-start)
+ [
### `platform.runtimeDone`
](#platform-runtimeDone)
+ [
### `platform.report`
](#platform-report)
+ [
### `platform.restoreStart`
](#platform-restoreStart)
+ [
### `platform.restoreRuntimeDone`
](#platform-restoreRuntimeDone)
+ [
### `platform.restoreReport`
](#platform-restoreReport)
+ [
### `platform.extension`
](#platform-extension)
+ [
### `platform.telemetrySubscription`
](#platform-telemetrySubscription)
+ [
### `platform.logsDropped`
](#platform-logsDropped)
+ [
### `function`
](#telemetry-api-function)
+ [
### `extension`
](#telemetry-api-extension)
+ [
## 共有オブジェクトタイプ
](#telemetry-api-objects)
+ [
### `InitPhase`
](#InitPhase)
+ [
### `InitReportMetrics`
](#InitReportMetrics)
+ [
### `InitType`
](#InitType)
+ [
### `ReportMetrics`
](#ReportMetrics)
+ [
### `RestoreReportMetrics`
](#RestoreReportMetrics)
+ [
### `RuntimeDoneMetrics`
](#RuntimeDoneMetrics)
+ [
### `Span`
](#Span)
+ [
### `Status`
](#Status)
+ [
### `TraceContext`
](#TraceContext)
+ [
### `TracingType`
](#TracingType)
## Telemetry API `Event` オブジェクトタイプ
このセクションでは、Lambda Telemetry API がサポートする `Event` オブジェクトのタイプについて詳しく説明します。イベントの説明にある疑問符 (`?`) は、その属性がオブジェクト内に存在しない可能性があることを示します。
### `platform.initStart`
`platform.initStart` イベントは、関数の初期化フェーズが開始されたことを示します。`platform.initStart` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.initStart
- record: PlatformInitStart
```
`PlatformInitStart` オブジェクトには以下の属性があります。
+ **functionName** – `String`
+ **functionVersion** – `String`
+ **initializationType** – ``InitType`` オブジェクト
+ **instanceId?** – `String`
+ **instanceMaxMemory?** – `Integer`
+ **phase** – ``InitPhase`` オブジェクト
+ **runtimeVersion?** – `String`
+ **runtimeVersionArn?** – `String`
以下は、タイプ `platform.initStart` の `Event` の例です。
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "nodejs-14.v3",
"runtimeVersionArn": "arn",
"functionName": "myFunction",
"functionVersion": "$LATEST",
"instanceId": "82561ce0-53dd-47d1-90e0-c8f5e063e62e",
"instanceMaxMemory": 256
}
}
```
### `platform.initRuntimeDone`
`platform.initRuntimeDone` イベントは、関数の初期化フェーズが完了したことを示します。`platform.initRuntimeDone` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.initRuntimeDone
- record: PlatformInitRuntimeDone
```
`PlatformInitRuntimeDone` オブジェクトには以下の属性があります。
+ **initializationType** – ``InitType`` オブジェクト
+ **phase** – ``InitPhase`` オブジェクト
+ **status** – ``Status`` オブジェクト
+ **spans?** – ``Span`` オブジェクトのリスト
以下は、タイプ `platform.initRuntimeDone` の `Event` の例です。
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.initRuntimeDone",
"record": {
"initializationType": "on-demand"
"status": "success",
"spans": [
{
"name": "someTimeSpan",
"start": "2022-06-02T12:02:33.913Z",
"durationMs": 70.5
}
]
}
}
```
### `platform.initReport`
`platform.initReport` イベントには、関数の初期化フェーズに関する全体的なレポートが含まれています。`platform.initReport` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.initReport
- record: PlatformInitReport
```
`PlatformInitReport` オブジェクトには以下の属性があります。
+ **errorType?** – 文字列
+ **initializationType** – ``InitType`` オブジェクト
+ **phase** – ``InitPhase`` オブジェクト
+ **metrics** – ``InitReportMetrics`` オブジェクト
+ **spans?** – ``Span`` オブジェクトのリスト
+ **status** – ``Status`` オブジェクト
以下は、タイプ `platform.initReport` の `Event` の例です。
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.initReport",
"record": {
"initializationType": "on-demand",
"status": "success",
"phase": "init",
"metrics": {
"durationMs": 125.33
},
"spans": [
{
"name": "someTimeSpan",
"start": "2022-06-02T12:02:33.913Z",
"durationMs": 90.1
}
]
}
}
```
### `platform.start`
`platform.start` イベントは、関数の呼び出しフェーズが開始されたことを示します。`platform.start` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.start
- record: PlatformStart
```
`PlatformStart` オブジェクトには以下の属性があります。
+ **requestId** – `String`
+ **version?** – `String`
+ **tracing?** – ``TraceContext``
以下は、タイプ `platform.start` の `Event` の例です。
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.start",
"record": {
"requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
"version": "$LATEST",
"tracing": {
"spanId": "54565fb41ac79632",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
}
}
}
```
### `platform.runtimeDone`
`platform.runtimeDone` イベントは、関数の呼び出しフェーズが完了したことを示します。`platform.runtimeDone` `Event` オブジェクトは以下のような形状になっています。
**Lambda マネージドインスタンス**
`platform.runtimeDone` イベントは Lambda マネージドインスタンスではサポートされていません。マネージドインスタンスで実行されている拡張機能は、マネージドインスタンスで `INVOKE` イベントをサブスクライブできないため、このイベントを受信しません。複数の呼び出しを同時に処理できる同時実行モデルにより、拡張機能は、従来の Lambda (デフォルト) 関数で行われている、個々の呼び出しの呼び出し後処理を実行できません。
マネージドインスタンスの場合、通常は `platform.runtimeDone` に含まれる `responseLatency` および `responseDuration` スパンが、代わりに `platform.report` イベントで使用できます。詳細については、「[`platform.report`](#platform-report)」を参照してください。
```
Event: Object
- time: String
- type: String = platform.runtimeDone
- record: PlatformRuntimeDone
```
`PlatformRuntimeDone` オブジェクトには以下の属性があります。
+ **errorType?** – `String`
+ **metrics?** – ``RuntimeDoneMetrics`` オブジェクト
+ **requestId** – `String`
+ **status** – ``Status`` オブジェクト
+ **spans?** – ``Span`` オブジェクトのリスト
+ **tracing?** – ``TraceContext`` オブジェクト
以下は、タイプ `platform.runtimeDone` の `Event` の例です。
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.runtimeDone",
"record": {
"requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
"status": "success",
"tracing": {
"spanId": "54565fb41ac79632",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
},
"spans": [
{
"name": "someTimeSpan",
"start": "2022-08-02T12:01:23:521Z",
"durationMs": 80.0
}
],
"metrics": {
"durationMs": 140.0,
"producedBytes": 16
}
}
}
```
### `platform.report`
`platform.report` イベントには、関数の呼び出しフェーズに関する全体的なレポートが含まれています。`platform.report` `Event` オブジェクトは以下のような形状になっています。
**Lambda マネージドインスタンス**
Lambda マネージドインスタンスの `platform.report` イベントには、Lambda (デフォルト) 関数とは異なるメトリクスとスパンがあります。マネージドインスタンス:
**スパン**: `extensionOverhead` の代わりに `responseLatency` と `responseDuration` が含まれます。同時実行モデルにより、拡張機能がマネージドインスタンスの `INVOKE` イベントにサブスクライブできないため、`extensionOverhead` スパンは使用できません。
**メトリクス**: `durationMs` のみが含まれます。`billedDurationMs`、`initDurationMs`、`maxMemoryUsedMB`、`memorySizeMB` メトリクスは含まれません。これらの呼び出しごとのメトリクスは、同時実行環境には適用されません。リソース使用率メトリクスには、[Lambda マネージドインスタンスのモニタリング](lambda-managed-instances-monitoring.md) または [Lambda Insights](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-insights.html) を使用します。
```
Event: Object
- time: String
- type: String = platform.report
- record: PlatformReport
```
`PlatformReport` オブジェクトには以下の属性があります。
+ **metrics** – ``ReportMetrics`` オブジェクト
+ **requestId** – `String`
+ **spans?** – ``Span`` オブジェクトのリスト
+ **status** – ``Status`` オブジェクト
+ **tracing?** – ``TraceContext`` オブジェクト
以下は、タイプ `platform.report` の `Event` の例です。
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.report",
"record": {
"metrics": {
"billedDurationMs": 694,
"durationMs": 693.92,
"initDurationMs": 397.68,
"maxMemoryUsedMB": 84,
"memorySizeMB": 128
},
"requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
}
}
```
### `platform.restoreStart`
`platform.restoreStart` イベントは、関数の環境復元イベントが開始されたことを示します。環境復元イベントでは、Lambda は環境をゼロから初期化するのではなく、キャッシュされたスナップショットから環境を作成します。詳細については、「[Lambda SnapStart](snapstart.md)」を参照してください。`platform.restoreStart` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.restoreStart
- record: PlatformRestoreStart
```
`PlatformRestoreStart` オブジェクトには以下の属性があります。
+ **functionName** – `String`
+ **functionVersion** – `String`
+ **instanceId?** – `String`
+ **instanceMaxMemory?** – `String`
+ **runtimeVersion?** – `String`
+ **runtimeVersionArn?** – `String`
以下は、タイプ `platform.restoreStart` の `Event` の例です。
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.restoreStart",
"record": {
"runtimeVersion": "nodejs-14.v3",
"runtimeVersionArn": "arn",
"functionName": "myFunction",
"functionVersion": "$LATEST",
"instanceId": "82561ce0-53dd-47d1-90e0-c8f5e063e62e",
"instanceMaxMemory": 256
}
}
```
### `platform.restoreRuntimeDone`
`platform.restoreRuntimeDone` イベントは、関数の環境復元イベントが完了したことを示します。環境復元イベントでは、Lambda は環境をゼロから初期化するのではなく、キャッシュされたスナップショットから環境を作成します。詳細については、「[Lambda SnapStart](snapstart.md)」を参照してください。`platform.restoreRuntimeDone` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.restoreRuntimeDone
- record: PlatformRestoreRuntimeDone
```
`PlatformRestoreRuntimeDone` オブジェクトには以下の属性があります。
+ **errorType?** – `String`
+ **spans?** – ``Span`` オブジェクトのリスト
+ **status** – ``Status`` オブジェクト
以下は、タイプ `platform.restoreRuntimeDone` の `Event` の例です。
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.restoreRuntimeDone",
"record": {
"status": "success",
"spans": [
{
"name": "someTimeSpan",
"start": "2022-08-02T12:01:23:521Z",
"durationMs": 80.0
}
]
}
}
```
### `platform.restoreReport`
`platform.restoreReport` イベントには、関数の復元イベントに関する全体的なレポートが含まれています。`platform.restoreReport` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.restoreReport
- record: PlatformRestoreReport
```
`PlatformRestoreReport` オブジェクトには以下の属性があります。
+ **errorType?** – 文字列
+ **metrics?** – ``RestoreReportMetrics`` オブジェクト
+ **spans?** – ``Span`` オブジェクトのリスト
+ **status** – ``Status`` オブジェクト
以下は、タイプ `platform.restoreReport` の `Event` の例です。
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.restoreReport",
"record": {
"status": "success",
"metrics": {
"durationMs": 15.19
},
"spans": [
{
"name": "someTimeSpan",
"start": "2022-08-02T12:01:23:521Z",
"durationMs": 30.0
}
]
}
}
```
### `platform.extension`
`extension` イベントには、拡張機能コードからのログが含まれています。`extension` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = extension
- record: {}
```
`PlatformExtension` オブジェクトには以下の属性があります。
+ **events** – `String` のリスト
+ **name** – `String`
+ **state** – `String`
以下は、タイプ `platform.extension` の `Event` の例です。
```
{
"time": "2022-10-12T00:02:15.000Z",
"type": "platform.extension",
"record": {
"events": [ "INVOKE", "SHUTDOWN" ],
"name": "my-telemetry-extension",
"state": "Ready"
}
}
```
### `platform.telemetrySubscription`
`platform.telemetrySubscription` イベントには、拡張機能サブスクリプションに関する情報が含まれています。`platform.telemetrySubscription` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.telemetrySubscription
- record: PlatformTelemetrySubscription
```
`PlatformTelemetrySubscription` オブジェクトには以下の属性があります。
+ **name** – `String`
+ **state** – `String`
+ **types** – `String` のリスト
以下は、タイプ `platform.telemetrySubscription` の `Event` の例です。
```
{
"time": "2022-10-12T00:02:35.000Z",
"type": "platform.telemetrySubscription",
"record": {
"name": "my-telemetry-extension",
"state": "Subscribed",
"types": [ "platform", "function" ]
}
}
```
### `platform.logsDropped`
`platform.logsDropped` イベントには、ドロップされたイベントに関する情報が含まれています。関数が短時間に大量のログを出力して Lambda が処理できない場合、Lambda は `platform.logsDropped` イベントを発行します。関数が生成するレートで CloudWatch または Telemetry API にサブスクライブされている拡張機能にログを送信できない場合、Lambda は関数の実行速度が低下するのを防ぐためにログを削除します。`platform.logsDropped` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = platform.logsDropped
- record: PlatformLogsDropped
```
`PlatformLogsDropped` オブジェクトには以下の属性があります。
+ **droppedBytes** – `Integer`
+ **droppedRecords** – `Integer`
+ **reason** – `String`
以下は、タイプ `platform.logsDropped` の `Event` の例です。
```
{
"time": "2022-10-12T00:02:35.000Z",
"type": "platform.logsDropped",
"record": {
"droppedBytes": 12345,
"droppedRecords": 123,
"reason": "Some logs were dropped because the downstream consumer is slower than the logs production rate"
}
}
```
### `function`
`function` イベントには、関数コードからのログが含まれています。`function` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = function
- record: {}
```
`record` フィールドの形式は、関数のログがプレーンテキスト形式か JSON 形式かによって異なります。ログ形式設定オプションの詳細については、「[JSON とプレーンテキストのログフォーマットの設定](monitoring-cloudwatchlogs-logformat.md)」を参照してください。
以下は、ログ形式がプレーンテキストであるタイプ `function` の `Event` 例です。
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "function",
"record": "[INFO] Hello world, I am a function!"
}
```
以下は、ログ形式が JSON であるタイプ `function` の `Event` 例です。
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "function",
"record": {
"timestamp": "2022-10-12T00:03:50.000Z",
"level": "INFO",
"requestId": "79b4f56e-95b1-4643-9700-2807f4e68189",
"message": "Hello world, I am a function!"
}
}
```
**注記**
使用しているスキーマのバージョンが `2022-12-13` バージョンよりも古い場合、関数のログ記録形式が JSON として設定されていても、`"record"` は常に文字列としてレンダリングされます。Lambda マネージドインスタンスの場合は、スキーマバージョン `2025-01-29` を使用する必要があります。
### `extension`
`extension` イベントには、拡張機能コードからのログが含まれています。`extension` `Event` オブジェクトは以下のような形状になっています。
```
Event: Object
- time: String
- type: String = extension
- record: {}
```
`record` フィールドの形式は、関数のログがプレーンテキスト形式か JSON 形式かによって異なります。ログ形式設定オプションの詳細については、「[JSON とプレーンテキストのログフォーマットの設定](monitoring-cloudwatchlogs-logformat.md)」を参照してください。
以下は、ログ形式がプレーンテキストであるタイプ `extension` の `Event` 例です。
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "extension",
"record": "[INFO] Hello world, I am an extension!"
}
```
以下は、ログ形式が JSON であるタイプ `extension` の `Event` 例です。
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "extension",
"record": {
"timestamp": "2022-10-12T00:03:50.000Z",
"level": "INFO",
"requestId": "79b4f56e-95b1-4643-9700-2807f4e68189",
"message": "Hello world, I am an extension!"
}
}
```
**注記**
使用しているスキーマのバージョンが `2022-12-13` バージョンよりも古い場合、関数のログ記録形式が JSON として設定されていても、`"record"` は常に文字列としてレンダリングされます。Lambda マネージドインスタンスの場合は、スキーマバージョン `2025-01-29` を使用する必要があります。
## 共有オブジェクトタイプ
このセクションでは、Lambda Telemetry API がサポートする共有オブジェクトのタイプについて詳しく説明します。
### `InitPhase`
初期化ステップが行われるフェーズを記述する文字列列挙です。ほとんどの場合、Lambda は `init` フェーズ中に関数の初期化コードを実行しますが、一部のエラーケースでは、Lambda が `invoke` フェーズ中に関数の初期化コードを再実行する場合があります。(これは、*抑制された初期化*と呼ばれます。)
+ **型** – `String`
+ **有効な値** – `init`\$1`invoke`\$1`snap-start`
### `InitReportMetrics`
初期化フェーズに関するメトリクスが含まれたオブジェクトです。
+ **型** – `Object`
`InitReportMetrics` オブジェクトは以下のように形成されています。
```
InitReportMetrics: Object
- durationMs: Double
```
以下は、`InitReportMetrics` オブジェクトの例です。
```
{
"durationMs": 247.88
}
```
### `InitType`
Lambda が環境を初期化した方法を記述する文字列列挙です。
+ **型** – `String`
+ **有効な値** – `on-demand`\$1`provisioned-concurrency`
### `ReportMetrics`
完了したフェーズに関するメトリクスが含まれるオブジェクトです。
+ **型** – `Object`
`ReportMetrics` オブジェクトは以下のように形成されています。
```
ReportMetrics: Object
- billedDurationMs: Integer
- durationMs: Double
- initDurationMs?: Double
- maxMemoryUsedMB: Integer
- memorySizeMB: Integer
- restoreDurationMs?: Double
```
以下は、`ReportMetrics` オブジェクトの例です。
```
{
"billedDurationMs": 694,
"durationMs": 693.92,
"initDurationMs": 397.68,
"maxMemoryUsedMB": 84,
"memorySizeMB": 128
}
```
### `RestoreReportMetrics`
完了した復元フェーズに関するメトリクスが含まれるオブジェクトです。
+ **型** – `Object`
`RestoreReportMetrics` オブジェクトは以下のように形成されています。
```
RestoreReportMetrics: Object
- durationMs: Double
```
以下は、`RestoreReportMetrics` オブジェクトの例です。
```
{
"durationMs": 15.19
}
```
### `RuntimeDoneMetrics`
呼び出しフェーズに関するメトリクスが含まれるオブジェクトです。
+ **型** – `Object`
`RuntimeDoneMetrics` オブジェクトは以下のように形成されています。
```
RuntimeDoneMetrics: Object
- durationMs: Double
- producedBytes?: Integer
```
以下は、`RuntimeDoneMetrics` オブジェクトの例です。
```
{
"durationMs": 200.0,
"producedBytes": 15
}
```
### `Span`
スパンに関する詳細情報が含まれるオブジェクトです。スパンは、トレース内の作業または操作の単位を表します。スパンの詳細については、OpenTelemetry Docs ウェブサイトの「**Tracing API**」ページにある「[Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span)」(スパン) を参照してください。
Lambda は、`platform.RuntimeDone` イベントに対して次のスパンをサポートしています。
+ `responseLatency` スパンは、Lambda 関数がレスポンスの送信を開始するまでにかかった時間を表します。
+ `responseDuration` スパンは、Lambda 関数がレスポンス全体の送信を完了するまでにかかった時間を表します。
+ `runtimeOverhead` スパンは、Lambda ランタイムが次の関数呼び出しを処理する準備ができたことを通知するまでにかかった時間を表します。これは、関数のレスポンスを返した後に、次のイベントを取得するための[次の呼び出し](runtimes-api.md#runtimes-api-next) API をランタイムが呼び出すまでにかかった時間です。
以下は、`responseLatency` スパンオブジェクトの例です。
```
{
"name": "responseLatency",
"start": "2022-08-02T12:01:23.521Z",
"durationMs": 23.02
}
```
### `Status`
初期化または呼び出しフェーズのステータスを記述するオブジェクトです。ステータスが `failure` または `error` の場合、`Status` オブジェクトにはエラーを記述する `errorType` フィールドも含まれています。
+ **型** – `Object`
+ **有効なステータス値** – `success`\$1`failure`\$1`error`\$1`timeout`
### `TraceContext`
トレースのプロパティを記述するオブジェクトです。
+ **型** – `Object`
`TraceContext` オブジェクトは以下のように形成されています。
```
TraceContext: Object
- spanId?: String
- type: TracingType enum
- value: String
```
以下は、`TraceContext` オブジェクトの例です。
```
{
"spanId": "073a49012f3c312e",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
}
```
### `TracingType`
``TraceContext`` オブジェクト内のトレーシングのタイプを記述する文字列列挙です。
+ **型** – `String`
+ **有効な値** – `X-Amzn-Trace-Id`
# Lambda Telemetry API `Event` オブジェクトの OpenTelemetry スパンへの変換
AWS Lambda Telemetry API スキーマには OpenTelemetry (OTel) との意味的な互換性があります。これは、AWS Lambda Telemetry API `Event` オブジェクトを OpenTelemetry (OTel) スパンに変換できることを意味します。変換するときは、単一の `Event` オブジェクトを単一の OTel スパンにマップしないようにしてください。その代わりに、ライフサイクルフェーズに関連する 3 つのイベントすべてを 単一の OTel スパンで提示する必要があります。例えば、`start`、`runtimeDone`、および `runtimeReport` イベントは、単一の関数呼び出しを表します。これら 3 つのイベントのすべてを単一の OTel スパンとして提示します。
イベントは、スパンイベントまたは子 (ネストされた) スパンを使用して変換できます。このページの表には、両方のアプローチに関する Telemetry API スキーマプロパティと OTel スパンプロパティ間のマッピングが説明されています。OTel スパンの詳細については、OpenTelemetry Docs ウェブサイトの「**Tracing API**」ページにある「[Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span)」(スパン) を参照してください。
**Topics**
+ [
## スパンイベントを使用して OTel スパンにマップする
](#telemetry-otel-span-events)
+ [
## 子スパンを使用して OTel スパンにマップする
](#telemetry-otel-child-spans)
## スパンイベントを使用して OTel スパンにマップする
以下の表にある `e` は、テレメトリソースからのイベントを表しています。
**\$1Start イベントのマッピング**
| OpenTelemetry | Lambda Telemetry API スキーマ |
| --- | --- |
| `Span.Name` | 拡張機能は、`type` フィールドに基づいてこの値を生成します。 |
| `Span.StartTime` | `e.time` を使用します。 |
| `Span.EndTime` | イベントがまだ完了していないことから、該当するものはありません。 |
| `Span.Kind` | `Server` に設定します。 |
| `Span.Status` | `Unset` に設定します。 |
| `Span.TraceId` | `e.tracing.value` にある AWS X-Ray ヘッダーを解析してから、`TraceId` 値を使用します。 |
| `Span.ParentId` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Parent` 値を使用します。 |
| `Span.SpanId` | 利用できる場合は、`e.tracing.spanId` を使用します。利用できない場合は、新しい `SpanId` を生成します。 |
| `Span.SpanContext.TraceState` | X-Ray トレースコンテキストについては、該当するものはありません。 |
| `Span.SpanContext.TraceFlags` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Sampled` 値を使用します。 |
| `Span.Attributes` | 拡張機能は、ここに任意のカスタム値を追加できます。 |
**\$1RuntimeDone イベントのマッピング**
| OpenTelemetry | Lambda Telemetry API スキーマ |
| --- | --- |
| `Span.Name` | 拡張機能は、`type` フィールドに基づいて値を生成します。 |
| `Span.StartTime` | 一致する `*Start` イベントからの `e.time` を使用します。 または、`e.time - e.metrics.durationMs` を使用します。 |
| `Span.EndTime` | イベントがまだ完了していないことから、該当するものはありません。 |
| `Span.Kind` | `Server` に設定します。 |
| `Span.Status` | `e.status` が `success` ではない場合は、`Error` に設定します。 それ以外の場合は、`Ok` に設定します。 |
| `Span.Events[]` | `e.spans[]` を使用します。 |
| `Span.Events[i].Name` | `e.spans[i].name` を使用します。 |
| `Span.Events[i].Time` | `e.spans[i].start` を使用します。 |
| `Span.TraceId` | `e.tracing.value` にある AWS X-Ray ヘッダーを解析してから、`TraceId` 値を使用します。 |
| `Span.ParentId` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Parent` 値を使用します。 |
| `Span.SpanId` | `*Start` イベントからのものと同じ `SpanId` を使用します。利用できない場合は、`e.tracing.spanId` を使用するか、新しい `SpanId` を生成します。 |
| `Span.SpanContext.TraceState` | X-Ray トレースコンテキストについては、該当するものはありません。 |
| `Span.SpanContext.TraceFlags` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Sampled` 値を使用します。 |
| `Span.Attributes` | 拡張機能は、ここに任意のカスタム値を追加できます。 |
**\$1Report イベントのマッピング**
| OpenTelemetry | Lambda Telemetry API スキーマ |
| --- | --- |
| `Span.Name` | 拡張機能は、`type` フィールドに基づいて値を生成します。 |
| `Span.StartTime` | 一致する `*Start` イベントからの `e.time` を使用します。 または、`e.time - e.metrics.durationMs` を使用します。 |
| `Span.EndTime` | `e.time` を使用します。 |
| `Span.Kind` | `Server` に設定します。 |
| `Span.Status` | `*RuntimeDone` イベントと同じ値を使用します。 |
| `Span.TraceId` | `e.tracing.value` にある AWS X-Ray ヘッダーを解析してから、`TraceId` 値を使用します。 |
| `Span.ParentId` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Parent` 値を使用します。 |
| `Span.SpanId` | `*Start` イベントからのものと同じ `SpanId` を使用します。利用できない場合は、`e.tracing.spanId` を使用するか、新しい `SpanId` を生成します。 |
| `Span.SpanContext.TraceState` | X-Ray トレースコンテキストについては、該当するものはありません。 |
| `Span.SpanContext.TraceFlags` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Sampled` 値を使用します。 |
| `Span.Attributes` | 拡張機能は、ここに任意のカスタム値を追加できます。 |
## 子スパンを使用して OTel スパンにマップする
以下の表には、`*RuntimeDone` スパンの子 (ネストされた) スパンを使用して、Lambda Telemetry API イベントを OTel スパンに変換する方法が説明されています。`*Start` および `*Report` マッピングについては、これらは子スパンでも同様であるため、[スパンイベントを使用して OTel スパンにマップする](#telemetry-otel-span-events) の表を参照してください。この表の `e` は、テレメトリソースからのイベントを表しています。
**\$1RuntimeDone イベントのマッピング**
| OpenTelemetry | Lambda Telemetry API スキーマ |
| --- | --- |
| `Span.Name` | 拡張機能は、`type` フィールドに基づいて値を生成します。 |
| `Span.StartTime` | 一致する `*Start` イベントからの `e.time` を使用します。 または、`e.time - e.metrics.durationMs` を使用します。 |
| `Span.EndTime` | イベントがまだ完了していないことから、該当するものはありません。 |
| `Span.Kind` | `Server` に設定します。 |
| `Span.Status` | `e.status` が `success` ではない場合は、`Error` に設定します。 それ以外の場合は、`Ok` に設定します。 |
| `Span.TraceId` | `e.tracing.value` にある AWS X-Ray ヘッダーを解析してから、`TraceId` 値を使用します。 |
| `Span.ParentId` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Parent` 値を使用します。 |
| `Span.SpanId` | `*Start` イベントからのものと同じ `SpanId` を使用します。利用できない場合は、`e.tracing.spanId` を使用するか、新しい `SpanId` を生成します。 |
| `Span.SpanContext.TraceState` | X-Ray トレースコンテキストについては、該当するものはありません。 |
| `Span.SpanContext.TraceFlags` | `e.tracing.value` にある X-Ray ヘッダーを解析してから、`Sampled` 値を使用します。 |
| `Span.Attributes` | 拡張機能は、ここに任意のカスタム値を追加できます。 |
| `ChildSpan[i].Name` | `e.spans[i].name` を使用します。 |
| `ChildSpan[i].StartTime` | `e.spans[i].start` を使用します。 |
| `ChildSpan[i].EndTime` | `e.spans[i].start + e.spans[i].durations` を使用します。 |
| `ChildSpan[i].Kind` | 親 `Span.Kind` と同じ。 |
| `ChildSpan[i].Status` | 親 `Span.Status` と同じ。 |
| `ChildSpan[i].TraceId` | 親 `Span.TraceId` と同じ。 |
| `ChildSpan[i].ParentId` | 親 `Span.SpanId` を使用します。 |
| `ChildSpan[i].SpanId` | 新しい `SpanId` を生成します。 |
| `ChildSpan[i].SpanContext.TraceState` | X-Ray トレースコンテキストについては、該当するものはありません。 |
| `ChildSpan[i].SpanContext.TraceFlags` | 親 `Span.SpanContext.TraceFlags` と同じ。 |
# Lambda Logs API を使用する
**重要**
Lambda Telemetry API は、Lambda Log API に取って代わる API です。**Logs API は引き続き完全に機能しますが、今後は Telemetry API のみを使用することをお勧めします。**拡張機能は、Telemetry API または Logs API のいずれかを使用して、テレメトリストリームにサブスクライブできます。これらの API のいずれかを使用してサブスクライブした後で、もう一方の API を使用してサブスクライブしようとすると、エラーが返されます。
**Lambda マネージドインスタンスは Logs API をサポートしていない**
Lambda マネージドインスタンスは Logs API をサポートしていません。マネージドインスタンス関数を使用している場合は、代わりに [Telemetry API](telemetry-api.md) を使用します。Telemetry API は、Lambda 関数からテレメトリデータを収集および処理するための拡張機能を提供します。
Lambda は、ランタイムログを自動的にキャプチャし、Amazon CloudWatch にストリームします 。このログストリームには、 関数コードと拡張機能が生成するログと、Lambda が関数呼び出しの一部として生成するログが含まれます。
[Lambda の拡張機能](runtimes-extensions-api.md)では、Lambda ランタイムログ API を使用して、Lambda [実行環境](lambda-runtime-environment.md)で直接ログストリームをサブスクライブできます。Lambda は、ログを拡張機能にストリームし、拡張機能は、ログを処理、フィルタリングして、指定された宛先に送信します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/logs-api-concept-diagram.png)
Logs API を使用すると、拡張機能は 3 つの異なるログストリームにサブスクライブできます。
+ Lambda 関数が生成して、`stdout` または `stderr` に書き込む関数ログ。
+ 拡張コードが生成する拡張ログ。
+ Lambda プラットフォームログ。呼び出しと拡張機能に関連するイベントとエラーを記録します。
**注記**
Lambda は拡張機能が 1 つまたは複数のログストリームにサブスクライブしている場合でも、すべてのログを CloudWatch に送信します。
**Topics**
+ [
## サブスクライブしてログを受信する
](#runtimes-logs-api-subscribing)
+ [
## メモリ使用量
](#runtimes-logs-api-memory)
+ [
## 送信先プロトコル
](#runtimes-logs-api-dest)
+ [
## バッファリング構成
](#runtimes-logs-api-buffering)
+ [
## サブスクリプションの例
](#runtimes-logs-api-subs-example)
+ [
## ログ API のサンプルコード
](#runtimes-logs-api-samples)
+ [
## Logs API リファレンス
](#runtimes-logs-api-ref)
+ [
## ログメッセージ
](#runtimes-logs-api-msg)
## サブスクライブしてログを受信する
Lambda 拡張機能は、Logs API にサブスクリプションリクエストを送信することで、ログを受信するようサブスクライブできます。
ログを受信するためにサブスクライブするには、内線識別子（`Lambda-Extension-Identifier`）が必要です。最初に [ 内線番号を登録 ](runtimes-extensions-api.md#extensions-registration-api-a) し、内線番号を受け取ります。そして [ 初期化中 ](lambda-runtime-environment.md#runtimes-lifecycle-ib) に Logs API にサブスクライブします。初期化フェーズの完了後は、Lambda はサブスクリプションリクエストを処理しません。
**注記**
Logs API サブスクリプションは冪等です。サブスクリプションリクエストが重複しても、サブスクリプションが重複することはありません。
## メモリ使用量
サブスクライバの数が増加すると、メモリ使用量は直線的に増加します。サブスクリプションは、各サブスクリプションが新しいメモリバッファを開き、ログを保存するため、メモリリソースを消費します。メモリ使用量を最適化するために、[ バッファリング設定 ](#runtimes-logs-api-buffering) を調整できます。バッファメモリ使用量は、実行環境の全体的なメモリ消費量の一部としてカウントされます。
## 送信先プロトコル
ログを受信するには、次のいずれかのプロトコルを選択できます。
1. **HTTP** (推奨) - Lambda は JSON 形式の記録の配列として、ローカル HTTP エンドポイント (`http://sandbox.localdomain:${PORT}/${PATH}`) にログを配信します。`$PATH` パラメータはオプションです。HTTP のみがサポートされ、HTTPS はサポートされません。ログを受信するには、PUT または POST のいずれかを選択できます。
1. **TCP** - Lambda は[改行区切りの JSON (NDJSON) 形式](https://github.com/ndjson/ndjson-spec)で TCPポートにログを配信します。
TCP ではなく HTTP を使用することをお勧めします。TCP では、Lambda プラットフォームはログをアプリケーション層に配信するときに確認できません。したがって、拡張機能がクラッシュすると、ログが失われる可能性があります。HTTP はこの制限を共有しません。
また、サブスクライブしてログを受信する前に、ローカル HTTP リスナーまたは TCP ポートを設定することをお勧めします。セットアップ中に、次の点に注意してください。
+ Lambda は、実行環境内の送信先にのみログを送信します。
+ Lambda は、リスナーがない場合、または POST や PUT リクエストの結果でエラーが発生した場合は、ログ送信の試行を再試行します (バックオフあり)。ログサブスクライバーがクラッシュした場合、Lambda が実行環境を再起動した後もログを受信し続けます。
+ Lambda がポート 9001 を予約しています。他のポート番号の制限や推奨事項はありません。
## バッファリング構成
Lambda はログをバッファリングし、サブスクライバに配信できます。サブスクリプションリクエストでこの動作を設定するには、次のオプションフィールドを指定します。Lambda では、指定しないフィールドにはデフォルト値が使用されます。
+ **timeoutMs** - バッチをバッファーする最大時間（ミリ秒単位）。デフォルト: 1,000。最小: 25 最大: 30,000。
+ **maxBytes** - メモリにバッファするログの最大サイズ （バイト単位）。デフォルト: 262,144。最小: 262,144。最大: 1,048,576。
+ **MaxItems** - メモリにバッファするイベントの最大数。デフォルト: 10,000。最小: 1,000。最大: 10,000。
バッファリングの設定時には、次の点に注意してください。
+ Lambda は、ランタイムがクラッシュした場合など、入力ストリームが閉じられている場合、ログをフラッシュします。
+ 各サブスクライバーは、サブスクリプションリクエストで異なるバッファリング設定を指定できます。
+ データを読み取るために必要なバッファサイズを考慮してください。サブスクライブリクエストで設定されている `2*maxBytes+metadata` と同じ大きさのペイロード `maxBytes` を受信することを想定します。例えば、Lambda は次のメタデータバイトを各レコードに追加します。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "function",
"record": "Hello World"
}
```
+ サブスクライバが着信ログを十分な速さで処理できない場合、Lambda はログを削除して、メモリ使用率を制限し続ける可能性があります。削除されたレコードの数を示すために、Lambda は `platform.logsDropped` ログを送信します。詳細については、「[Lambda: 関数のログの一部が表示されない](troubleshooting-execution.md#troubleshooting-execution-missinglogs)」を参照してください。
## サブスクリプションの例
次の例は、プラットフォームログと関数ログをサブスクライブするリクエストを示しています。
```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs HTTP/1.1
{ "schemaVersion": "2020-08-15",
"types": [
"platform",
"function"
],
"buffering": {
"maxItems": 1000,
"maxBytes": 262144,
"timeoutMs": 100
},
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080/lambda_logs"
}
}
```
リクエストが成功すると、サブスクライバーは HTTP 200 成功レスポンスを受信します。
```
HTTP/1.1 200 OK
"OK"
```
## ログ API のサンプルコード
カスタム送信先にログを送信する方法を示すサンプルコードについては、AWS Lambda コンピューティングブログの [AWS 拡張機能を使用してログをカスタム送信先に送信する](https://aws.amazon.com/blogs/compute/using-aws-lambda-extensions-to-send-logs-to-custom-destinations/)を参照してください。
基本的な Lambda 拡張機能を開発し、Logs API をサブスクライブする方法を示す Python および Go のコードサンプルについては、AWS Samples GitHub リポジトリの [AWS LambdaExtensions](https://github.com/aws-samples/aws-lambda-extensions) を参照してください。Lambda 拡張機能の構築 に関する詳細については、[Lambda 拡張機能 API を使用した拡張機能の作成](runtimes-extensions-api.md) を参照してください。
## Logs API リファレンス
Logs API エンドポイントの値は、`AWS_LAMBDA_RUNTIME_API` の環境変数から取得できます。API リクエストを送信するには、API パスの前にプレフィックス `2020-08-15/` を使用します。以下に例を示します。
```
http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs
```
Log API の OpenAPI 仕様 (バージョン **2020-08-15**) は、[logs-api-request.zip](samples/logs-api-request.zip) から入手できます。
### Subscribe
Lambda 実行環境で使用できる 1 つ以上のログストリームをサブスクライブするために、拡張機能が Subscribe API リクエストを送信します。
**パス** – `/logs`
**メソッド** – **PUT**
**Body パラメータ**
`destination`「」を参照してください。[送信先プロトコル](#runtimes-logs-api-dest)必須: はい。タイプ:文字列。
`buffering`「」を参照してください。[バッファリング構成](#runtimes-logs-api-buffering)必須: いいえ。タイプ:文字列。
`types` - 受信するログのタイプの配列。必須: はい。タイプ: 文字列の配列 有効な値：「プラットフォーム」、「関数」、「拡張」。
`schemaVersion` - 必須: いいえ。デフォルト値: "2020-08-15"。拡張機能が [`platform.runtimeDone`](#runtimes-logs-api-ref-done) メッセージを受信するには、「2021-03-18」に設定します。
****レスポンスパラメータ****
サブスクリプションレスポンスの OpenAPI 仕様 (バージョン **2020-08-15**) は、HTTP および TCP プロトコルで使用できます。
+ HTTP: [ logs-api-http-response.zip ](samples/logs-api-http-response.zip)
+ TCP: [ logs-api-tcp-response.zip ](samples/logs-api-tcp-response.zip)
****レスポンスコード****
+ 200 - リクエストは正常に完了しました
+ 202 - リクエストは承認されました ローカルテスト中のサブスクリプションリクエストへのレスポンス。
+ 4XX - 無効なリクエスト
+ 500 - サービスエラー
リクエストが成功すると、サブスクライバーは HTTP 200 成功レスポンスを受信します。
```
HTTP/1.1 200 OK
"OK"
```
リクエストが失敗した場合、サブスクライバはエラーレスポンスを受信します。以下に例を示します。
```
HTTP/1.1 400 OK
{
"errorType": "Logs.ValidationError",
"errorMessage": URI port is not provided; types should not be empty"
}
```
## ログメッセージ
Logs API を使用すると、拡張機能は 3 つの異なるログストリームにサブスクライブできます。
+ 関数 - Lambda 関数が生成し、`stdout` または `stderr` に書き出すログ。
+ 拡張機能 - 拡張コードが生成するログ。
+ プラットフォーム - ランタイムプラットフォームが生成するログ。呼び出しと拡張機能に関連するイベントおよびエラーを記録します。
**Topics**
+ [
### 関数ログ
](#runtimes-logs-api-msg-function)
+ [
### 拡張ログ
](#runtimes-logs-api-msg-extension)
+ [
### プラットフォームログ
](#runtimes-logs-api-msg-platform)
### 関数ログ
Lambda 関数と内部拡張機能は、関数ログを生成し、`stdout` または `stderr` に書き出します。
次の例は、関数ログメッセージの形式を示しています。 \$1 "time": "2020-08-20T12:31:32.123Z", "type": "function", "record": "ERROR encountered。Stack trace:\$1n\$1my-function (line 10)\$1n" \$1
### 拡張ログ
拡張機能は、拡張ログを生成できます。ログ形式は、関数ログの場合と同じです。
### プラットフォームログ
Lambda は、`platform.start`、`platform.end`、`platform.fault` などのプラットフォームイベントのログメッセージを生成します。
必要に応じて、`platform.runtimeDone` ログメッセージを含む Logs API スキーマの **2021-03-18** バージョンをサブスクライブできます。
#### プラットフォームログメッセージ例
次の例は、プラットフォームの開始ログと終了ログを示しています。これらのログは、requestId で指定された呼び出しの開始時刻と呼び出しの終了時刻を示します。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.start",
"record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"}
}
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.end",
"record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"}
}
```
**platform.initRuntimeDone** ログメッセージには、[初期化ライフサイクルフェーズ](lambda-runtime-environment.md#runtimes-lifecycle-ib)の一部である `Runtime init` サブフェーズのステータスが表示されます。`Runtime init` が正常に実行されると、ランタイムが `/next` Runtime API リクエスト (`on-demand` および `provisioned-concurrency` 初期化タイプの場合)、または `restore/next` (`snap-start` 初期化タイプの場合) を送信します。以下は、`snap-start` 初期化タイプに関する、正常に実行された **Platform.InitRuntimedOne** ログメッセージの例です。
```
{
"time":"2022-07-17T18:41:57.083Z",
"type":"platform.initRuntimeDone",
"record":{
"initializationType":"snap-start",
"status":"success"
}
}
```
**platform.initReport** ログメッセージには、`Init` フェーズの継続時間と、このフェーズ中に料金が請求されたミリ秒数が表示されます。初期化タイプが `provisioned-concurrency` の場合、Lambda は呼び出し中にこのメッセージを送信します。初期化タイプが `snap-start` の場合、Lambda はスナップショットの復元後にこのメッセージを送信します。以下は、`snap-start` 初期化タイプに関する **platform.initReport** ログメッセージの例です。
```
{
"time":"2022-07-17T18:41:57.083Z",
"type":"platform.initReport",
"record":{
"initializationType":"snap-start",
"metrics":{
"durationMs":731.79,
"billedDurationMs":732
}
}
}
```
プラットフォームレポートログには、requestId で指定された呼び出しに関するメトリックが含まれます。呼び出しにコールドスタートが含まれている場合にのみ、`initDurationMs` フィールドがログに含まれます。AWS X-Ray トレースがアクティブである場合、ログには X-Ray メタデータが含まれます。次の例は、コールドスタートを含む呼び出しのプラットフォームレポートログを示しています。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.report",
"record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56",
"metrics": {"durationMs": 101.51,
"billedDurationMs": 300,
"memorySizeMB": 512,
"maxMemoryUsedMB": 33,
"initDurationMs": 116.67
}
}
}
```
プラットフォーム障害ログは、ランタイムまたは実行環境エラーをキャプチャします。次の例は、プラットフォーム障害ログメッセージを示しています。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.fault",
"record": "RequestId: d783b35e-a91d-4251-af17-035953428a2c Process exited before completing request"
}
```
**注記**
AWS は現在、Lambda サービスに変更を実装しています。これらの変更により、AWS アカウント のさまざまな Lambda 関数によって出力されるシステムログメッセージとトレースセグメントの構造と内容にわずかな違いが生じる場合があります。
この変更の影響を受けるログ出力の 1 つは、プラットフォームの障害ログ `"record"` フィールドです。次の例は、古い形式と新しい形式での `"record"` フィールドの例を示しています。新しいスタイルの障害ログには、より簡潔なメッセージが含まれています。
これらの変更は今後数週間に実装され、中国および GovCloud リージョンを除くすべての AWS リージョンのすべての関数は、新しい形式のログメッセージとトレースセグメントを使用するように移行されます。
**Example プラットフォーム障害ログレコード (古いスタイル)**
```
"record":"RequestId: ...\tError: Runtime exited with error: exit status 255\nRuntime.ExitError"
```
**Example プラットフォーム障害ログレコード (新しいスタイル)**
```
"record":"RequestId: ... Status: error\tErrorType: Runtime.ExitError"
```
Lambda は、拡張機能が拡張 API に登録されると、プラットフォーム拡張ログを生成します。次の例は、プラットフォーム拡張メッセージを示しています。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.extension",
"record": {"name": "Foo.bar",
"state": "Ready",
"events": ["INVOKE", "SHUTDOWN"]
}
}
```
Lambda は、拡張機能がログ API をサブスクライブすると、プラットフォームログサブスクリプションログを生成します。次の例は、ログサブスクリプションメッセージを示しています。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.logsSubscription",
"record": {"name": "Foo.bar",
"state": "Subscribed",
"types": ["function", "platform"],
}
}
```
Lambda は、拡張機能が受信しているログの数を処理できない場合に、プラットフォームログをドロップしたログを生成します。次の例は、`platform.logsDropped` ログメッセージの例を示しています。
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.logsDropped",
"record": {"reason": "Consumer seems to have fallen behind as it has not acknowledged receipt of logs.",
"droppedRecords": 123,
"droppedBytes" 12345
}
}
```
**platform.restoreStart** ログメッセージには、`Restore` フェーズが開始された時刻が表示されます (`snap-start` 初期化タイプのみ)。例:
```
{
"time":"2022-07-17T18:43:44.782Z",
"type":"platform.restoreStart",
"record":{}
}
```
**platform.restoreReport** ログメッセージには、`Restore` フェーズの継続時間と、このフェーズ中に料金が請求されたミリ秒数が表示されます (`snap-start` 初期化タイプのみ)。例:
```
{
"time":"2022-07-17T18:43:45.936Z",
"type":"platform.restoreReport",
"record":{
"metrics":{
"durationMs":70.87,
"billedDurationMs":13
}
}
}
```
#### プラットフォーム `runtimeDone` メッセージ
サブスクライブリクエストでスキーマバージョンを「2021-03-18」に設定した場合、Lambda は関数の呼び出しが正常に完了するか、エラーで終了した後に `platform.runtimeDone` メッセージを送信します。拡張機能は、このメッセージを使用して、この関数呼び出しのすべてのテレメトリ収集を停止できます。
スキーマバージョン **2021-03-18** での Log イベントタイプの OpenAPI 仕様は、[schema-2021-03-18.zip](samples/schema-2021-03-18.zip) から入手できます。
Lambda は、ランタイムが `Next` または `Error` ランタイム API リクエストを送信したときに `platform.runtimeDone` ログメッセージを生成します。`platform.runtimeDone` ログは、関数の呼び出しが完了したことを Logs API のコンシューマーに通知します。拡張機能は、この情報を使用して、呼び出し中に収集されたすべてのテレメトリをいつ送信するかを決定できます。
##### 例
Lambda は、関数の呼び出しが完了したときに、ランタイムが NEXT リクエストを送信した後に `platform.runtimeDone` メッセージを送信します。次の例は、各ステータス値 (成功、失敗、タイムアウト) のメッセージを示しています。
**Example 成功した場合のメッセージ例**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "success"
}
}
```
**Example 失敗した場合のメッセージ例**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "failure"
}
}
```
**Example タイムアウトした場合のメッセージ例**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "timeout"
}
}
```
**Example platform.restoreRuntimeDone メッセージの例 (`snap-start` 初期化タイプのみ)**
**platform.restoreRuntimeDone** ログメッセージには、`Restore` フェーズが正常に実行されたかどうかが表示されます。Lambda は、ランタイムが `restore/next` Runtime API リクエストを送信するときに、このメッセージを送信します。可能なステータスには、success (成功)、failure (失敗)、および timeout (タイムアウト) の 3 つがあります。以下は、正常に実行された **platform.restoreRuntimeDone** ログメッセージの例です。
```
{
"time":"2022-07-17T18:43:45.936Z",
"type":"platform.restoreRuntimeDone",
"record":{
"status":"success"
}
}
```