# Lambda 関数のモニタリング、デバッグ、トラブルシューティング
AWS Lambda は他の AWS のサービスとの統合により、Lambda 関数のモニタリングおよびトラブルシューティングに役立ちます。Lambda はユーザーの代わりに自動的に Lambda 関数をモニタリングし、Amazon CloudWatch を通じてメトリクスを報告します。Lambda は、コードを実行する際のコードのモニタリングに役立つように、リクエストの数、リクエストあたりの呼び出し時間、エラーとなったリクエストの数を自動的に追跡します。
他の AWS のサービスを使用して、Lambda 関数のトラブルシューティングを行うことができます。このセクションでは、これらの AWS のサービスを使用して、Lambda 関数とアプリケーションのモニタリング、トレース、デバッグ、トラブルシューティングを行う方法について説明します。各ランタイムでの関数のロギングとエラーに関する詳細については、それぞれのランタイムセクションを参照してください。
**Topics**
+ [料金](#monitoring-console-metrics-pricing)
+ [Lambda での CloudWatch メトリクスの使用](monitoring-metrics.md)
+ [Lambda 関数ログの操作](monitoring-logs.md)
+ [AWS CloudTrail を使用した AWS Lambda API コールのロギング](logging-using-cloudtrail.md)
+ [AWS X-Ray を使用した Lambda 関数呼び出しの視覚化](services-xray.md)
+ [Amazon CloudWatch Lambda Insights を使用した関数パフォーマンスのモニタリング](monitoring-insights.md)
+ [Lambda アプリケーションのモニタリング](applications-console-monitoring.md)
+ [Amazon CloudWatch Application Signals によるアプリケーションパフォーマンスのモニタリング](monitoring-application-signals.md)
+ [Visual Studio Code での Lambda 関数のリモートデバッグ](debugging.md)
## 料金
CloudWatch では、無期限の無料利用枠をご利用いただけます。無料利用枠の限度を超えた場合、メトリクス、ダッシュボード、アラーム、ログ、インサイトに対する CloudWatch 料金が発生します。詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs)」を参照してください。
# Lambda での CloudWatch メトリクスの使用
AWS Lambda 関数がイベントの処理を終了すると、Lambda は呼び出しに関するメトリクスを Amazon CloudWatch に自動的に送信します。関数メトリクスを受信するために実行ロールに追加のアクセス許可を付与する必要はありません。また、これらのメトリクスには追加料金はかかりません。
Lambda 関数には、さまざまなタイプのメトリクスが関連付けられています。これには、呼び出しメトリクス、パフォーマンスメトリクス、同時実行メトリクス、非同期呼び出しメトリクス、イベントソースマッピングメトリクスなどがあります。詳細については、「[Lambda 関数のメトリクスのタイプ](monitoring-metrics-types.md)」を参照してください。
CloudWatch コンソールでは、[これらのメトリクスを表示](monitoring-metrics-view.md)し、メトリクスを使用してグラフとダッシュボードを作成できます。使用率、パフォーマンス、エラー率の変化に対応するようにアラームを設定することもできます。Lambda は、メトリクスデータを 1 分間隔で CloudWatch に送信します。Lambda 関数についてより詳細な情報を直ちに把握したい場合は、[高解像度のカスタムメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)を作成できます。料金は、カスタムメトリクスと CloudWatch アラームに対して適用されます。詳細については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)をご覧ください。
# Lambda 関数のメトリクスの表示
CloudWatch コンソールを使用して、Lambda 関数のメトリクスを表示します。コンソールで関数名、エイリアス、バージョン、またはイベントソースマッピング UUID によって関数メトリクスをフィルタリングおよびソートできます。
**CloudWatch コンソールでメトリクスを表示するには**
1. CloudWatch コンソールで [[Metrics] (メトリクス) ページ](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~();namespace=~'AWS*2fLambda) (`AWS/Lambda` 名前空間) を開きます。
1. **[参照]** タブの **[メトリクス]** で、次のいずれかのディメンションを選択します。
+ **関数名を基準** (`FunctionName`) - 関数のすべてのバージョンおよびエイリアスの集計メトリクスを表示します。
+ **リソースを基準** (`Resource`) - 関数のバージョンまたはエイリアスのメトリクスを表示します。
+ **実行バージョンを基準** (`ExecutedVersion`) - エイリアスおよびバージョンの組み合わせのメトリクスを表示します。`ExecutedVersion` ディメンションを使用して、両方とも[加重エイリアス](configuration-aliases.md)のターゲットである 2 つのバージョンの関数のエラー率を比較します。
+ **イベントソースマッピング UUID を基準** (`EventSourceMappingUUID`) — イベントソースマッピングのメトリクスを表示します。
+ **[全関数]** (なし) - 現在の AWS リージョン 内のすべての関数の集計メトリクスを表示します。
1. メトリクスを選択します。メトリクスは、ビジュアルグラフと **[グラフ化したメトリクス]** タブに自動的に表示されます。
デフォルトでは、グラフはすべてのメトリクスで `Sum` 統計を使用します。別の統計を選択してグラフをカスタマイズするには、[**Graphed metrics**] タブのオプションを使用します。
**注記**
メトリクスのタイムスタンプには、関数が呼び出された時間が反映されます。呼び出し時間によっては、数分後にメトリクスが生成される場合があります。例えば、関数のタイムアウトが 10 分の場合は、正確なメトリクスを得るために過去 10 分以上を確認します。
CloudWatch の詳細については、「[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)」を参照してください。
# Lambda 関数のメトリクスのタイプ
このセクションでは、CloudWatch コンソールで使用できる Lambda メトリクスのタイプについて説明します。
**Topics**
+ [呼び出しメトリクス](#invocation-metrics)
+ [デプロイメトリクス](#deployment-metrics)
+ [パフォーマンスメトリクス](#performance-metrics)
+ [同時実行メトリクス](#concurrency-metrics)
+ [非同期呼び出しメトリクス](#async-invocation-metrics)
+ [イベントソースマッピングメトリクス](#event-source-mapping-metrics)
## 呼び出しメトリクス
呼び出しメトリクスは、Lambda 関数の呼び出しの結果を示すバイナリインジケータです。`Sum` 統計を使用して、これらのメトリクスを表示します。例えば、関数がエラーを返した場合、Lambda は値 1 の `Errors` メトリクスを送信します。1 分ごとに発生した関数エラーの数を取得するには、1 分間の `Errors` メトリクスの `Sum` を表示します。
+ `Invocations` – 関数コードが呼び出された回数 (成功した呼び出しや関数エラーが発生した呼び出しを含む)。呼び出しリクエストがスロットリングされた場合、呼び出しは記録されません。それ以外の場合は、呼び出しエラーになります。`Invocations` の値は請求対象リクエストの数に等しくなります。
+ `Errors` - 関数エラーが発生した呼び出しの数。関数エラーには、コードによってスローされた例外と、Lambda ランタイムによってスローされた例外が含まれます。ランタイムは、タイムアウトや設定エラーなどの問題に対してエラーを返します。エラー率を計算するには、`Errors` の値を `Invocations` の値で割ります。エラーメトリクスのタイムスタンプは、エラーが発生した時点ではなく、関数が呼び出された時間を反映していることに注意してください。
+ `DeadLetterErrors` – [非同期呼び出し](invocation-async.md)の場合、Lambda がイベントをデッドレターキュー (DLQ) に送信しようとしたが、失敗した回数。デッドレターエラーは、リソースの誤設定またはサイズ制限が原因で発生する可能性があります。
+ `DestinationDeliveryFailures`– 非同期呼び出しおよびサポートされている[イベントソースマッピング](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html)の場合、Lambda がイベントを[送信先](invocation-async-retain-records.md#invocation-async-destinations)に送信しようとして失敗した回数。イベントソースマッピングの場合、Lambda はストリームソース (DynamoDB および Kinesis) の送信先をサポートします。配信エラーは、アクセス許可エラー、リソースの誤設定、またはサイズ制限が原因で発生する可能性があります。設定した送信先が Amazon SQS FIFO キューまたは Amazon SNS FIFO トピックなどのサポートされていないタイプの場合にも、エラーが発生する可能性があります。
+ `Throttles` - スロットリングされた呼び出しリクエストの数。すべての関数インスタンスがリクエストを処理していて、スケールアップできる同時実行がない場合、Lambda は `TooManyRequestsException` エラーを出して追加のリクエストを拒否します。スロットリングされたリクエストやその他の呼び出しエラーは、`Invocations` または `Errors` のいずれかとしてカウントされません。
**注記**
[Lambda マネージドインスタンス](lambda-managed-instances.md)では、Lambda はスロットルの原因となる特定の制約を特定するための、きめ細かなスロットルメトリクスを提供します 実行環境でスロットルが発生すると、次のサブメトリクスのうち 1 つは 1 で出力され、残りの 3 つは 0 で出力されます。`Throttles` メトリクスは常にこれらのサブメトリクスと一緒に出力されます。
`CPUThrottles` – 実行環境で CPU の使用率が上限に達したときにスロットリングされる呼び出し。
`MemoryThrottles` – 実行環境でメモリの使用率が上限に達したときにスロットリングされる呼び出し。
`DiskThrottles` – 実行環境でディスクの使用率が上限に達したときにスロットリングされる呼び出し。
`ConcurrencyThrottles` – 実行環境の同時実行の上限に達したときにスロットリングされる呼び出し。
+ `OversizedRecordCount` — Amazon DocumentDB イベントソースの場合における、関数が変更ストリームから受け取るイベントのうちサイズが 6 MB を超えるイベントの数。Lambda はメッセージをドロップし、このメトリクスを送信します。
+ `ProvisionedConcurrencyInvocations` - [プロビジョニングされた同時実行](provisioned-concurrency.md)を使用して関数コードが呼び出された回数。
+ `ProvisionedConcurrencySpilloverInvocations` - プロビジョニングされたすべての同時実行が使用されているときに、標準同時実行を使用して関数コードが呼び出された回数。
+ `RecursiveInvocationsDropped` – 関数が無限再帰ループの一部である問題が検出されたことが原因で、Lambda が関数の呼び出しを停止した回数。再帰ループ検出機能は、サポートされている AWS SDK によって追加されたメタデータを追跡することで、リクエストチェーンの一部として関数が呼び出された回数をモニタリングします。デフォルトでは、関数がリクエストチェーンの一部として約 16 回呼び出された場合、Lambda は次の呼び出しをドロップします。再帰ループ検出機能を無効にすると、このメトリクスは出力されません。この機能の詳細については、「[Lambda 再帰ループ検出を使用した無限ループの防止](invocation-recursion.md)」を参照してください。
## デプロイメトリクス
デプロイメトリクスは、Lambda 関数のデプロイイベントと関連する検証プロセスに関する情報を提供します。
+ `SignatureValidationErrors` – コード署名設定ポリシーが `Warn` に設定されているときに、署名検証に失敗したコードパッケージのデプロイが発生した回数。このメトリクスは、有効期限、不一致、または失効チェックが失敗しても、`Warn` ポリシー設定のためにデプロイが引き続き許可されている場合に出力されます。コード署名の詳細については、「[コード署名を使用して Lambda でコードの整合性を検証する](configuration-codesigning.md)」を参照してください。
## パフォーマンスメトリクス
パフォーマンスメトリクスは、単一の関数呼び出しに関するパフォーマンスの詳細を提供します。たとえば、`Duration` メトリクスは、関数がイベントの処理に費やす時間をミリ秒単位で示します。関数がイベントを処理する速度を把握するには、`Average` または `Max` 統計を使用してこれらのメトリクスを表示します。
+ `Duration` - 関数コードがイベントの処理に費やす時間。呼び出しの請求期間は、最も近いミリ秒に切り上げた `Duration` の値です。`Duration` にコールドスタート時間は含まれません。
+ `PostRuntimeExtensionsDuration` - 関数コードの完了後、拡張のためにランタイムがコードの実行に費やした累積時間。
+ `IteratorAge` — DynamoDB、Kinesis、および Amazon DocumentDB イベントソースにおける、イベントの最後のレコードの経過時間 (ミリ秒単位)。このメトリクスは、ストリームがレコードを受信してから、イベント ソース マッピングがイベントを関数に送信するまでの時間を測定します。
+ `OffsetLag` - セルフマネージド Apache Kafka および Amazon Managed Streaming for Apache Kafka (Amazon MSK) イベントソースの場合、トピックに書き込まれた最後のレコードと関数が処理した最後のレコードとのオフセットの差分。Kafka トピックは複数のパーティションを持つことができますが、このメトリクスはトピックレベルでのオフセット遅延を測定します。
また、`Duration` はパーセンタイル (`p`) 統計もサポートしています。`Average` 統計と `Maximum` 統計を歪める外れ値を除外するには、パーセンタイルを使用します。例えば、`p95` 統計は、呼び出しの 95% の最大所要時間を示します。ただし、最も遅い 5% は除きます。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[パーセンタイル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles)」を参照してください。
## 同時実行メトリクス
Lambda は、関数、バージョン、エイリアス、または AWS リージョン 全体でイベントを処理するインスタンスの総数として同時実行メトリクスを報告します。[同時実行の制限](lambda-concurrency.md#concurrency-quotas)に達するまであとどれくらいかを確認するには、`Max` 統計とともにこれらのメトリクスを表示します。
+ `ConcurrentExecutions` - イベントを処理している関数インスタンスの数。この数値がリージョンの[同時実行クォータ](gettingstarted-limits.md#compute-and-storage)、または関数で設定した[予約済み同時実行制限](configuration-concurrency.md)に達すると、Lambda は追加の呼び出しリクエストをスロットリングします。
+ `ProvisionedConcurrentExecutions` - [プロビジョニングされた同時実行](provisioned-concurrency.md)を使用してイベントを処理している関数インスタンスの数。Lambda は、プロビジョニングされた同時実行を使用するエイリアスまたはバージョンの呼び出しごとに、現在の数を出力します。関数が非アクティブな場合、またはリクエストを受信していない場合、Lambda はこのメトリクスを出力しません。
+ `ProvisionedConcurrencyUtilization` - バージョンまたはエイリアスの場合、`ProvisionedConcurrentExecutions` の値をプロビジョニングされた同時実行の合計量で割ります。例えば、関数に 10 のプロビジョニングされた同時実行数を設定して `ProvisionedConcurrentExecutions` が 7 の場合、`ProvisionedConcurrencyUtilization` は 0.7 になります。
関数が非アクティブであるか、リクエストを受信しない場合、Lambda は `ProvisionedConcurrentExecutions` に基づいているため、このメトリクスを出力しません。CloudWatch アラームの基準として `ProvisionedConcurrencyUtilization` を使用する場合は、この点に注意してください。
+ `UnreservedConcurrentExecutions` – リージョンの場合、同時実行が予約されていない関数によって処理されているイベントの数。
+ `ClaimedAccountConcurrency` — リージョンに関する、オンデマンド呼び出しでは使用できない同時実行の量。`ClaimedAccountConcurrency` は、`UnreservedConcurrentExecutions` に割り当てられた同時実行数を加えたものに等しくなります (つまり、予約された同時実行数の合計にプロビジョニングされた同時実行数の合計を加えたもの)。詳細については、「[`ClaimedAccountConcurrency` メトリクスの処理](monitoring-concurrency.md#claimed-account-concurrency)」を参照してください。
## 非同期呼び出しメトリクス
非同期呼び出しメトリクスは、イベントソースからの非同期呼び出しおよび直接呼び出しに関する詳細を提供します。しきい値とアラームを設定して、特定の変更を通知できます。例えば、処理用にキューに入れられるイベントの数が意図せず増えた場合 (`AsyncEventsReceived`) や、イベントが処理されるのを長時間待っていた場合 (`AsyncEventAge`) です。
+ `AsyncEventsReceived` — Lambda が処理のために正常にキューに入れられたイベントの数。このメトリクスは、Lambda 関数が受け取るイベントの数に関するインサイトを提供します。このメトリクスをモニタリングし、しきい値のアラームを設定して問題がないか確認します。例えば、Lambda に送信された望ましくない数のイベントを検出したり、誤ったトリガーや関数設定に起因する問題を迅速に診断したりします。`AsyncEventsReceived` と `Invocations` が一致しない場合は、処理にばらつきがあるか、イベントがドロップされているか、キューが未処理になっている可能性があります。
+ `AsyncEventAge` — Lambda がイベントを正常にキューに入れてから、関数が呼び出されるまでの時間。このメトリクスの値は、呼び出しの失敗またはスロットリングによってイベントが再試行されるときに増加します。このメトリクスをモニタリングし、キューの蓄積が発生したときのさまざまな統計のしきい値にアラームを設定します。このメトリクスの増加をトラブルシューティングするには、`Errors` メトリクスを調べて関数エラーを特定し、`Throttles` メトリクスを見て同時実行の問題を特定します。
+ `AsyncEventsDropped` — 関数を正常に実行せずにドロップされたイベントの数。デッドレターキュー (DLQ) または `OnFailure` 送信先を設定すると、イベントはドロップされる前にそこに送信されます。イベントは、さまざまな理由でドロップされます。例えば、イベントがイベントの最大有効期間を超えたり、再試行回数が上限に達したり、予約された同時実行数が 0 に設定されたりすることがあります。イベントがドロップされる理由をトラブルシューティングするには、関数エラーを特定する `Throttles`メトリクスと、同時実行の問題を特定する `Errors` メトリクスを調べてください。
## イベントソースマッピングメトリクス
イベントソースマッピングメトリクスでは、イベントソースマッピングの処理動作に関するインサイトを提供します。
現在、イベントソースマッピングメトリクスは、Amazon SQS、Kinesis、DynamoDB、Amazon MSK、およびセルフマネージド Apache Kafka イベントソースで使用できます。
メトリクス設定によるイベントソースマッピングについては、コンソール **[Lambda]** > **[追加リソース]** > **[イベントソースマッピング]** のページの **[モニター]** タブで、すべての ESM 関連メトリクスを確認することもできます。
**メトリクスまたはイベントソースマッピングを有効にするには (コンソール)**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. メトリクスを有効にする関数を選択します。
1. **[設定]** タブを選択し、**[トリガー]** を選択します。
1. メトリクスを有効にするイベントソースマッピングを選択し、**[編集]** を選択します。
1. **[イベントソースマッピングの設定]** で、**[メトリクスを有効にする]** を選択するか、**[メトリクス]** ドロップダウンリストから選択します。
1. **[保存]** を選択します。
または、[EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) の [EventSourceMappingMetricsConfig](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingMetricsConfig.html) オブジェクトを使用してプログラムでイベントソースマッピングのメトリクスを有効にできます。例えば、次の [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) CLI コマンドでイベントソースマッピングのメトリクスを有効にします。
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--metrics-config Metrics=EventCount
```
`EventCount`、`ErrorCount`、`KafkaMetrics` の 3 つのメトリクスのグループがあり、各グループには複数のメトリクスがあります。各イベントソースですべてのメトリクスを使用できるわけではありません。次の表に、イベントソースのタイプごとにサポートされているメトリクスをまとめます。
メトリクスに関連するメトリクスを受信するには、メトリクスグループをオプトインする必要があります。例えば、メトリクス設定で EventCount を (`PolledEventCount`、`FilteredOutEventCount`、`InvokedEventCount`、`FailedInvokeEventCount`、`DroppedEventCount`、`OnFailureDestinationDeliveredEventCount`、`DeletedEventCount`) に設定します。
| イベントソースマッピングメトリクス | メトリクスグループ | Amazon SQS | Kinesis および DynamoDB Streams | Amazon MSK およびセルフマネージド Apache Kafka |
| --- | --- | --- | --- | --- |
| `PolledEventCount` | `EventCount` | あり | はい | はい |
| `FilteredOutEventCount` | `EventCount` | はい | はい | はい |
| `InvokedEventCount` | `EventCount` | はい | はい | はい |
| `FailedInvokeEventCount` | `EventCount` | はい | はい | あり |
| `DroppedEventCount` | `EventCount` | なし | はい | あり |
| `OnFailureDestinationDeliveredEventCount` | `EventCount` | なし | はい | はい |
| `DeletedEventCount` | `EventCount` | あり | なし | なし |
| `CommittedEventCount` | `EventCount` | なし | なし | あり |
| `PollingErrorCount` | `ErrorCount` | なし | なし | あり |
| `InvokeErrorCount` | `ErrorCount` | なし | なし | あり |
| `OnFailureDestinationDeliveryErrorCount` | `ErrorCount` | なし | なし | あり |
| `SchemaRegistryErrorCount` | `ErrorCount` | なし | なし | あり |
| `CommitErrorCount` | `ErrorCount` | なし | なし | あり |
| `MaxOffsetLag` | `KafkaMetrics` | なし | なし | あり |
| `SumOffsetLag` | `KafkaMetrics` | なし | なし | あり |
また、イベントソースマッピングが[プロビジョニングモード](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode)の場合、Lambda は次のメトリクスを提供します。
+ `ProvisionedPollers` – プロビジョニングモードのイベントソースマッピングにおける、アクティブに実行されているイベントポーラーの数。`MAX` 計算を使用して、このメトリクスを表示します。
+ (Amazon MSK およびセルフマネージド Apache Kafka イベントソースのみ) `EventPollerUnit` – プロビジョニングモードのイベントソースマッピングの場合、アクティブに実行されているイベントポーラーユニットの数。`SUM` 計算を使用して、このメトリクスを表示します。
+ (Amazon MSK およびセルフマネージド Apache Kafka イベントソース) `EventPollerThroughputInBytes` – プロビジョニングモードのイベントソースマッピングの場合、イベントソースからポーリングされたイベントポーラーの合計レコードサイズ。現在のポーリングスループットを確認できます。`SUM` 計算を使用して、このメトリクスを表示します。
各メトリクスの詳細を以下に示します。
+ `PolledEventCount` – Lambda がイベントソースから正常に読み取るイベントの数。Lambda がイベントをポーリングし、空のポーリング (新しいレコードなし) を受信すると、Lambda はこのメトリクスに 0 の値を出力します。このメトリクスを使用して、イベントソースマッピングで新しいイベントが正しくポーリングされているかどうかを検出します。
+ `FilteredOutEventCount` – [フィルター条件](invocation-eventfiltering.md)を使用するイベントソースマッピングにおける、そのフィルター条件によって除外されたイベントの数。このメトリクスを使用して、イベントソースマッピングがイベントを適切に除外しているかどうかを検出します。イベントがフィルター条件に一致する場合、Lambda は 0 メトリクスを出力します。
+ `InvokedEventCount` – Lambda 関数を呼び出したイベントの数。このメトリクスを使用して、イベントが関数を適切に呼び出していることを確認します。イベントによって関数エラーまたはスロットリングが発生した場合、自動再試行により、`InvokedEventCount` は同じポーリングされたイベントを複数回カウントすることがあります。
**警告**
Lambda イベントソースマッピングは各イベントを少なくとも 1 回処理し、レコードの重複処理が発生する可能性があります。このため、イベントはイベント数を含むメトリクスで複数回カウントされる場合があります。
+ `FailedInvokeEventCount` – Lambda が関数を呼び出そうとして、失敗したイベントの数。呼び出しは、ネットワーク設定に問題がある、アクセス許可が正しくない、Lambda 関数、バージョン、またはエイリアスが削除されたなどの理由で失敗することがあります。イベントソースマッピングで[部分的なバッチレスポンス](services-sqs-errorhandling.md#services-sqs-batchfailurereporting)が有効になっている場合、`FailedInvokeEventCount` には、レスポンス内に空でない `BatchItemFailures` があるイベントがすべて含まれます。
**注記**
`FailedInvokeEventCount` メトリクスのタイムスタンプは、関数呼び出しの終了を表します。この動作は、関数呼び出しの開始時にタイムスタンプが付けられる他の Lambda 呼び出しエラーメトリクスとは異なります。
+ `DroppedEventCount` – 有効期限切れまたは再試行回数の上限に達したことにより Lambda がドロップしたイベントの数。具体的には、これは `MaximumRecordAgeInSeconds` または `MaximumRetryAttempts` の設定値を超えるレコードの数です。重要な点として、イベントソースの保持設定を超えたために期限切れになるレコードの数は含まれません。ドロップされたイベントは、[障害発生時の送信先](invocation-async-retain-records.md)に送信するイベントも除外します。このメトリクスを使用して、イベントのバックログの増加を検出します。
+ `OnFailureDestinationDeliveredEventCount` – [障害発生時の送信先](invocation-async-retain-records.md)が設定されたイベントソースマッピングにおける、その送信先に送信されたイベントの数。このメトリクスを使用して、このイベントソースからの呼び出しに関連する関数エラーをモニタリングします。送信先への配信が失敗した場合、Lambda はメトリクスを次のように処理します。
+ Lambda は `OnFailureDestinationDeliveredEventCount` メトリクスを出力しません。
+ `DestinationDeliveryFailures` メトリクスの場合、Lambda は 1 を出力します。
+ `DroppedEventCount` メトリクスの場合、Lambda は配信に失敗したイベントの数に等しい数値を出力します。
+ `DeletedEventCount` — Lambda が処理後に正常に削除したイベントの数。Lambda がイベントを削除しようとして失敗した場合、Lambda は 0 メトリクスを出力します。このメトリクスを使用して、正常に処理されたイベントがイベントソースから削除されることを確認します。
+ `CommittedEventCount` – Lambda が処理後に正常にコミットしたイベントの数。これは、Kafka イベントソースマッピングの各パーティションからコミットされた最後のオフセットと現在のオフセットのデルタの合計です。
+ `PollingErrorCount` – Lambda がイベントソースからのリクエストのポーリングに失敗したエラーの数。Lambda は、エラーが発生したときにのみこのメトリクスデータを発行します。
+ `InvokeErrorCount` – Lambda が関数の呼び出しに失敗したエラーの数。呼び出しはバッチのレコードであることに注意してください。数値はバッチレベルにあり、レコード数レベルではありません。Lambda は、エラーが発生したときにのみこのメトリクスデータを発行します。
+ `SchemaRegistryErrorCount` – Lambda がスキーマの取得またはスキームによる逆シリアル化に失敗したエラーの数。Lambda は、エラーが発生したときにのみこのメトリクスデータを発行します。
+ `CommitErrorCount` – Lambda が Kafka クラスターにコミットできなかったエラーの数。Lambda は、エラーが発生したときにのみこのメトリクスデータを発行します。
+ `MaxOffsetLag` – イベントソースマッピングのすべてのパーティションにおけるオフセットラグ (最新のオフセットとコミットされたオフセットの差) の最大数。
+ `SumOffsetLag` – イベントソースマッピングのすべてのパーティションにおけるオフセットラグの合計。
イベントソースマッピングが無効になっている場合、イベントソースマッピングメトリクスは受信されません。CloudWatch または Lambda の可用性が低下している場合、メトリクスが欠落している可能性もあります。
# Lambda 関数ログの操作
障害をトラブルシューティングできるよう、AWS Lambda はユーザーに代わって Lambda 関数を自動でモニタリングします。Lambda コンソール、CloudWatch コンソール、AWS Command Line Interface (AWS CLI)、あるいは CloudWatch API を使用して Lambda 関数のログを表示できます。Amazon S3 および Firehose にログを送信するように Lambda を設定することもできます。
関数の[実行ロール](lambda-intro-execution-role.md)が必要なアクセス許可を持っている限り、Lambda はその関数によって処理されるすべてのリクエストのログをキャプチャし、デフォルトの送信先である Amazon CloudWatch Logs に送信します。Lambda コンソールを使用して Amazon S3 または Firehose をログ記録先として設定することもできます。
+ **CloudWatch Logs** は、デフォルトの Lambda 関数のログ記録先です。CloudWatch Logs は、リアルタイムのログ表示および分析機能を提供し、ログデータに基づくメトリクスおよびアラームの作成をサポートします。
+ **Amazon S3** は経済的な長期ストレージを提供すると共に、Athena などのサービスを使用したログ分析を可能にします。通常は、高いレイテンシーが得られます。
+ **Firehose** は、さまざまな送信先にログのマネージドストリーミングを提供します。ログを他の AWS サービス (OpenSearch Service や Redshift Data API など) またはサードパーティプラットフォーム (Datadog、New Relic、Splunk など) に送信する必要がある場合、Firehose は事前構築済みの統合機能を提供することでこのプロセスを簡素化します。追加のインフラストラクチャを設定せず、カスタム HTTP エンドポイントにストリーミングすることもできます。
## ログを送信するサービス送信先の選択
関数ログの送信先となるサービスを選択する際、以下の重要な要因を考慮してください。
+ **コスト管理はサービスによって異なります。**通常、Amazon S3 は最も経済的な長期ストレージオプションを提供しますが、CloudWatch Logs はリアルタイムでのログ表示、ログ処理、アラート設定を可能にします。Firehose のコストには、ストリーミングサービスおよびストリーミング先の設定に関連するコストの両方が含まれます。
+ **分析機能はサービスによって異なります。**CloudWatch Logs はリアルタイムのモニタリングに優れ、Logs Insights や Live Tail などの他の CloudWatch 機能とネイティブに統合します。Amazon S3 も Athena などの分析ツールと互換性があり、さまざまなサービスとの統合が可能ですが、追加のセットアップが必要になる場合があります。Firehose は事前構築された統合機能を提供することで、特定の AWS サービス (OpenSearch Service や Redshift Data API など) およびサポートされているサードパティプラットフォーム (Datadog や Splunk など) への直接ストリーミングを簡素化し、設定作業を軽減する効果があります。
+ **セットアップと使いやすさはサービスによって異なります。**CloudWatch Logs はデフォルトのログ送信先です。追加の設定なしですぐに実装でき、CloudWatch コンソール上でのシンプルなログ表示および分析機能を提供します。Amazon S3 にログを送信するには、Lambda コンソールで初期設定を行い、バケットのアクセス許可を設定する必要があります。OpenSearch Service やサードパーティ分析プラットフォームなどのサービスに直接ログを送信したい場合、Firehose でプロセスを簡素化することができます。
## ログ送信先の設定
AWS Lambda は、関数ログの複数の送信先をサポートします。このガイドでは利用可能なログ記録の送信先について説明し、ニーズに応じて適切なオプションを選択できるようにします。どの送信先を選択するかに関わらず、Lambda はログ形式、フィルタリング、配信を制御するオプションを提供します。
Lambda は、関数ログ形式として JSON 形式およびプレーンテキスト形式の両方をサポートします。JSON 構造化ログは検索可能性を高めて自動分析を可能にする一方、プレーンテキストログはシンプルさを提供し、ストレージコストを削減する効果が期待できます。システムログとアプリケーションログの両方についてログレベルを設定することで、Lambda がどのログを選択された送信先に送信するかをコントロールできます。フィルタリングによってストレージコストを管理し、デバッグ中に関連するログエントリを見つけやすくなります。
各送信先のセットアップ手順の詳細については、次のセクションを参照してください。
+ [Lambda 関数ログを CloudWatch Logs に送信する](monitoring-cloudwatchlogs.md)
+ [Firehose への Lambda 関数ログの送信](logging-with-firehose.md)
+ [Lambda 関数ログを Amazon S3 に送信する](logging-with-s3.md)
## Lambda 関数の高度なログ記録コントロールの設定
関数ログのキャプチャ、処理、使用方法をより細かく制御できるよう、Lambda では次のログ記録設定オプションを用意しています。
+ **ログの形式** - 関数ログ形式として、プレーンテキスト形式または構造化 JSON 形式のいずれかを選択できます。
+ **ログレベル** - JSON 構造化ログの場合、Lambda が CloudWatch に送信するログの詳細レベル (`FATAL`、`ERROR`、`WARN`、`INFO`、`DEBUG`、`TRACE`) を選択できます。
+ **ロググループ** - 関数がログを送信する CloudWatch ロググループを選択できます。
高度なログ記録コントロールの設定の詳細については、以下のセクションを参照してください。
+ [JSON とプレーンテキストのログフォーマットの設定](monitoring-cloudwatchlogs-logformat.md)
+ [ログレベルのフィルタリング](monitoring-cloudwatchlogs-log-level.md)
+ [CloudWatch ロググループの設定](monitoring-cloudwatchlogs-loggroups.md)
# JSON とプレーンテキストのログフォーマットの設定
ログ出力を JSON キー値のペアとしてキャプチャすると、関数のデバッグ時の検索やフィルタリングが容易になります。JSON 形式のログでは、タグやコンテキスト情報をログに追加することもできます。これにより、大量のログデータを自動的に分析するのに役立ちます。開発ワークフローがプレーンテキストで Lambda ログを使用する既存のツールに依存している場合を除き、ログ形式には JSON を選択することをお勧めします。
**Lambda マネージドインスタンス**
Lambda マネージドインスタンスは JSON ログ形式のみをサポートします。マネージドインスタンス関数を作成すると、Lambda は自動的にログ形式を JSON に設定し、プレーンテキストに変更することはできません。マネージドインスタンスの詳細については、「[Lambda マネージドインスタンス](lambda-managed-instances.md)」を参照してください。
すべての Lambda マネージドランタイムについて、関数のシステムログを CloudWatch Logs に非構造化プレーンテキストで送信するか、JSON 形式で送信するかを選択できます。システムログは Lambda が生成するログで、プラットフォームイベントログと呼ばれることもあります。
[サポートされているランタイム](#monitoring-cloudwatchlogs-logformat-supported)では、サポートされている組み込みログ記録メソッドのいずれかを使用すると、Lambda は関数のアプリケーションログ (関数コードが生成するログ) を構造化された JSON 形式で出力することもできます。これらのランタイムに対して関数のログ形式を設定すると、選択した設定がシステムログとアプリケーションログの両方に適用されます。
サポートされているランタイムでは、関数がサポートされているログ記録ライブラリまたはメソッドを使用している場合は、Lambda が構造化された JSON でログをキャプチャするために既存のコードを変更する必要はありません。
**注記**
JSON ログフォーマットを使用すると、メタデータが追加され、一連のキー値のペアを含む JSON オブジェクトとしてログメッセージがエンコードされます。そのため、関数のログメッセージのサイズが大きくなる可能性があります。
## サポートされているランタイムとログ記録メソッド
Lambda は現在、以下のランタイムの JSON 構造化アプリケーションログを出力するオプションをサポートしています。
| Language | サポートバージョン |
| --- | --- |
| Java | Amazon Linux 1 上の Java 8 を除くすべての Java ランタイム |
| .NET | .NET 8 以降 |
| Node.js | Node.js 16 およびそれ以降 |
| Python | Python 3.8 以降 |
| Rust | 該当なし |
Lambda が関数のアプリケーションログを構造化された JSON 形式で CloudWatch に送信するには、関数が以下の組み込みログ記録ツールを使用してログを出力する必要があります。
+ **Java**: `LambdaLogger` ロガーまたは Log4j2。詳細については、「[Java Lambda 関数のログ記録とモニタリング](java-logging.md)」を参照してください。
+ **.NET**: コンテキストオブジェクトの `ILambdaLogger` インスタンス。詳細については、「[C\$1 Lambda 関数のログ記録とモニタリング](csharp-logging.md)」を参照してください。
+ **Node.js** – コンソールメソッド `console.trace`、`console.debug`、`console.log`、`console.info`、`console.error` および `console.warn`。詳細については、「[Node.js Lambda 関数のログ記録とモニタリング](nodejs-logging.md)」を参照してください。
+ **Python**: 標準の Python `logging` ライブラリ。詳細については、「[Python Lambda 関数のログ記録とモニタリング](python-logging.md)」を参照してください。
+ **Rust**: `tracing` クレート。詳細については、「[Rust Lambda 関数のログ記録とモニタリング](rust-logging.md)」を参照してください。
他のマネージド Lambda ランタイムについては、現在、Lambda は構造化された JSON 形式でのシステムログのキャプチャのみをネイティブでサポートしています。ただし、Powertools for AWS Lambda などのログ記録ツールを使用して JSON 形式のログを出力することで、どのランタイムでも構造化 JSON 形式のアプリケーションログをキャプチャできます。
## 既定のログ形式
現在、すべての Lambda ランタイムのデフォルトのログ形式はプレーンテキストです。Lambda マネージドインスタンスの場合、ログ形式は常に JSON であり、変更できません。
既に Powertools for AWS Lambda などのログ記録ライブラリを使用して JSON 構造化形式で関数ログを生成している場合は、JSON ログ形式を選択すればコードを変更する必要はありません。Lambda は既に JSON でエンコードされたログを二重にエンコードしないため、関数のアプリケーションログは以前と同様にキャプチャされます。
## システムログの JSON 形式
関数のログ形式を JSON として設定すると、各システムログ項目 (プラットフォームイベント) は、以下のキーを含むキー値のペアを含む JSON オブジェクトとしてキャプチャされます。
+ `"time"` - ログメッセージが生成された時刻
+ `"type"` - 記録されるイベントのタイプ
+ `"record"` - ログ出力の内容
`"record"` 値の形式は、記録されるイベントのタイプによって異なります。詳細については、「[Telemetry API `Event` オブジェクトタイプ](telemetry-schema-reference.md#telemetry-api-events)」を参照してください。システムログイベントに割り当てられるログレベルの詳細については、「[システムログレベルのイベントマッピング](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping)」を参照してください。
比較のため、以下の 2 つの例は、プレーンテキスト形式と構造化された JSON 形式の両方で同じログ出力を示しています。ほとんどの場合、システムログイベントには、プレーンテキストで出力される場合よりも JSON 形式で出力される方が多くの情報が含まれることに注意してください。
**Example プレーンテキスト:**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example 構造化された JSON:**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**注記**
[Telemetry API を使用して拡張機能のリアルタイムテレメトリデータにアクセスする](telemetry-api.md) は常に JSON 形式で `START` や `REPORT` などのプラットフォームイベントを送信します。Lambda が CloudWatch に送信するシステムログの形式を設定しても、Lambda Telemetry API の動作には影響しません。
## アプリケーションログの JSON 形式
関数のログ形式を JSON として設定すると、サポートされているログ記録ライブラリとメソッドを使用して書き込まれたアプリケーションログ出力は、以下のキーを持つキー値のペアを含む JSON オブジェクトとしてキャプチャされます。
+ `"timestamp"` - ログメッセージが生成された時刻
+ `"level"` - メッセージに割り当てられたログレベル
+ `"message"` - ログメッセージの内容
+ `"requestId"` (Python、.NET、および Node.js) または `"AWSrequestId"` (Java) - 関数呼び出しの一意のリクエスト ID
関数が使用するランタイムとログ記録方法によっては、この JSON オブジェクトには追加のキーペアが含まれる場合もあります。例えば、Node.js では、関数が `console` メソッドを使用して複数の引数を使用しているエラーオブジェクトをログに記録する場合、JSON オブジェクトには、`errorMessage`、`errorType`、`stackTrace` というキーを含む追加のキーと値のペアが含まれます。さまざまな Lambda ランタイムの JSON 形式のログの詳細については、「[Python Lambda 関数のログ記録とモニタリング](python-logging.md)、[Node.js Lambda 関数のログ記録とモニタリング](nodejs-logging.md)、[Java Lambda 関数のログ記録とモニタリング](java-logging.md)」を参照してください。
**注記**
Lambda がタイムスタンプ値に使用するキーは、システムログとアプリケーションログでは異なります。システムログの場合、Lambda はキー `"time"` を使用して Telemetry API との一貫性を維持します。アプリケーションログについては、Lambda はサポートされているランタイムの規則に従い、`"timestamp"` を使用します。
比較のため、以下の 2 つの例は、プレーンテキスト形式と構造化された JSON 形式の両方で同じログ出力を示しています。
**Example プレーンテキスト:**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example 構造化された JSON:**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## 関数のログ形式の設定
関数のログ形式を設定するには、Lambda コンソールまたは AWS Command Line Interface (AWS CLI) を使用できます。[CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) と [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) Lambda API コマンド、AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) リソース、および CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) リソースを使用して、関数のログ形式を設定することもできます。
関数のログ形式を変更しても、CloudWatch Logs に保存されている既存のログには影響しません。新しいログのみが更新された形式を使用します。
関数のログ形式を JSON に変更し、ログレベルを設定しない場合、Lambda は関数のアプリケーションログレベルとシステムログレベルを自動的に INFO に設定します。つまり、Lambda はレベル INFO 以下のログ出力のみを CloudWatch Logs に送信します。アプリケーションおよびシステムログレベルのフィルタリングの詳細については、[ログレベルのフィルタリング](monitoring-cloudwatchlogs-log-level.md) を参照してください。
**注記**
Python ランタイムでは、関数のログ形式がプレーンテキストに設定されている場合、デフォルトのログレベル設定は WARN です。つまり、Lambda は WARN 以下のレベルのログ出力のみを CloudWatch Logs に送信します。関数のログ形式を JSON に変更すると、このデフォルト動作が変わります。Python におけるログ記録の詳細については、「[Python Lambda 関数のログ記録とモニタリング](python-logging.md)」を参照してください。
埋め込みメトリックフォーマット (EMF、Embedded Metric Format) ログを生成する Node.js 関数の場合、関数のログ形式を JSON に変更すると、CloudWatch がメトリクスを認識できなくなる可能性があります。
**重要**
関数が Powertools for AWS Lambda (TypeScript) またはオープンソースの EMF クライアントライブラリを使用して EMF ログを生成する場合は、[Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) および [EMF](https://www.npmjs.com/package/aws-embedded-metrics) ライブラリを最新バージョンに更新して、CloudWatch が引き続きログを正しく解析できるようにしてください。JSON ログ形式に切り替える場合は、関数に埋め込まれているメトリクスとの互換性を確認するためのテストを実施することもお勧めします。EMF ログを生成する node.js 関数に関するその他のアドバイスについては、「[構造化された JSON ログでの埋め込みメトリクスフォーマット (EMF、Embedded Metric Format) クライアントライブラリの使用](nodejs-logging.md#nodejs-logging-advanced-emf)」を参照してください。
**関数のログ形式を設定するには (コンソール)**
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 関数を選択します。
1. 関数設定ページで、**[モニタリングおよび運用ツール]** を選択します。
1. **[ログ記録設定]** ペインで、**[編集]** を選択します。
1. **[ログの内容]** の **[ログ形式]** で **[テキスト]** または **[JSON]** を選択します。
1. **[保存]** を選択します。
**既存の関数 (AWS CLI) のログ形式を変更するには**
+ 既存の関数のログ形式を変更するには、[update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) コマンドを使用します。`LoggingConfig` の `LogFormat` オプションを `JSON` または `Text` に設定します。
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**関数の作成時にログ形式を設定するには (AWS CLI)**
+ 新しい関数を作成するときにログ形式を設定するには、[create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) コマンドの `--logging-config` オプションを使用します。`LogFormat` を `JSON` または `Text` に設定します。以下のコマンド例を使用すれば、構造化 JSON でログを出力する Node.js 関数を作成できます。
関数の作成時にログ形式を指定しない場合、Lambda は選択したランタイムバージョンのデフォルトのログ形式を使用します。デフォルトのログ記録形式の詳細については、「[既定のログ形式](#monitoring-cloudwatchlogs-format-default)」を参照してください。
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON
```
# ログレベルのフィルタリング
Lambda は関数のログをフィルタリングして、特定の詳細レベル以下のログのみが CloudWatch Logs に送信されるようにすることができます。関数のシステムログ (Lambda が生成するログ) とアプリケーションログ (関数コードが生成するログ) には、ログレベルのフィルタリングを個別に設定できます。
[サポートされているランタイムとログ記録メソッド](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported) では、Lambda が関数のアプリケーションログをフィルタリングするために、関数コードに変更を加える必要はありません。
その他のすべてのランタイムとログ記録メソッドでは、関数コードはキー `"level"` とキー値のペアを含む JSON 形式のオブジェクトとして `stdout` または `stderr` にログイベントを出力する必要があります。例えば、Lambda は以下の `stdout` への出力を DEBUG レベルのログとして解釈します。
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
`"level"` 値フィールドが無効または欠落している場合、Lambda はログ出力にレベル INFO を割り当てます。Lambda がタイムスタンプフィールドを使用するには、有効な [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) タイムスタンプ形式で時間を指定する必要があります。有効なタイムスタンプを指定しない場合、Lambda はログに INFO レベルを割り当ててタイムスタンプを追加します。
タイムスタンプキーに名前を付ける場合は、使用しているランタイムの規則に従ってください。Lambda は、マネージドランタイムで使用されるほとんどの一般的な命名規則をサポートしています。
**注記**
ログレベルのフィルタリングを使用するには、JSON ログ形式を使用するように関数を設定する必要があります。現在、すべての Lambda マネージドランタイムのデフォルトのログ形式はプレーンテキストです。関数のログ形式を JSON に設定する方法については、「[関数のログ形式の設定](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format)」を参照してください。
アプリケーションログ (関数コードによって生成されるログ) については、以下のログレベルから選択できます。
| ログレベル | 標準的な使用状況 |
| --- | --- |
| TRACE (最も詳細) | コードの実行パスを追跡するために使用される最も詳細な情報 |
| DEBUG | システムデバッグの詳細情報 |
| 情報 | 関数の通常の動作を記録するメッセージ |
| WARN | 対処しないと予期しない動作を引き起こす可能性がある潜在的なエラーに関するメッセージ |
| エラー | コードが期待どおりに動作しなくなる問題に関するメッセージ |
| FATAL (詳細度が最も低い) | アプリケーションの機能停止を引き起こす重大なエラーに関するメッセージ |
ログレベルを選択すると、Lambda はそのレベル以下のログを CloudWatch Logs に送信します。例えば、関数のアプリケーションログレベルを WARN に設定した場合、Lambda は INFO レベルと DEBUG レベルでログ出力を送信しません。ログフィルタリングのデフォルトのアプリケーションログレベルは INFO です。
Lambda が関数のアプリケーションログをフィルタリングすると、レベルのないログメッセージにはログレベル INFO が割り当てられます。
システムログ (Lambda サービスによって生成されるログ) については、以下のログレベルから選択できます。
| ログレベル | 使用方法 |
| --- | --- |
| DEBUG (詳細度が最も高い) | システムデバッグの詳細情報 |
| 情報 | 関数の通常の動作を記録するメッセージ |
| WARN (詳細度が最も低い) | 対処しないと予期しない動作を引き起こす可能性がある潜在的なエラーに関するメッセージ |
ログレベルを選択すると、Lambda はそのレベル以下のログを送信します。例えば、関数のシステムログレベルを INFO に設定した場合、Lambda は DEBUG レベルでログ出力を送信しません。
デフォルトでは、Lambda はシステムログレベルを INFO に設定します。この設定では、Lambda は自動的に CloudWatch に `"start"` および `"report"` ログメッセージを送信します。詳細度がより高いシステムログまたは詳細度がより低いシステムログを受信するには、ログレベルを DEBUG または WARN に変更します。Lambda がさまざまなシステムログイベントをマッピングするログレベルのリストを確認するには、「[システムログレベルのイベントマッピング](#monitoring-cloudwatchlogs-log-level-mapping)」を参照してください。
## ログレベルフィルタリングの設定
関数にアプリケーションとシステムログレベルのフィルタリングを設定するには、Lambda コンソールまたは AWS Command Line Interface (AWS CLI) を使用できます。[CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) と [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) Lambda API コマンド、AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html) リソース、および CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) リソースを使用して、関数のログレベルを設定することもできます。
関数のログレベルをコード内で設定した場合、この設定は他のログレベル設定よりも優先されることに注意してください。例えば、Python `logging` `setLevel()` メソッドを使用して関数のログレベルを INFO に設定した場合、この設定は Lambda コンソールを使用して設定した WARN の設定よりも優先されます。
**既存の関数のアプリケーションまたはシステムログレベルを設定するには (コンソール)**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. 関数設定ページで、**[モニタリングおよび運用ツール]** を選択します。
1. **[ログ記録設定]** ペインで、**[編集]** を選択します。
1. **[ログの内容]** の **[ログ形式]** で **[JSON]** が選択されていることを確認します。
1. ラジオボタンを使用して、関数に必要な **[アプリケーションログレベル]** と **[システムログレベル]** を選択します。
1. **[保存]** を選択します。
**既存の関数のアプリケーションまたはシステムログレベルを設定するには (AWS CLI)**
+ 既存の関数のアプリケーションログレベルまたはシステムログレベルを変更するには、[update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) コマンドを使用します。`--logging-config` を使用して、`DEBUG`、`INFO` または `WARN` のいずれかに `SystemLogLevel` を設定します。`ApplicationLogLevel` を `DEBUG`、`INFO`、`WARN`、`ERROR`、または `FATAL` のいずれかに設定します。
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**関数の作成時にログレベルのフィルタリングを設定するには**
+ 新しい関数を作成するときにログレベルのフィルタリングを設定するには、`--logging-config` を使用して [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html) コマンドの `SystemLogLevel` および `ApplicationLogLevel` キーを設定します。`SystemLogLevel` を `DEBUG`、`INFO`、または `WARN` のいずれかに設定します。`ApplicationLogLevel` を `DEBUG`、`INFO`、`WARN`、`ERROR`、または `FATAL` のいずれかに設定します。
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## システムログレベルのイベントマッピング
Lambda によって生成されるシステムレベルのログイベントについて、以下の表は各イベントに割り当てられるログレベルを定義しています。表に記載されているイベントの詳細については、「[Lambda Telemetry API `Event` スキーマリファレンス](telemetry-schema-reference.md)」を参照してください。
| イベント名 | 条件 | 割り当てられたログレベル |
| --- | --- | --- |
| initStart | runtimeVersion が設定されている | 情報 |
| initStart | runtimeVersion が設定されていない | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status\$1=success | WARN |
| initReport | initializationType\$1=on-demand | 情報 |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status\$1=success | WARN |
| restoreStart | runtimeVersion が設定されている | 情報 |
| restoreStart | runtimeVersion が設定されていない | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status\$1=success | WARN |
| restoreReport | status=success | 情報 |
| restoreReport | status\$1=success | WARN |
| 開始 | - | 情報 |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status\$1=success | WARN |
| レポート | status=success | 情報 |
| レポート | status\$1=success | WARN |
| 拡張子 | state=success | 情報 |
| 拡張子 | state\$1=success | WARN |
| logSubscription | - | 情報 |
| telemetrySubscription | - | 情報 |
| logsDropped | - | WARN |
**注記**
[Telemetry API を使用して拡張機能のリアルタイムテレメトリデータにアクセスする](telemetry-api.md) は常にプラットフォームイベントの完全なセットを出力します。Lambda が CloudWatch に送信するシステムログのレベルを設定しても、Lambda Telemetry API の動作には影響しません。
## カスタムランタイムによるアプリケーションログレベルのフィルタリング
関数にアプリケーションログレベルのフィルタリングを設定すると、バックグラウンドで Lambda は `AWS_LAMBDA_LOG_LEVEL` 環境変数を使用してランタイムのアプリケーションログレベルを設定します。また、Lambda は `AWS_LAMBDA_LOG_FORMAT` 環境変数を使用して関数のログ形式を設定します。これらの変数を使用して、Lambda の高度なログ記録コントロールを[カスタムランタイム](runtimes-custom.md)に統合できます。
Lambda コンソール、AWS CLI、および Lambda API でカスタムランタイムを使用して関数のログ記録設定を設定できるようにするには、これらの環境変数の値をチェックするようにカスタムランタイムを設定します。その後、選択したログ形式とログレベルに従ってランタイムのロガーを設定できます。
# Lambda 関数ログを CloudWatch Logs に送信する
関数の実行ロールが必要なアクセス許可を持っていることを前提として、デフォルトでは Lambda はすべての関数呼び出しについてログを自動的にキャプチャし、CloudWatch Logs に送信します。デフォルトで、これらのログは「/aws/lambda/**」という名前のロググループに保存されます。デバッグ強化のため、ユーザーはコードにカスタムログ記録ステートメントを挿入することができ、Lambda はこのコードを CloudWatch Logs にシームレスに統合させます。必要に応じて、Lambda コンソール、AWS CLI、あるいは Lambda API を使用してログを別のグループに送信するように関数を設定することができます。詳細については、「[CloudWatch ロググループの設定](monitoring-cloudwatchlogs-loggroups.md)」を参照してください。
Lambda 関数のログは、Lambda コンソール、CloudWatch コンソール、AWS Command Line Interface(AWS CLI)、または CloudWatch API を使って表示することができます。詳細については、「[Lambda 関数の CloudWatch Logs を表示する](monitoring-cloudwatchlogs-view.md)」を参照してください。
**注記**
関数の呼び出し後にログが表示されるまで、5～10 分かかることがあります。
## 必要な IAM 許可
ログを CloudWatch Logs にアップロードするには、[実行ロール](lambda-intro-execution-role.md)には次のアクセス許可が必要です。
+ `logs:CreateLogGroup`
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`
詳細については、「Amazon CloudWatch ユーザーガイド」の「[Using identity-based policies (IAM policies) for CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html)」を参照してください。
これらの CloudWatch Logs のアクセス許可は、Lambda が付与する `AWSLambdaBasicExecutionRole`AWS 管理ポリシーを使って追加します。このポリシーをロールに割り当てるには、次のコマンドを実行します。
```
aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
詳細については、「[実行ロールでの AWS マネージドポリシーの使用](permissions-managed-policies.md)」を参照してください。
## 料金
Lambda ログの使用には追加料金は発生しませんが、標準の CloudWatch Logs 料金が適用されます。詳細については、「[CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。
# CloudWatch ロググループの設定
デフォルトでは、CloudWatch は関数が最初に呼び出されたときに `/aws/lambda/` という名前のロググループを自動的に作成します。既存のロググループにログを送信するように関数を設定したり、関数の新しいロググループを作成したりするには、Lambda コンソールまたは AWS CLI を使用できます。[CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) および [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) Lambda API コマンドと AWS Serverless Application Model (AWS SAM) [AWS::Serverless::Function]() リソースを使用してカスタムロググループを設定することもできます。
同じ CloudWatch ロググループにログを送信するように、複数の Lambda 関数を設定できます。例えば、1 つのロググループを使用して、特定のアプリケーションを構成するすべての Lambda 関数のログを保存できます。Lambda 関数にカスタムロググループを使用する場合、Lambda が作成するログストリームには関数名と関数バージョンが含まれます。これにより、同じロググループを複数の関数に使用しても、ログメッセージと関数の間のマッピングは保持されます。
カスタムロググループのログストリーム命名形式は以下の規則に従います。
```
YYYY/MM/DD/[][]
```
カスタムロググループを設定する場合、ロググループに選択する名前は [CloudWatch Logs の命名規則](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html)に従う必要があることに注意してください。また、カスタムロググループ名には文字列 `aws/` で始まるものを使用できません。`aws/` で始まるカスタムロググループを作成すると、Lambda はロググループを作成できなくなります。この結果、関数のログは CloudWatch に送信されなくなります。
**関数のロググループを変更するには (コンソール)**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. 関数設定ページで、**[モニタリングおよび運用ツール]** を選択します。
1. **[ログ記録設定]** ペインで、**[編集]** を選択します。
1. **[ログ記録グループ]** ペインの **[CloudWatch ロググループ]** で、**[カスタム]** を選択します。
1. **[カスタムロググループ]** に、関数からのログの送信先にする CloudWatch ロググループの名前を入力します。既存のロググループの名前を入力すると、関数はそのグループを使用します。入力した名前のロググループが存在しない場合、Lambda はその名前で関数の新しいロググループを作成します。
**関数のロググループを変更するには (AWS CLI)**
+ 既存の関数のロググループを変更するには、[update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html) コマンドを使用します。
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogGroup=myLogGroup
```
**関数の作成時にカスタムロググループを指定するには (AWS CLI)**
+ AWS CLI を使用して新しい Lambda 関数を作成するときにカスタムロググループを指定するには、`--logging-config` オプションを使用します。以下のコマンド例では、`myLogGroup` という名前のロググループにログを送信する Node.js Lambda 関数を作成します。
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogGroup=myLogGroup
```
## 実行ロールのアクセス許可
関数から CloudWatch Logs にログを送信するには、その関数に [logs:PutLogEvents](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html) アクセス許可が必要です。Lambda コンソールを使用して関数のロググループを設定すると、Lambda は以下が満たされることを条件に、このアクセス許可をロールに追加します。
+ サービスの送信先が CloudWatch Logs に設定されていること
+ 関数の実行ロールが CloudWatch Logs (デフォルトの送信先) にログをアップロードするアクセス許可を持っていないこと
**注記**
Lambda は、Amazon S3 または Firehose ログの送信先に「Put」のアクセス許可を追加しません。
Lambda がこのアクセス許可を追加すると、任意の CloudWatch Logs ロググループにログを送信するアクセス許可が関数に付与されます。
Lambda が関数の実行ロールを自動的に更新しないようにして、代わりに手動で関数の実行ロールを編集するには、**[アクセス許可]** を展開し、**[必要なアクセス許可を追加]** のチェックを外します。
AWS CLI を使用して関数のロググループを設定しても、Lambda は `logs:PutLogEvents` アクセス許可を自動的に追加しません。まだアクセス許可がない場合は、関数の実行ロールにアクセス許可を追加します。このアクセス許可は、[AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor) マネージドポリシーに含まれています。
## Lambda マネージドインスタンスの CloudWatch ログ記録
[Lambda マネージドインスタンス](lambda-managed-instances.md)を使用する場合、CloudWatch Logs にログを送信する際には追加の考慮事項があります。
### VPC ネットワーク要件
Lambda マネージドインスタンスは、VPC 内の顧客所有の EC2 インスタンスで実行されます。CloudWatch Logs にログを送信し、X-Ray にトレースを送信するには、これらの AWS API が VPC からルーティング可能であることを確認する必要があります。これには複数のオプションがあります。
+ **AWS PrivateLink (推奨)**: [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) を使用して CloudWatch Logs および X-Ray サービスの VPC エンドポイントを作成します。これにより、インスタンスはインターネットゲートウェイや NAT ゲートウェイを必要とせずに、これらのサービスにプライベートにアクセスできます。詳細については、「[インターフェイス VPC エンドポイントでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html)」を参照してください。
+ **NAT ゲートウェイ**: プライベートサブネットからのアウトバウンドインターネットアクセスを許可するように NAT ゲートウェイを設定します。
+ **インターネットゲートウェイ**: パブリックサブネットの場合は、VPC にインターネットゲートウェイが設定されていることを確認します。
CloudWatch Logs または X-Ray API が VPC からルーティングできない場合、関数ログとトレースは配信されません。
### 同時呼び出しとログ属性
Lambda マネージドインスタンスの実行環境は、複数の呼び出しを同時に処理できます。複数の呼び出しが同時に実行されると、それらのログエントリは同じログストリームにインターリーブされます。同時呼び出しからのログを効果的にフィルタリングして分析するには、各ログエントリに AWS リクエスト ID が含まれていることを確認する必要があります。
以下のアプローチのいずれかをお勧めします。
+ **デフォルトの Lambda ランタイムロガーを使用する (推奨)**: Lambda マネージドランタイムによって提供されるデフォルトのログ記録ライブラリには、各ログエントリにリクエスト ID が自動的に含まれます。
+ **構造化 JSON ログ記録の実装**: [カスタムランタイム](runtimes-custom.md)を構築している場合、またはカスタムログ記録が必要な場合は、各エントリにリクエスト ID を含む JSON 形式のログを実装します。Lambda マネージドインスタンスは JSON ログ形式のみをサポートします。JSON ログに `requestId` フィールドを含めて、呼び出しによるフィルタリングを有効にします。
```
{
"timestamp": "2025-01-15T10:30:00.000Z",
"level": "INFO",
"requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"message": "Processing request"
}
```
リクエスト ID 属性を使用すると、CloudWatch Logs Insights クエリを使用して、特定の呼び出しの CloudWatch Logs ログエントリをフィルタリングできます。例えば、次のようになります。
```
fields @timestamp, @message
| filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
| sort @timestamp asc
```
Lambda マネージドインスタンスのログ記録要件の詳細については、「[Lambda マネージドインスタンスの実行環境について理解する](lambda-managed-instances-execution-environment.md)」を参照してください。
# Lambda 関数の CloudWatch Logs を表示する
Lambda 関数の Amazon CloudWatch logs は、Lambda コンソール、CloudWatch コンソール、または AWS Command Line Interface (AWS CLI) を使って表示できます。関数のログにアクセスするには、次のセクションの手順を実行します。
## CloudWatch Logs ライブテールを使用して関数ログをストリーミングする
Amazon CloudWatch Logs ライブテールは、Lambda コンソールで新しいログイベントのストリーミングリストを直接表示することで、関数のトラブルシューティングを迅速に行うのに役立ちます。Lambda 関数から取り込まれたログをリアルタイムで表示、フィルタリングできるため、問題をすばやく検出して解決することができます。
**注記**
Live Tail セッションでは、セッションの使用時間ごとに 1 分間隔でコストが発生します。料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」を参照してください。
### ライブテールと --ログ-タイプテールの比較
CloudWatch Logs ライブテールと Lambda API (AWS CLI の `--log-type Tail`) の [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) オプションには以下のいくつかの違いがあります:
+ `--log-type Tail` は、呼び出しログの最初の 4 KB のみを返します。ライブテールは、この制限を共有せず 1 秒あたり最大 500 件のログイベントを受信できます。
+ `--log-type Tail` はレスポンスでログをキャプチャして送信します。これにより、関数のレスポンスレイテンシーに影響を与える可能性があります。ライブテールは、関数レスポンスのレイテンシーには影響しません。
+ `--log-type Tail` は同期呼び出しのみをサポートします。ライブテールは、同期呼び出しと非同期呼び出しの両方で機能します。
**注記**
[Lambda マネージドインスタンス](lambda-managed-instances.md)は、`--log-type Tail` オプションをサポートしていません。CloudWatch Logs Live Tail を使用するか CloudWatch Logs を直接クエリして、マネージドインスタンス関数のログを表示します。
### アクセス許可
CloudWatch Logs ライブテールセッションを開始および停止するには、以下のアクセス許可が必要です:
+ `logs:DescribeLogGroups`
+ `logs:StartLiveTail`
+ `logs:StopLiveTail`
### Lambda コンソールでライブテールセッションを開始する
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 関数の名前を選択します。
1. **[テスト]** タブを選択します。
1. **[テストイベント]** ペインで、**[CloudWatch Logs ライブテール]** を選択します。
1. **[ロググループを選択]** で、関数のロググループはデフォルトで選択されます。一度に最大 5 つのロググループを選択できます。
1. (オプション) 特定の単語やその他の文字列を含むログイベントのみを表示するときは、その単語または文字列を **[フィルターパターンを追加]** ボックスに入力します。フィルターフィールドでは、大文字と小文字が区別されます。このフィールドには、正規表現 (regex) を含む、複数の用語とパターン演算子を含めることができます。パターン構文の詳細については、「*Amazon CloudWatch Logs ユーザーガイド*」の「[フィルターパターン構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)」を参照してください。
1. **[開始]** を選択します。一致するログイベントがウィンドウに表示されます。
1. Live Tail セッションを停止するには、**[停止]** をクリックします。
**注記**
ライブテールセッションは、15 分間非アクティブ状態になった後、または Lambda コンソールセッションがタイムアウトすると自動的に停止します。
## コンソールを使用して関数ログにアクセスする
1. Lambda コンソールの [[関数]](https://console.aws.amazon.com/lambda/home#/functions) ページを開きます。
1. 関数を選択します。
1. [**Monitor**] (モニタリング) タブを選択します。
1. **[View CloudWatch Logs を表示]** を選択して、CloudWatch コンソールを開きます。
1. 下にスクロールし、表示したい関数呼び出しの**ログストリーム**を選択します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/log-stream.png)
Lambda 関数の各インスタンスには、専用のログストリームがあります。関数がスケールアップした場合は、各同時インスタンスが独自のログストリームを持ちます。呼び出しに応じて新しい実行環境が作成されるたびに、新しいログストリームが生成されます。ログストリームの命名規則は次のとおりです。
```
YYYY/MM/DD[Function version][Execution environment GUID]
```
単一の実行環境は、その存続期間中は同じログストリームに書き込みます。ログストリームには、その実行環境からのメッセージと、Lambda 関数のコードからの出力が含まれます。カスタムログを含め、すべてのメッセージにはタイムスタンプが付けられます。関数がコードからの出力をログに記録しない場合でも、呼び出しごとに 3 つの最小ログステートメントが生成されます (START、END、REPORT)。
![\[モニタリングとオブザーバビリティの図 3\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-3.png)
これらのログには、以下が表示されます。
+ **RequestId** - リクエストごとに生成される一意の ID です。Lambda 関数がリクエストを再試行しても、この ID は変更されず、その後再試行するごとにログに表示されます。
+ **開始/終了** - 単一の呼び出しをブックマークするため、これらの間にあるすべてのログ行は同じ呼び出しに属します。
+ **所要時間** - `INIT` コードを除く、ハンドラー関数の合計呼び出し時間。
+ **請求期間** - 請求目的で四捨五入ロジックを適用します。
+ **メモリサイズ** － 関数に割り当てられたメモリの量。
+ **最大使用メモリ** - 呼び出し中に使用されたメモリの最大量。
+ **初期所要時間** - メインハンドラーの外部で、コードの `INIT` セクションを実行するためにかかった時間。
## AWS CLI を使用したログへのアクセス
AWS CLI は、コマンドラインシェルでコマンドを使用して AWS サービスとやり取りするためのオープンソースツールです。このセクションの手順を完了するには、[AWS CLIバージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) が必要です。
[AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) および `--log-type` コマンドオプションを使用して、呼び出しのログを取得します。レスポンスには、`LogResult`フィールドが含まれ、このフィールドには、呼び出しから base64 コードされた最大 4 KB のログが含まれます。
**Example ログ ID を取得します**
次の例は、`LogResult`という名前の関数の`my-function`フィールドから*ログ ID * を取得する方法を示しています。
```
aws lambda invoke --function-name my-function out --log-type Tail
```
次のような出力が表示されます。
```
{
"StatusCode": 200,
"LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
"ExecutedVersion": "$LATEST"
}
```
**Example ログをデコードします**
同じコマンドプロンプトで、`base64` ユーティリティを使用してログをデコードします。次の例は、`my-function`の base64 でエンコードされたログを取得する方法を示しています 。
```
aws lambda invoke --function-name my-function out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、「*AWS Command Line Interface バージョン 2 用ユーザーガイド*」の「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
以下の出力が表示されます。
```
START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST
"AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib",
END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8
REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB
```
`base64`このユーティリティは、Linux、macOS、および [ Windows の Ubuntu ](https://docs.microsoft.com/en-us/windows/wsl/install-win10) で使用できます。macOS ユーザーは、`base64 -D`を使用する必要があります 。
**Example get-logs.sh スクリプト**
同じコマンドプロンプトで、次のスクリプトを使用して、最後の 5 つのログイベントをダウンロードします。このスクリプトは `sed` を使用して出力ファイルから引用符を削除し、ログが使用可能になるまで 15 秒待機します。この出力には Lambda からのレスポンスと、`get-log-events` コマンドからの出力が含まれます。
次のコードサンプルの内容をコピーし、Lambda プロジェクトディレクトリに `get-logs.sh` として保存します。
AWS CLI バージョン 2 を使用している場合、**cli-binary-format** オプションは必須です。これをデフォルト設定にするには、`aws configure set cli-binary-format raw-in-base64-out` を実行します。詳細については、「*AWS Command Line Interface バージョン 2 用ユーザーガイド*」の「[AWS CLI でサポートされているグローバルコマンドラインオプション](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)」を参照してください。
```
#!/bin/bash
aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out
sed -i'' -e 's/"//g' out
sleep 15
aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
```
**Example macOS および Linux (専用)**
同じコマンドプロンプトで、macOS と Linux ユーザーが次のコマンドを実行して、スクリプトが実行可能であることを確認する必要があります。
```
chmod -R 755 get-logs.sh
```
**Example 最後の 5 つのログイベントを取得します**
同じコマンドプロンプトで、次のスクリプトを実行して、最後の 5 つのログイベントを取得します。
```
./get-logs.sh
```
以下の出力が表示されます。
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
{
"events": [
{
"timestamp": 1559763003171,
"message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n",
"ingestionTime": 1559763003309
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003173,
"message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n",
"ingestionTime": 1559763018353
},
{
"timestamp": 1559763003218,
"message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n",
"ingestionTime": 1559763018353
}
],
"nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795",
"nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080"
}
```
## ログの解析と構造化ログ記録
CloudWatch Logs Insights を使用すると、特殊な[クエリ構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)を使用してログデータを検索および分析できます。複数のロググループに対してクエリを実行し、[グロブ](https://en.wikipedia.org/wiki/Glob_(programming))および[正規表現](https://en.wikipedia.org/wiki/Regular_expression)のパターンマッチングを使用した強力なフィルタリングを提供します。
Lambda 関数に構造化ログ記録を実装することにより、これらの機能を活用できます。構造化ログ記録はログを事前定義された形式に整理し、クエリを容易にします。ログレベルの使用は、情報メッセージを警告やエラーから分離するフィルター対応のログを生成するために重要な最初のステップです。例えば、次の Node.js コードの例を検討します。
```
exports.handler = async (event) => {
console.log("console.log - Application is fine")
console.info("console.info - This is the same as console.log")
console.warn("console.warn - Application provides a warning")
console.error("console.error - An error occurred")
}
```
結果の CloudWatch ログファイルには、ログレベルを指定する個別のフィールドが含まれています。
![\[モニタリングとオブザーバビリティの図 10\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-10.png)
その後、CloudWatch Logs Insights クエリはログレベルでフィルタリングできます。例えば、エラーのみをクエリするには、次のクエリを使用できます。
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
```
### JSON 構造化ログ記録
JSON は、アプリケーションログの構造を提供するために一般的に使用されます。次の例では、ログが JSON に変換されて 3 つの異なる値が出力されます。
![\[モニタリングとオブザーバビリティの図 11\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-11.png)
CloudWatch Logs Insights の機能により、JSON 出力の値が自動的に検出され、メッセージがフィールドとして解析されます。カスタムのグロブや正規表現は必要ありません。JSON 構造化ログを使用することで、次のクエリは、アップロードされたファイルが 1 MB を超え、アップロード時間が 1 秒を超え、呼び出しがコールドスタートではなかった呼び出しを検出します。
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
```
このクエリは、次のような結果を生成する場合があります。
![\[モニタリングとオブザーバビリティの図 12\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-12.png)
JSON で検出されたフィールドは、右側の*検出されたフィールド*メニューに自動的に入力されます。Lambda サービスによって発行された標準フィールドには「@」のプレフィックスが付けられ、同じ方法でこれらのフィールドをクエリできます。Lambda ログには、@timestamp、@logStream、@message、@requestId、@duration、@billedDuration、@type、@maxMemoryUsed、@memorySize フィールドが必ず含まれています。X-Ray が関数に対して有効になっている場合は、@xrayTraceId と @xraySegmentId もログに含まれています。
Amazon S3、Amazon SQS、Amazon EventBridge などの AWS イベントソースが関数を呼び出すと、イベント全体が JSON オブジェクト入力として関数に提供されます。関数の最初の行にこのイベントをログ記録することにより、CloudWatch Logs Insights を使用してネストされた任意のフィールドにクエリを実行できます。
### 便利な Insights クエリ
次の表に、Lambda 関数のモニタリングに役立つ Insights クエリの例を示しています。
| 説明 | のクエリ構文の例 |
| --- | --- |
| 最後の 100 件のエラー |
```
fields Timestamp, LogLevel, Message
\| filter LogLevel == "ERR"
\| sort @timestamp desc
\| limit 100
``` |
| 請求された呼び出しの上位 100 件 |
```
filter @type = "REPORT"
\| fields @requestId, @billedDuration
\| sort by @billedDuration desc
\| limit 100
``` |
| 合計呼び出し数でのコールドスタートの割合 |
```
filter @type = "REPORT"
\| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
coldStartPct, avg(@duration)
by bin(5m)
``` |
| Lambda 期間のパーセンタイルレポート |
```
filter @type = "REPORT"
\| stats
avg(@billedDuration) as Average,
percentile(@billedDuration, 99) as NinetyNinth,
percentile(@billedDuration, 95) as NinetyFifth,
percentile(@billedDuration, 90) as Ninetieth
by bin(30m)
``` |
| Lambda メモリ使用量のパーセンタイルレポート |
```
filter @type="REPORT"
\| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed,
min(@maxMemoryUsed/1024/1024) as min_MemoryUsed,
max(@maxMemoryUsed/1024/1024) as max_MemoryUsed,
percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95
``` |
| 割り当てられたメモリの 100% を使用している呼び出し |
```
filter @type = "REPORT" and @maxMemoryUsed=@memorySize
\| stats
count_distinct(@requestId)
by bin(30m)
``` |
| 呼び出し全体で使用された平均メモリ |
```
avgMemoryUsedPERC,
avg(@billedDuration) as avgDurationMS
by bin(5m)
``` |
| メモリ統計の視覚化 |
```
filter @type = "REPORT"
\| stats
max(@maxMemoryUsed / 1024 / 1024) as maxMemMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB,
min(@maxMemoryUsed / 1024 / 1024) as minMemMB,
(avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct,
avg(@billedDuration) as avgDurationMS
by bin(30m)
``` |
| Lambda が終了した呼び出し |
```
filter @message like /Process exited/
\| stats count() by bin(30m)
``` |
| タイムアウトした呼び出し |
```
filter @message like /Task timed out/
\| stats count() by bin(30m)
``` |
| レイテンシーレポート |
```
filter @type = "REPORT"
\| stats avg(@duration), max(@duration), min(@duration)
by bin(5m)
``` |
| 過剰プロビジョニングされたメモリ |
```
filter @type = "REPORT"
\| stats max(@memorySize / 1024 / 1024) as provisonedMemMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
provisonedMemMB - maxMemUsedMB as overProvisionedMB
``` |
## ログの視覚化とダッシュボード
すべての CloudWatch Logs Insights クエリでは、結果をマークダウン形式または CSV 形式にエクスポートできます。場合によっては、少なくとも 1 つの集計関数があると、[クエリから可視化](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html)を作成する方が便利なことがあります。`stats` 関数を使用すると、集計およびグループ化を定義できます。
前の *logInsightsJSON* の例では、アップロードサイズとアップロード時間でフィルタリングし、最初の呼び出しを除外していました。これにより、データのテーブルが作成されました。本番システムのモニタリングでは、最小、最大、平均のファイルサイズを視覚化して外れ値を見つける方が役立つ場合があります。これを行うには、必要な集計を使用して stats 関数を適用し、毎分などの時間値でグループ化します。
例えば、次のクエリを検討します。これは [JSON 構造化ログ記録](#querying-logs-json) セクションのクエリ例と同じですが、追加の集計関数があります。
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
| stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m)
```
最小、最大、平均のファイルサイズを視覚化して外れ値を見つける方が便利な場合があるため、これらの集計を含めました。結果は **[可視化]** タブで確認できます。
![\[モニタリングとオブザーバビリティの図 14\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-14.png)
視覚化の構築が完了したら、オプションでグラフを CloudWatch ダッシュボードに追加できます。これを行うには、視覚化の上にある **[ダッシュボードに追加]** を選択します。これにより、クエリがウィジェットとして追加され、自動更新間隔を選択できるため、結果を継続的にモニタリングしやすくなります。
![\[モニタリングとオブザーバビリティの図 15\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-observability-figure-15.png)
# Firehose への Lambda 関数ログの送信
Lambda コンソールで、関数ログを Firehose に送信できるようになりました。サードパーティの分析ツールやカスタムエンドポイントなど、Firehose がサポートするさまざまな送信先にログをリアルタイムストリーミングできます。
**注記**
Lambda コンソール、AWS CLI、AWS CloudFormation、およびすべての AWS SDK を使用して、Lambda 関数ログを Firehose に送信するように設定できます。
## 料金
料金の詳細については、「[Amazon CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs)」を参照してください。
## Firehose ログの送信先に必要なアクセス許可
Lambda コンソールを使用して Firehose を関数のログ送信先として設定するには、次の要件を満たす必要があります。
1. Lambda で CloudWatch Logs を使用するのに[必要な IAM アクセス許可](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs)。
1. [Firehose 向けサブスクリプションフィルターの設定](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample)。このフィルターは、どのログイベントを Firehose ストリームに配信するかを定義します。
## Firehose への Lambda 関数ログの送信
Lambda コンソールでは、新しい関数を作成した後に関数ログを Firehose に直接送信できます。これには、次の手順を実行してください。
1. AWS マネジメントコンソールにサインインし、Lambda コンソールを開きます。
1. 関数の名前を選択します。
1. **[設定]** タブを選択します。
1. **モニタリングツールとオペレーションツール**タブを選択します。
1. 「ログ設定」セクションで **[編集]** を選択します。
1. 「ログコンテンツ」セクションでログ形式を選択します。
1. 「ログ送信先」セクションで、次の手順を実行してください。
1. 送信先サービスを選択します。
1. **[新規のロググループを作成]** と **[既存のロググループを使用]** のいずれかを選択します。
**注記**
既存のロググループをFirehose の送信先に設定する場合、設定するロググループが `Delivery` ロググループタイプであることを確認してください。
1. Firehose ストリームを選択します。
1. CloudWatch `Delivery` ロググループが表示されます。
1. **[保存]** を選択します。
**注記**
コンソールで指定した IAM ロールが必要なアクセス許可を持っていないと、送信先のセットアップは失敗します。これを解決するには、「Firehose ログの送信先に必要なアクセス許可」を参照して必要なアクセス許可を付与してください。
## クロスアカウントログ記録
別の AWS アカウントの Firehose 配信ストリームにログを送信するように Lambda を設定できます。送信先を設定すると共に、両方のアカウントで適切なアクセス許可を設定する必要があります。
必要な IAM ロールおよびポリシーなど、クロスアカウントログ記録のセットアップに関する詳細な手順については、CloudWatch Logs ドキュメントの「[Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html)」を参照してください。
# Lambda 関数ログを Amazon S3 に送信する
Lambda コンソールを使用してログを Amazon S3 に直接送信するように Lambda 関数を設定できます。この機能は、コスト効率の高い長期ログストレージソリューションを提供するとともに、Athena などのサービスによる強力な分析オプションの利用を可能にします。
**注記**
これにより、Lambda コンソール、AWS CLI、AWS CloudFormation、あるいはすべての AWS SDK を使用して、Lambda関数ログを Amazon S3 に送信するように設定できます。
## 料金
料金の詳細については、「[Amazon CloudWatch pricing](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs)」を参照してください。
## Amazon S3 ログの送信先に必要なアクセス許可
Lambda コンソールを使用して Amazon S3 を関数のログ送信先に設定するには、次の要件を満たしている必要があります。
1. Lambda で CloudWatch Logs を使用するのに[必要な IAM アクセス許可](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs)。
1. [Amazon S3 への Lambda 関数ログの送信向けに CloudWatch Logs のサブスクリプションフィルターをセットアップする](#using-cwl-subscription-filter-lambda-s3) の実行。このフィルターは、どのログイベントを Amazon S3 バケットに配信するかを定義します。
## Amazon S3 への Lambda 関数ログの送信向けに CloudWatch Logs のサブスクリプションフィルターをセットアップする
CloudWatch Logs から Amazon S3 にログを送信するには、サブスクリプションフィルターを作成する必要があります。このフィルターは、どのログイベントを Amazon S3 バケットに配信するかを定義します。この Amazon S3 バケットは、ロググループと同じリージョンに存在する必要があります。
### Amazon S3 のサブスクリプションフィルターを作成する方法
1. Amazon Simple Storage Service (Amazon S3) バケットを作成します。CloudWatch Logs 専用に作成したバケットを使用することをお勧めします。ただし、既存のバケットを使用する場合は、ステップ 2 に進みます。
次のコマンドを実行します。プレースホルダーリージョンは、使用するリージョンに置き換えます。
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**注記**
`amzn-s3-demo-bucket2` は Amazon S3 バケット名の例です。この名前はすでに*予約*されています。手順が正しく機能するためには、この名前を一意の Amazon S3 バケット名に置き換える必要があります。
出力例を次に示します。
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Amazon S3 バケットにデータを置くため、CloudWatch Logs アクセス許可を付与する IAM ロールを作成します。このポリシーには、「混乱した代理」のセキュリティ問題を防止するための aws:SourceArn グローバル条件コンテキストキーが含まれています。詳細については、「[Confused deputy prevention](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions-confused-deputy.html)」を参照してください。
1. テキストエディタを使用して、次のようにファイル `~/TrustPolicyForCWL.json` 内に信頼ポリシーを作成します。
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. create-role コマンドを使用し、信頼ポリシーファイルを指定して IAM ロールを作成します。後のステップで必要になるため、返された Role.Arn 値を書き留めます。
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. 権限ポリシーを作成し、CloudWatch Logs がアカウントで実行できるアクションを定義します。まず、テキストエディタを使用してファイル `~/PermissionsForCWL.json` で権限ポリシーを作成します。
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
次の `put-role-policy` コマンドを入力して、アクセス許可ポリシーをロールに関連付けます。
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. `Delivery` ロググループを作成するか、もしくは既存の `Delivery` ロググループを使用します。
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. `PutSubscriptionFilter` で送信先をセットアップする
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Lambda 関数ログを Amazon S3 に送信する
Lambda コンソールでは、新しい関数を作成した後に関数ログを Amazon S3 に直接送信できます。これには、次の手順を実行してください。
1. AWS マネジメントコンソールにサインインし、Lambda コンソールを開きます。
1. 関数の名前を選択します。
1. **[設定]** タブを選択します。
1. **モニタリングツールとオペレーションツール**タブを選択します。
1. 「ログ設定」セクションで **[編集]** を選択します。
1. 「ログコンテンツ」セクションでログ形式を選択します。
1. 「ログ送信先」セクションで、次の手順を実行してください。
1. 送信先サービスを選択します。
1. **[新規のロググループを作成]** と **[既存のロググループを使用]** のいずれかを選択します。
**注記**
既存のロググループを Amazon S3 の送信先に設定する場合、設定するロググループが `Delivery` ロググループタイプであることを確認してください。
1. 関数ログの送信先となる Amazon S3 バケットを選択します。
1. CloudWatch `Delivery` ロググループが表示されます。
1. **[保存]** を選択します。
**注記**
コンソールで指定した IAM ロールが必要なアクセス許可を持っていないと、送信先のセットアップは失敗します。これを解決するには、「[Amazon S3 ログの送信先に必要なアクセス許可](#logging-s3-permissions)」を参照してください。
## クロスアカウントログ記録
別の AWS アカウントの Amazon S3 バケットにログを送信するように Lambda を設定できます。送信先を設定すると共に、両方のアカウントで適切なアクセス許可を設定する必要があります。
必要な IAM ロールおよびポリシーなど、クロスアカウントログ記録のセットアップに関する詳細な手順については、CloudWatch Logs ドキュメントの「[Setting up a new cross-account subscription](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html)」を参照してください。
# AWS CloudTrail を使用した AWS Lambda API コールのロギング
AWS Lambda は、ユーザー、ロール、または AWS のサービス によって実行されたアクションの記録を提供するサービスである [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) と統合されています。CloudTrail は Lambda に対する API コールをイベントとしてキャプチャします。キャプチャされた呼び出しには、Lambda コンソールの呼び出しと、Lambda API 操作へのコード呼び出しが含まれます。CloudTrail で収集された情報を使用して、Lambda に対するリクエスト、リクエスト元の IP アドレス、リクエストの作成日時、その他の詳細を確認できます。
各イベントまたはログエントリには、リクエストの生成者に関する情報が含まれます。アイデンティティ情報は、以下を判別するのに役立ちます。
+ ルートユーザーまたはユーザー認証情報のどちらを使用してリクエストが送信されたか。
+ リクエストが IAM Identity Center ユーザーに代わって行われたかどうか。
+ リクエストがロールまたはフェデレーションユーザーのテンポラリなセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが、別の AWS のサービス によって送信されたかどうか。
アカウントを作成すると、AWS アカウント で CloudTrail がアクティブになり、自動的に CloudTrail の**[イベント履歴]** にアクセスできるようになります。CloudTrail の **[イベント履歴]** では、AWS リージョン で過去 90 日間に記録された管理イベントの表示、検索、およびダウンロードが可能で、変更不可能な記録を確認できます。詳細については、「*AWS CloudTrail ユーザーガイド*」の「[CloudTrail イベント履歴の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。**[イベント履歴]** の閲覧には CloudTrail の料金はかかりません。
AWS アカウント で過去 90 日間のイベントを継続的に記録するには、証跡または [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) イベントデータストアを作成します。
**CloudTrail 証跡**
*証跡*により、CloudTrail はログファイルを Amazon S3 バケットに配信できます。AWS マネジメントコンソール を使用して作成した証跡はマルチリージョンです。AWS CLI を使用する際は、単一リージョンまたは複数リージョンの証跡を作成できます。アカウント内のすべて AWS リージョン でアクティビティを把握するため、マルチリージョン証跡を作成することをお勧めします。単一リージョンの証跡を作成する場合、証跡の AWS リージョン に記録されたイベントのみを表示できます。証跡の詳細については、「*AWS CloudTrail ユーザーガイド*」の「[AWS アカウントの証跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)」および「[組織の証跡の作成](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html)」を参照してください。
証跡を作成すると、進行中の管理イベントのコピーを 1 つ無料で CloudTrail から Amazon S3 バケットに配信できますが、Amazon S3 ストレージには料金がかかります。CloudTrail の料金の詳細については、「[AWS CloudTrail の料金](https://aws.amazon.com/cloudtrail/pricing/)」を参照してください。Amazon S3 の料金に関する詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。
**CloudTrail Lake イベントデータストア**
*[CloudTrail Lake]* を使用すると、イベントに対して SQL ベースのクエリを実行できます。CloudTrail Lake は、行ベースの JSON 形式の既存のイベントを [Apache ORC](https://orc.apache.org/) 形式に変換します。ORC は、データを高速に取得するために最適化された単票ストレージ形式です。イベントは、*イベントデータストア*に集約されます。イベントデータストアは、[高度なイベントセレクタ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors)を適用することによって選択する条件に基づいた、イベントのイミュータブルなコレクションです。どのイベントが存続し、クエリに使用できるかは、イベントデータストアに適用するセレクタが制御します。CloudTrail Lake の詳細については、「*AWS CloudTrail ユーザーガイド*」の「[AWS CloudTrail Lake の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html)」を参照してください。
CloudTrail Lake のイベントデータストアとクエリにはコストがかかります。イベントデータストアを作成する際に、イベントデータストアに使用する[料金オプション](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option)を選択します。料金オプションによって、イベントの取り込みと保存にかかる料金、および、そのイベントデータストアのデフォルトと最長の保持期間が決まります。CloudTrail の料金の詳細については、「[AWS CloudTrail の料金](https://aws.amazon.com/cloudtrail/pricing/)」を参照してください。
## CloudTrail の Lambda データイベント
[データイベント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events)では、リソース上またはリソース内で実行されるリソースオペレーション (Amazon S3 オブジェクトの読み取りまたは書き込みなど) についての情報が得られます。これらのイベントは、データプレーンオペレーションとも呼ばれます。データイベントは、多くの場合、高ボリュームのアクティビティです。デフォルトで、ほとんどのデータイベントは CloudTrail でログ記録されません。また、CloudTrail の**イベント履歴**にも記録されません。
サポートされているサービスに対してデフォルトでログ記録される CloudTrail のデータイベントは、`LambdaESMDisabled` です。このイベントを使用して Lambda イベントソースマッピングの問題をトラブルシューティングする方法の詳細については、「[CloudTrail を使用した無効な Lambda イベントソースのトラブルシューティング](#cloudtrail-ESM-troubleshooting)」を参照してください。
追加の変更がイベントデータに適用されます。CloudTrail の料金の詳細については、「[AWS CloudTrail の料金](https://aws.amazon.com/cloudtrail/pricing/)」を参照してください。
CloudTrail コンソール、AWS CLI、または CloudTrail API オペレーションを使用して、 `AWS::Lambda::Function` リソースタイプのデータイベントをログ記録できます。データイベントをログに記録する方法の詳細については、「 *AWS CloudTrailユーザーガイド*」の「 [AWS マネジメントコンソールを使用したデータイベントのログ記録](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console)」および「[AWS Command Line Interfaceを使用したデータイベントのログ記録](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI)」を参照してください。
次の表に、データイベントをログに記録できる Lambda リソースタイプを示します。**データイベントタイプ (コンソール）** 列には、CloudTrail コンソールの**[データイベントタイプ]**リストから選択する値が表示されます。**resources.type 値**列には、AWS CLI または CloudTrail API を使用して高度なイベントセレクタを設定するときに指定する `resources.type` 値が表示されます。**CloudTrail に記録されたデータ API** 列には、リソースタイプの CloudTrail にログ記録された API コールが表示されます。
| データイベントタイプ (コンソール) | resources.type 値 | CloudTrail にログ記録されたデータ API |
| --- | --- | --- |
| Lambda | AWS::Lambda::Function | [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) |
`eventName`、`readOnly`、および `resources.ARN` フィールドでフィルタリングして、自分にとって重要なイベントのみをログに記録するように高度なイベントセレクタを設定できます。次の例は、特定の関数のみのイベントをログ記録するデータイベント設定の JSON ビューです。オブジェクトの詳細については、「*AWS CloudTrail API リファレンス*」の「[https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html)」を参照してください。
```
[
{
"name": "function-invokes",
"fieldSelectors": [
{
"field": "eventCategory",
"equals": [
"Data"
]
},
{
"field": "resources.type",
"equals": [
"AWS::Lambda::Function"
]
},
{
"field": "resources.ARN",
"equals": [
"arn:aws:lambda:us-east-1:111122223333:function:hello-world"
]
}
]
}
]
```
## CCloudTrail の Lambda 管理イベント
[管理イベント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events)では、AWS アカウント のリソースに対して実行される管理オペレーションについての情報が得られます。これらのイベントは、コントロールプレーンオペレーションとも呼ばれます。CloudTrail は、デフォルトで管理イベントをログ記録します。
Lambda は、次のアクションを管理イベントとして CloudTrail ログファイルに記録することをサポートしています。
**注記**
CloudTrail ログファイルでは、 `eventName` に日付やバージョン情報が含まれる場合がありますが、同じ公開 API アクションを指しています。例えば、`GetFunction` のアクションが `GetFunction20150331v2` として表示される場合があります。次のリストは、イベント名が API アクション名と異なるタイミングを指定します。
+ [AddLayerVersionPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) (イベント名: `AddPermission20150331v2`）
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html) (イベント名: `CreateAlias20150331`）
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html) (イベント名: `CreateEventSourceMapping20150331`）
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html) (イベント名: `CreateFunction20150331`）
(`Environment` および `ZipFile` パラメータは、`CreateFunction` では CloudTrail ログから省かれます)。
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html) (イベント名: `DeleteAlias20150331`）
+ [DeleteCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteCodeSigningConfig.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html) (イベント名: `DeleteEventSourceMapping20150331`）
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html) (イベント名: `DeleteFunction20150331`）
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html) (イベント名: `DeleteFunctionConcurrency20171031`）
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html) (イベント名: `GetAlias20150331`）
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetLayerVersionPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetLayerVersionPolicy.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
+ [PublishLayerVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html) (イベント名: `PublishLayerVersion20181031`）
(`ZipFile` パラメータは、`PublishLayerVersion` では CloudTrail ログから省かれます)。
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) (イベント名: `PublishVersion20150331`）
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html) (イベント名: `PutFunctionConcurrency20171031`）
+ [PutFunctionCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionCodeSigningConfig.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html) (イベント名: `RemovePermission20150331v2`）
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) (イベント名: `TagResource20170331v2`）
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) (イベント名: `UntagResource20170331v2`）
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html) (イベント名: `UpdateAlias20150331`）
+ [UpdateCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateCodeSigningConfig.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) (イベント名: `UpdateEventSourceMapping20150331`）
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) (イベント名: `UpdateFunctionCode20150331v2`）
(`ZipFile` パラメータは、`UpdateFunctionCode` では CloudTrail ログから省かれます)。
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) (イベント名: `UpdateFunctionConfiguration20150331v2`）
(`Environment` パラメータは、`UpdateFunctionConfiguration` では CloudTrail ログから省かれます)。
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
## CloudTrail を使用した無効な Lambda イベントソースのトラブルシューティング
API アクション [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html) を使用してイベントソースマッピングの状態を変更すると、API コールは管理イベントとして CloudTrail でログ記録されます。イベントソースマッピングは、エラーが原因で `Disabled` 状態に直接移行することもあります。
次のサービスでは、イベントソースが Disabled 状態に移行する際、Lambda により CloudTrail に `LambdaESMDisabled` データイベントが発行されます。
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon DynamoDB
+ Amazon Kinesis
Lambda は、他のイベントソースマッピングタイプでこのイベントをサポートしていません。
サポートされているサービスのイベントソースマッピングが `Disabled` 状態に移行した際にアラートを受信するには、CloudTrail イベント `LambdaESMDisabled` を使用して Amazon CloudWatch でアラームを設定します。CloudWatch アラームの設定についての詳細は、[「Creating CloudWatch alarms for CloudTrail events: examples](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html)」を参照してください。
`LambdaESMDisabled` イベントメッセージの `serviceEventDetails` エンティティには、次のいずれかのエラーコードが含まれます。
**`RESOURCE_NOT_FOUND`**
リクエストで指定されたリソースは存在しません。
**`FUNCTION_NOT_FOUND`**
イベントソースにアタッチされている関数が存在しません。
**`REGION_NAME_NOT_VALID`**
イベントソースまたは関数に指定されたリージョン名が無効です。
**`AUTHORIZATION_ERROR`**
アクセス許可が設定されていないか、正しく設定されていません。
**`FUNCTION_IN_FAILED_STATE`**
関数コードがコンパイルされない、回復不能な例外が発生した、または不正なデプロイが発生しました。
## Lambda イベントの例
各イベントは任意の送信元からの単一のリクエストを表し、リクエストされた API オペレーション、オペレーションの日時、リクエストパラメーターなどに関する情報を含みます。CloudTrail ログファイルは、パブリック API コールの順序付けられたスタックトレースではないため、イベントは特定の順序で表示されません。
以下は、`GetFunction` アクションと `DeleteFunction` アクションの CloudTrail ログエントリの例です。
**注記**
`eventName`には、`"GetFunction20150331"`のような日付やバージョン情報が含まれることがありますが、同じ公開 API を指しています。
```
{
"Records": [
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:03:36Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "GetFunction",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111122223333:user/myUserName is not authorized to perform: lambda:GetFunction on resource: arn:aws:lambda:us-west-2:111122223333:function:other-acct-function",
"requestParameters": null,
"responseElements": null,
"requestID": "7aebcd0f-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "e92a3e85-8ecd-4d23-8074-843aabfe89bf",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
},
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:04:42Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "DeleteFunction20150331",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"requestParameters": {
"functionName": "basic-node-task"
},
"responseElements": null,
"requestID": "a2198ecc-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "20b84ce5-730f-482e-b2b2-e8fcc87ceb22",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
]
}
```
CloudTrail レコードの内容については、「*AWS CloudTrail ユーザーガイド*」の「[CloudTrail record contents](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html)」を参照してください。
# AWS X-Ray を使用した Lambda 関数呼び出しの視覚化
AWS X-Ray を使用して、アプリケーションのコンポーネントの視覚化、パフォーマンスのボトルネックの特定、およびエラーの原因となったリクエストのトラブルシューティングを行うことができます。Lambda 関数はトレースデータを X-Ray に送信し、X-Ray はデータを処理してサービスマップと検索可能なトレースサマリーを生成します。
Lambda は、X-Ray の 2 つのトレースモード (`Active` および `PassThrough`) をサポートしています。`Active` トレースでは、Lambda は関数呼び出しのトレースセグメントを自動的に作成して X-Ray に送信します。一方、`PassThrough` モードでは、トレースコンテキストをダウンストリームサービスに伝達するだけです。関数の `Active` トレースを有効にしている場合、Lambda はサンプリングされたリクエストのトレースを X-Ray に自動的に送信します。通常、Amazon API Gateway などのアップストリームサービスや、X-Ray SDK でインストルメントされた Amazon EC2 でホストされているアプリケーションは、着信リクエストをトレースする必要があるかどうかを判断してから、そのサンプリングデシジョンをトレースヘッダーとして追加します。Lambda は、そのヘッダーを使用してトレースを送信するかどうかを決定します。Amazon SQS などの上流のメッセージプロデューサーからのトレースは、下流の Lambda 関数からのトレースに自動的にリンクされるため、アプリケーション全体のエンドツーエンドのビューが作成されます。詳細については、「*AWS X-Ray デベロッパーガイド*」の「[イベント駆動型アプリケーションのトレース](https://docs.aws.amazon.com//xray/latest/devguide/xray-tracelinking.html)」を参照してください。
**注記**
X-Ray トレースは、現在、Amazon Managed Streaming for Apache Kafka (Amazon MSK)、セルフマネージド Apache Kafka、ActiveMQ と RabbitMQ 向けの Amazon MQ、または Amazon DocumentDB イベントソースマッピングを備えた Lambda 関数ではサポートされていません。
コンソールを使用して、Lambda 関数のアクティブトレースをオンにするには、次のステップに従います。
**アクティブトレースをオンにするには**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. **[設定]** を選択してから、**[モニタリングおよび運用ツール]** を選択します。
1. **[その他の監視ツール]** で、**[編集]** を選択します。
1. **[CloudWatch Application Signals と AWS X-Ray]** で、**[Lambda サービストレース]** の **[有効]** を選択します。
1. **[保存]** を選択します。
関数には、トレースデータを X-Ray にアップロードするためのアクセス許可が必要です。Lambda コンソールでトレースを有効にすると、Lambda は必要な権限を関数の [[実行ロール]](lambda-intro-execution-role.md) に追加します。それ以外の場合は、[AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess) ポリシーを実行ロールに追加します。
X-Ray は、アプリケーションへのすべてのリクエストをトレースするとは限りません。X-Ray は、サンプリングアルゴリズムを適用することで効率的なトレースを行うと同時に、すべてのリクエストについての代表的なサンプルを示します。サンプルレートは 1 秒あたり 1 回のリクエストで、追加リクエストの 5％ です。関数の X-Ray サンプルレートを設定することはできません。
## X-Ray トレースを理解する
X-Ray では、*トレース*は 1 つ以上の*サービス*によって処理されるリクエストに関する情報を記録します。Lambda はトレースごとに 2 つのセグメントを記録します。これにより、サービスグラフに 2 つのノードが作成されます。次の図は、これら 2 つのノードを強調表示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/xray-servicemap-function.png)
左に示された 1 つめのノードは、呼び出しリクエストを受信する Lambda サービスを表しています。2 つめのノードは、特定の Lambda 関数を表しています。
Lambda サービス用に記録されたセグメント `AWS::Lambda` は、Lambda 実行環境を準備するために必要なすべての手順をカバーしています。これには、MicroVM のスケジューリング、設定したリソースを使用した実行環境の作成またはフリーズ解除、関数コードとすべてのレイヤーのダウンロードが含まれます。
`AWS::Lambda::Function` セグメントは、関数によって実行される作業のためのものです。
**注記**
AWS は現在、Lambda サービスに変更を実装しています。これらの変更により、AWS アカウント のさまざまな Lambda 関数によって出力されるシステムログメッセージとトレースセグメントの構造と内容にわずかな違いが生じる場合があります。
この変更は、関数セグメントのサブセグメントに影響します。次の段落では、これらのサブセグメントの古い形式と新しい形式の両方について説明します。
これらの変更は今後数週間に実装され、中国および GovCloud リージョンを除くすべての AWS リージョンのすべての関数は、新しい形式のログメッセージとトレースセグメントを使用するように移行されます。
**古いスタイルの AWS X-Ray Lambda セグメント構造**
`AWS::Lambda` セグメントの古いスタイルの X-Ray 構造は次のようになります。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/V2_sandbox_images/v1_XRay_structure.png)
この形式では、関数セグメントには `Initialization`、`Invocation`、および `Overhead` のサブセグメントがあります。[Lambda SnapStart](snapstart.md) のみ、`Restore` サブセグメントも存在します (この図には示されていません)。
`Initialization` サブセグメントは、Lambda 実行環境ライフサイクルの初期フェーズを表します。このフェーズでは、Lambda は拡張機能を初期化し、ランタイムを初期化して、関数の初期化コードを実行します。
`Invocation` サブセグメントは呼び出しフェーズを現し、Lambda は関数ハンドラーを呼び出します。これはランタイムと拡張機能の登録から始まり、ランタイムが応答を送信する準備ができたら完了します。
(Lambda SnapStart のみ) `Restore` サブセグメントは、Lambda がスナップショットを復元し、ランタイムをロードし、復元後の[ランタイムフック](snapstart-runtime-hooks.md)を実行するのにかかる時間を表しています。スナップショットを復元するプロセスには、MicroVM 外部でのアクティビティに費やす時間が含まれる場合があります。この時間は、`Restore` サブセグメントで報告されます。MicroVM 外部でスナップショットの復元に費やした時間については課金されません。
`Overhead` サブセグメントは、ランタイムが応答を送信してから、次の呼び出しのシグナルを送信するまでの間に発生するフェーズを表します。この間、ランタイムは呼び出しに関連するすべてのタスクを終了し、サンドボックスをフリーズする準備をします。
**重要**
X-Ray SDK を使用すると、ダウンストリーム呼び出し、注釈、およびメタデータ用の追加のサブセグメントで `Invocation` サブセグメントを拡張できます。関数セグメントに直接アクセスしたり、ハンドラーの呼び出しスコープの外で行われた作業を記録したりすることはできません。
Lambda 実行環境の詳細については、「[Lambda 実行環境のライフサイクルの概要](lambda-runtime-environment.md)」を参照してください。
次の図に、古いスタイルの X-Ray 構造を使用したトレースの例を示します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
この例の 2 つのセグメントに注意してください。いずれも **my-function** と名付けられていますが、1 つは `AWS::Lambda` の起点があり、もう 1 つは `AWS::Lambda::Function` の起点があります。`AWS::Lambda` セグメントにエラーが表示される場合は、Lambda サービスに問題があります。`AWS::Lambda::Function` セグメントにエラーが表示される場合、関数に問題があります。
**注記**
時折、X-Ray トレースの関数初期化フェーズと呼び出しフェーズの間に大きなギャップがあることに気付くことがあります。[プロビジョニングされた同時実行](provisioned-concurrency.md)を使用する関数の場合、これが発生するのは Lambda が呼び出しに先立って関数インスタンスを初期化するからです。[予約されていない (オンデマンド) 同時実行](lambda-concurrency.md)を使用する関数の場合、Lambda は、呼び出しがない場合でも先を見越して関数インスタンスを初期化することがあります。視覚的には、これらのケースの両方が、初期化フェーズと呼び出しフェーズ間における時間のギャップとして表示されます。
**新しいスタイルの AWS X-Ray Lambda セグメント構造**
`AWS::Lambda` セグメントの新しいスタイルの X-Ray 構造は次のようになります。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/V2_sandbox_images/v2_XRay_structure.png)
この新しい形式では、`Init` サブセグメントは、以前と同様に Lambda 実行環境ライフサイクルの初期化フェーズを表します。
新しい形式には呼び出しセグメントはありません。代わりに、顧客サブセグメントが `AWS::Lambda::Function` セグメントに直接アタッチされます。このセグメントには、注釈として次のメトリクスが含まれています。
+ `aws.responseLatency` – 関数の実行にかかる時間
+ `aws.responseDuration` – 顧客へのレスポンスの転送にかかる時間
+ `aws.runtimeOverhead` – ランタイムの終了に必要な追加時間
+ `aws.extensionOverhead` – 拡張機能の終了に必要な追加時間
新しいスタイルの X-Ray 構造を使用したトレースの例を次の図に示します。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v2.png)
この例の 2 つのセグメントに注意してください。いずれも **my-function** と名付けられていますが、1 つは `AWS::Lambda` の起点があり、もう 1 つは `AWS::Lambda::Function` の起点があります。`AWS::Lambda` セグメントにエラーが表示される場合は、Lambda サービスに問題があります。`AWS::Lambda::Function` セグメントにエラーが表示される場合、関数に問題があります。
Lambda のトレースに関する各言語での概要については、次のトピックを参照してください。
+ [AWS Lambda での Node.js コードの作成](nodejs-tracing.md)
+ [AWS Lambda での Python コードの作成](python-tracing.md)
+ [AWS Lambda での Ruby の作成](ruby-tracing.md)
+ [AWS Lambda での Java コードの作成](java-tracing.md)
+ [AWS Lambda での Go コードの作成](golang-tracing.md)
+ [AWS Lambda での C\$1 コードの作成](csharp-tracing.md)
アクティブなインストルメンテーションをサポートするサービスの詳細なリストについては、「AWS X-Ray デベロッパーガイド」の「[サポート対象の AWS のサービス](https://docs.aws.amazon.com/xray/latest/devguide/xray-usage.html#xray-usage-codechanges)」を参照してください。
## Lambda でのデフォルトのトレース動作
`Active` トレースを有効にしていない場合、Lambda はデフォルトで `PassThrough` トレースモードになります。
`PassThrough` モードでは、Lambda は X-Ray トレースヘッダーをダウンストリームサービスに転送しますが、トレースは自動的に送信しません。これは、トレースヘッダーにリクエストをサンプリングする決定が含まれている場合でも当てはまります。アップストリームサービスが X-Ray トレースヘッダーを提供しない場合、Lambda はヘッダーを生成し、サンプリングしないという決定をします。ただし、関数コードからトレースライブラリを呼び出すことで、独自のトレースを送信できます。
**注記**
以前は、Lambda は、Amazon API Gateway などのアップストリームサービスがトレースヘッダーを追加したときにトレースを自動的に送信していました。Lambda からトレースを自動的に送信しないようにすると、ユーザーは重要な関数のトレースを制御できます。お使いのソリューションがこのパッシブトレース動作に依存している場合は、`Active` トレースに切り替えてください。
## 実行ロールのアクセス許可
Lambda には、トレースデータを X-Ray に送信するために次のアクセス許可が必要です。これを関数の[実行ロール](lambda-intro-execution-role.md)に追加します。
+ [xray:PutTraceSegments](https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html)
+ [xray:PutTelemetryRecords](https://docs.aws.amazon.com/xray/latest/api/API_PutTelemetryRecords.html)
これらのアクセス許可は、[AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess) 管理ポリシーに含まれています。
## Lambda API での `Active` トレースの有効化
AWS CLI または AWS SDK を使用してトレース設定を管理するには、以下の API オペレーションを使用します。
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
以下の例の AWS CLI コマンドは、**my-function** という名前の関数に対するアクティブトレースを有効にします。
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
トレースモードは、関数のバージョンを公開するときのバージョン固有の設定の一部です。公開後のバージョンのトレースモードを変更することはできません。
## CloudFormation での`Active` トレースの有効化
CloudFormation テンプレート内で `AWS::Lambda::Function` リソースに対するアクティブトレースを有効化するには、`TracingConfig` プロパティを使用します。
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) － トレース設定**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
AWS Serverless Application Model (AWS SAM) `AWS::Serverless::Function` リソースに、`Tracing` プロパティを使用します。
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) － トレース設定**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
# Amazon CloudWatch Lambda Insights を使用した関数パフォーマンスのモニタリング
Amazon CloudWatch Lambda Insights は、サーバーレスアプリケーションの Lambda 関数ランタイムパフォーマンスメトリクスとログを収集および集計します。このページでは、Lambda Insights を有効にして Lambda 関数に関する問題の診断に使用する方法について説明します。
**Topics**
+ [Lambda Insights によるサーバーレスアプリケーションのモニタリング方法](#monitoring-insights-how)
+ [料金](#monitoring-insights-pricing)
+ [ランタイムのサポート](#monitoring-insights-runtimes)
+ [Lambda コンソールで Lambda Insights を有効にする](#monitoring-insights-enabling-console)
+ [Lambda Insights をプログラムで有効にする](#monitoring-insights-enabling-programmatically)
+ [Lambda Insights ダッシュボードの使用](#monitoring-insights-multifunction)
+ [関数の異常を検出するワークフローの例](#monitoring-insights-anomalies)
+ [クエリを使用して関数のトラブルシューティングを行うワークフローの例](#monitoring-insights-queries)
+ [次のステップ](#monitoring-console-next-up)
## Lambda Insights によるサーバーレスアプリケーションのモニタリング方法
CloudWatch Lambda Insights は、 で実行されているサーバーレスアプリケーション用のモニタリングおよびトラブルシューティングソリューションですAWS Lambda このソリューションでは、CPU 時間、メモリ、ディスク、ネットワーク使用率などのシステムレベルのメトリクスが収集、集約、要約されます。また、コールドスタートや Lambda ワーカーシャットダウンなどの診断情報が収集、集約、要約されるため、Lambda 関数に関する問題を特定し、迅速に解決できます。
Lambda Insights は、[Lambda レイヤー](chapter-layers.md)として提供される新しい CloudWatch Lambda [拡張機能](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html)を使用します。この拡張機能を、サポートされているランタイムで、Lambda 関数で有効にすると、システムレベルのメトリクスが収集され、その Lambda 関数の呼び出しごとに 1 つのパフォーマンスログイベントが発生します。CloudWatch は、埋め込みメトリクスフォーマットを使用して、ログイベントからメトリクスを抽出します。詳細については、「[AWS Lambda 拡張機能の使用](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html)」を参照してください。
Lambda Insights レイヤーは、`/aws/lambda-insights/` ロググループ用に `CreateLogStream` および `PutLogEvents` を拡張します。
## 料金
Lambda 関数に対して Lambda Insights を有効にすると、Lambda Insights は関数ごとに 8 つのメトリックスを報告し、関数呼び出しごとに約 1 KB のログデータが CloudWatch に送信されます。料金は、Lambda Insights によって関数に関してレポートされたメトリックスとログに対してのみ発生します。最低料金やサービス使用義務はありません。関数が呼び出されない場合、Lambda Insights に対する支払いはありません。料金の例については、[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)を参照してください。
## ランタイムのサポート
Lambda Insights は、[Lambda 拡張機能](runtimes-extensions-api.md)をサポートする任意のランタイムで使用できます。
## Lambda コンソールで Lambda Insights を有効にする
新規および既存の Lambda 関数で、Lambda Insights 拡張モニタリングを有効にできます。サポートされているランタイムの Lambda コンソールの関数で Lambda Insights を有効にすると、Lambda は Lambda Insights [拡張機能](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html)をレイヤーとして関数に追加し、関数の[実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)に必要な [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) ポリシーを検証するか、アタッチしようとします。
**Lambda コンソールで Lambda Insights を有効にするには**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. [**設定**] タブを選択します。
1. 左側のメニューで **[モニタリングおよび運用ツール]** を選択します。
1. **[その他の監視ツール]** ペインで、**[編集]** を選択します。
1. **[CloudWatch Lambda インサイト]** で、**[拡張モニタリング]** をオンにします。
1. [**Save**] を選択します。
## Lambda Insights をプログラムで有効にする
Lambda Insights は、AWS Command Line Interface (AWS CLI)、AWS Serverless Application Model (SAM) CLI、CloudFormation、または、AWS Cloud Development Kit (AWS CDK)を使用して有効にすることもできます。Lambda Insights を、プログラムを使って、サポートされているランタイムの関数で有効にすると、CloudWatch は、[https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) ポリシーを関数の[実行ロール](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html)にアタッチします。
詳細については、*Amazon CloudWatch ユーザーガイド*の [Lambda Insights を使用する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-Getting-Started.html)を参照してください。
## Lambda Insights ダッシュボードの使用
Lambda Insights のダッシュボードには、CloudWatch コンソールに multi-function overview と single-function view という 2 つの画面があります。multi-function overview では、現在の AWS アカウントとリージョンの Lambda 関数のランタイムメトリクスが集計されます。single-function view では、単一の Lambda 関数で使用可能なランタイムメトリクスが表示されます。
Lambda Insights ダッシュボードの CloudWatch コンソールにある multi-function overview を使用して、使用率の高い Lambda 関数と使用率の低い Lambda 関数を識別できます。Lambda Insights ダッシュボードの CloudWatch コンソールにある single-function view を使用して、個々のリクエストのトラブルシューティングを行うことができます。
**すべての関数のランタイムメトリクスを表示するには**
1. CloudWatch コンソールで [[Multi-function (複数の関数)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance)] ページを開きます。
1. 定義済みの時間範囲から選択するか、カスタムの時間範囲を選択します。
1. (オプション) CloudWatch ダッシュボードにウィジェットを追加するには、[**Add to dashboard (ダッシュボードに追加)**] を選択します。
![\[Lambda Insights ダッシュボードの multi-function overview。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-multifunction-view.png)
**1 つの関数のランタイムメトリクスを表示するには**
1. CloudWatch コンソールで [[Single-function (単一の関数)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions)] ページを開きます。
1. 定義済みの時間範囲から選択するか、カスタムの時間範囲を選択します。
1. (オプション) CloudWatch ダッシュボードにウィジェットを追加するには、[**Add to dashboard (ダッシュボードに追加)**] を選択します。
![\[Lambda Insights ダッシュボードの single-function view。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambainsights-singlefunction-view.png)
詳細については、[CloudWatch ダッシュボードでのウィジェットの作成と操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html)を参照してください。
## 関数の異常を検出するワークフローの例
Lambda Insights ダッシュボードの multi-function overview を使用して、関数でのコンピュートメモリの異常を特定および検出できます。例えば、multi-function overview で、関数が大量のメモリを使用していることが示されている場合、[**Memory Usage**] ペインで詳細なメモリ使用率メトリクスを表示できます。その後、[Metrics] ダッシュボードに移動して、異常検出を有効にするか、アラームを作成できます。
**関数の異常検出を有効にするには**
1. CloudWatch コンソールで [[Multi-function (複数の関数)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance)] ページを開きます。
1. [**Function summary**] で、関数の名前を選択します。
single-function view が開き、関数のランタイムメトリクスが表示されます。
![\[Lambda Insights ダッシュボードの関数概要ペイン。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-function-summary.png)
1. [**Memory Usage**] ペインで、3 つの縦のドットを選択し、[**View in metrics**] を選択して [**Metrics**] ダッシュボードを開きます。
![\[[Memory Usage (メモリ使用状況)] ペインのメニュー。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-memory-usage.png)
1. [**Graphed Metrics**] タブの [**Actions**] 列で、最初のアイコンを選択して関数の異常検出を有効にします。
![\[[Memory Usage (メモリ使用状況)] ペインの [Graphed Metrics (グラフ化されたメトリクス)] タブ\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-graphed-metrics.png)
詳細については、[CloudWatch の異常検出の使用方法](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)を参照してください。
## クエリを使用して関数のトラブルシューティングを行うワークフローの例
Lambda Insights ダッシュボードの single-function view を使用して、関数の所要時間が急増する根本原因を特定できます。例えば、multi-function overview で関数の所要時間が大きく増加している場合は、[**Duration**] ペインで一時停止するか、各関数を選択して、どの関数が増加の原因になっているかを判断できます。次に、single-function view に移動し、[**Application logs**] を確認して、根本原因を特定できます。
**関数に対してクエリを実行するには**
1. CloudWatch コンソールで [[Multi-function (複数の関数)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance)] ページを開きます。
1. [**Duration**] ペインで、所要時間メトリクスをフィルタリングする関数を選択します。
![\[[Duration (所要時間)] ペインで選択された関数。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-choose-function.png)
1. [[Single-function (単独の関数)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions)] ページを開きます。
1. [**Filter metrics by function name**] ドロップダウンリストを選択し、関数を選択します。
1. [**Most recent 1000 application logs**] を表示するには、[**Application logs**] タブを選択します。
1. [**Timestamp**] と [**Message**] を確認し、トラブルシューティングを行う呼び出しリクエストを特定します。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-application-logs.png)
1. **最新の 1000 の呼び出し**] を表示するには、[**Invocations (呼び出し)**] タブを選択します。
1. トラブルシューティングを行う呼び出しリクエストの [**Timestamp**] または [**Message**] を選択します。
![\[最近の呼び出しリクエストを選択します。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-invocations-function-select.png)
1. [**View logs**] ドロップダウンリストを選択し、[**View performance logs**] を選択します。
関数の自動生成されたクエリが [**Logs Insights**] ダッシュボードで開きます。
1. [**Run query**] を選択して、呼び出しリクエストの [**Logs**] メッセージを生成します。
![\[[Logs Insights] (ログインサイト) ダッシュボードで選択した関数をクエリします。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/lambdainsights-query.png)
## 次のステップ
+ CloudWatch Logs ダッシュボードの作成方法については、*Amazon CloudWatch ユーザーガイド*の [Create a Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html) を参照してください。
+ CloudWatch Logs ダッシュボードにクエリを追加する方法については、*Amazon CloudWatch ユーザーガイド*の [Add Query to Dashboard or Export Query Results](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) を参照してください。
# Lambda アプリケーションのモニタリング
Lambda コンソールの **[アプリケーション]** セクションには **[モニタリング]** タブが含まれており、アプリケーション内のリソースの集計メトリクスが表示された Amazon CloudWatch ダッシュボードを確認できます。
**Lambda アプリケーションをモニタリングするには**
1. Lambda コンソールの [[Applications (アプリケーション)] ページ](https://console.aws.amazon.com/lambda/home#/applications)を開きます。
1. [**モニタリング**] を選択します。
1. グラフ内のメトリクスの詳細を表示するには、ドロップダウンメニューから **[メトリクスで表示]** を選択します。
![\[モニタリングウィジェット。\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/applications-monitoring-widget.png)
グラフが新しいタブで開き、関連するメトリクスがグラフの下に一覧表示されます。このグラフの表示はカスタマイズできます。表示されるメトリクスやリソースを変更し、統計や期間などの要因を変更することで、現在の状況を詳しく理解できます。
デフォルトでは、Lambda コンソールにベーシックなダッシュボードが表示されます。このページをカスタマイズするには、1 つ以上の Amazon CloudWatch ダッシュボードを、[AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html) リソースタイプのアプリケーションテンプレートに追加します。テンプレートの 1 つ以上のダッシュボードが含まれている場合、このページにはデフォルトのダッシュボードではなく、使用するダッシュボードが表示されます。ページの右上のドロップダウンメニューから、ダッシュボードを切り替えることができます。次の例では、`my-function` という名前の関数を呼び出す数をグラフ化する単一のウィジェットのダッシュボードを作成します。
**Example 関数ダッシュボードのテンプレート**
```
Resources:
MyDashboard:
Type: AWS::CloudWatch::Dashboard
Properties:
DashboardName: my-dashboard
DashboardBody: |
{
"widgets": [
{
"type": "metric",
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/Lambda",
"Invocations",
"FunctionName",
"my-function",
{
"stat": "Sum",
"label": "MyFunction"
}
],
[
{
"expression": "SUM(METRICS())",
"label": "Total Invocations"
}
]
],
"region": "us-east-1",
"title": "Invocations",
"view": "timeSeries",
"stacked": false
}
}
]
}
```
CloudWatch ダッシュボードとウィジェットの作成の詳細については、*Amazon CloudWatch API リファレンス*の「[Dashboard body structure and syntax](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html)」を参照してください。
# Amazon CloudWatch Application Signals によるアプリケーションパフォーマンスのモニタリング
Amazon CloudWatch Application Signals は、デベロッパーとオペレーターが Lambda を使用して作成されたサーバーレスアプリケーションのヘルスとパフォーマンスをモニタリングできるようにするアプリケーションパフォーマンスモニタリング (APM) ソリューションです。Lambda コンソールからワンクリックで Application Signals を有効にできるため、Lambda 関数に計測コードや外部依存関係を追加する必要はありません。Application Signals を有効にすると、収集されたすべてのメトリクスとトレースを CloudWatch コンソールで表示できます。このページでは、アプリケーションの Application Signals テレメトリデータを有効にして表示する方法について説明します。
**Topics**
+ [Application Signals と Lambda の統合方法](#monitoring-application-signals-how)
+ [料金](#monitoring-application-signals-pricing)
+ [ランタイムのサポート](#monitoring-application-signals-runtimes)
+ [Lambda コンソールで Application Signals を有効にする](#monitoring-application-signals-console)
+ [Application Signals ダッシュボードの使用](#monitoring-application-signals-dashboard)
## Application Signals と Lambda の統合方法
Application Signals は、[Lambda レイヤー](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)を介して提供される拡張 [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/) ライブラリを使用して、Lambda 関数を自動的に計測します。Application Signals は、レイヤーによって収集されたデータを読み取り、アプリケーションの主要なパフォーマンスメトリクスでダッシュボードを生成します。
Lambda コンソールで [Application Signals を有効にする](#monitoring-application-signals-console)と、このレイヤーをワンクリックでアタッチできます。コンソールから Application Signals を有効にすると、Lambda はユーザーに代わって次の処理を実行します。
+ 関数の実行ロールを更新して、`CloudWatchLambdaApplicationSignalsExecutionRolePolicy` を追加します。[このポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.html)によって、Application Signals に使用される AWS X-Ray および CloudWatch ロググループへの書き込みアクセス権が付与されます。
+ 関数にレイヤーを追加します。このレイヤーは関数を自動的に計測して、リクエスト、可用性、レイテンシー、エラー、障害などのテレメトリデータをキャプチャします。Application Signals が適切に動作するには、関数から既存の X-Ray SDK 計測コードをすべて削除します。カスタム X-Ray SDK 計測コードは、レイヤーによる計測を妨げる可能性があります。
+ `AWS_LAMBDA_EXEC_WRAPPER` 環境変数を関数に追加し、その値を `/opt/otel-instrument` に設定します。この環境変数は、関数の起動動作を変更して Application Signals レイヤーを利用するため、適切な計測に必要です。この環境変数が既に存在する場合は、必要な値に設定されていることを確認してください。
## 料金
Lambda 関数に Application Signals を使用すると、料金が発生します。料金については、[Amazon CloudWatch 料金表](https://aws.amazon.com/cloudwatch/pricing/)を参照してください。
## ランタイムのサポート
Application Signals と Lambda の統合は、次のランタイムで機能します。
+ .NET 8
+ Java 11
+ Java 17
+ Java 21
+ Python 3.10
+ Python 3.11
+ Python 3.12
+ Python 3.13
+ Node.js 18.x
+ Node.js 20.x
+ Node.js 22.x
## Lambda コンソールで Application Signals を有効にする
[サポートされているランタイム](#monitoring-application-signals-runtimes)を使用して、既存の Lambda 関数で Application Signals を有効にできます。次の手順では、Lambda コンソールでワンクリックで Application Signals を有効にする方法について説明します。
**Lambda コンソールで Application Signals を有効にするには**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. [**設定**] タブを選択します。
1. 左側のメニューで **[モニタリングおよび運用ツール]** を選択します。
1. **[その他の監視ツール]** ペインで、**[編集]** を選択します。
1. **[CloudWatch Application Signals と AWS X-Ray]**、および **[Application Signals]** で、**[有効]** を選択します。
1. **[保存]** を選択します。
関数で Application Signals を初めて有効にする場合は、CloudWatch コンソールで Application Signals の 1 回限りのサービス検出設定も実行する必要があります。この 1 回限りのサービス検出設定を完了すると、Application Signals は、Application Signals を有効にしたその他の Lambda 関数をすべてのリージョンで自動的に検出します。
**注記**
更新された関数を呼び出すと、サービスデータが CloudWatch コンソールの Application Signals ダッシュボードに表示され始めるまでに最大 10 分かかる場合があります。
## Application Signals ダッシュボードの使用
関数の Application Signals を有効にすると、CloudWatch コンソールでアプリケーションメトリクスを視覚化できます。以下の手順に従って、Lambda コンソールで関連する Application Signals ダッシュボードをすばやく表示できます。
**関数の Application Signals ダッシュボードを表示するには**
1. Lambda コンソールの [[関数ページ]](https://console.aws.amazon.com/lambda/home#/functions) を開きます。
1. 関数を選択します。
1. [**Monitor**] (モニタリング) タブを選択します。
1. **[Application Signals を表示]** ボタンを選択します。これにより、CloudWatch コンソールでサービスの Application Signals の概要に直接アクセスできます。
例えば、次のスクリーンショットは、10 分間の時間枠における関数のレイテンシー、リクエスト数、可用性、障害率、エラー率のメトリクスを示しています。
![\[\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/monitoring-application-signals-dashboard.png)
Application Signals との統合を最大限に活用するために、アプリケーションのサービスレベル目標 (SLO) を作成できます。例えば、レイテンシー SLO を作成してアプリケーションがユーザーリクエストに迅速に応答するようにしたり、可用性 SLO を作成して稼働時間を追跡したりできます。SLO は、ユーザーに影響を与える前にパフォーマンスの低下や停止を検出するのに役立ちます。詳細については、「Amazon CloudWatch ユーザーガイド」の「[サービスレベル目標 (SLO)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html)」を参照してください。
# Visual Studio Code での Lambda 関数のリモートデバッグ
[AWS Toolkit for Visual Studio Code](https://aws.amazon.com/visualstudiocode/) のリモートデバッグ機能を使用すると、AWS クラウドで直接実行されている Lambda 関数をデバッグできます。この機能は、ローカルでの再現が難しい問題や、ログだけでは診断が難しい問題の調査に役立ちます。
リモートデバッグでは、以下を実行できます。
+ Lambda 関数コードにブレークポイントを設定する。
+ コード実行のステップスルーをリアルタイムで行う。
+ ランタイム中の変数と状態を検査する。
+ AWS にデプロイされた Lambda 関数をデバッグする (VPC 内にある関数や特定の IAM 許可を持つ関数を含む)。
## ランタイムのサポート
リモートデバッグは、次のランタイムでサポートされています。
+ Python (AL2023)
+ Java
+ JavaScript/Node.js (AL2023)
**注記**
リモートデバッグは、x86\$164 アーキテクチャと arm64 アーキテクチャの両方でサポートされています。
## セキュリティとリモートデバッグ
リモートデバッグは、既存の Lambda セキュリティ境界内で動作します。ユーザーは、関数の環境変数と設定にアクセスする能力を既に保有している `UpdateFunctionConfiguration` 許可を使用して、関数にレイヤーをアタッチできます。リモートデバッグがこれらの既存の許可の範囲を超えることはありません。その代わりに、セキュアなトンネリングと自動セッション管理を通じてセキュリティコントロールを強化します。さらに、リモートデバッグはお客様が完全に制御する機能であり、明示的な許可とアクションが必要です。
+ **IoT セキュアトンネルの作成**: AWSToolkit は IoT セキュアトンネルを作成する必要があります。これは、`iot:OpenTunnel` を使用したユーザーの明示的な許可がある場合にのみ行われます。
+ **デバッグレイヤーのアタッチとトークンの管理**: デバッグプロセスは、以下のコントロールを使用してセキュリティを維持します。
+ デバッグレイヤーは Lambda 関数にアタッチされる必要があります。このプロセスには、`lambda:UpdateFunctionConfiguration` 許可と `lambda:GetLayerVersion` 許可が必要です。
+ セキュリティトークン (`iot:OpenTunnel` 経由で生成) は、各デバッグセッションの前に関数環境変数で更新される必要があります。これには `lambda:UpdateFunctionConfiguration` も必要です。
+ セキュリティのため、このトークンは自動的にローテーションされます。デバッグレイヤーは各デバッグセッションの終了時に自動的に削除され、再利用することはできません。
**注記**
リモートデバッグは、x86\$164 アーキテクチャと arm64 アーキテクチャの両方でサポートされています。
## 前提条件
リモートデバッグを開始する前に、以下を確認してください。
1. AWS アカウントに Lambda 関数がデプロイされている。
1. AWS Toolkit for Visual Studio Code がインストールされている。インストール手順については、「[Setting up the AWS Toolkit for Visual Studio Code](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/setup-toolkit.html)」を参照してください。
1. **3.69.0** 以降の AWS Toolkit バージョンがインストールされている。
1. AWS Toolkit for Visual Studio Code で AWS 認証情報が設定されている。詳細については、「[認証とアクセスコントロール](foundation-iac-local-development.md#lambda-functions-vscode-authentication-and-access-control)」を参照してください。
## Lambda 関数のリモートデバッグ
次の手順を実行して、リモートデバッグセッションを開始します。
1. 左側のサイドバーにある AWS アイコンを選択して、VS Code で AWS Explorer を開きます。
1. Lambda セクションを展開して関数を表示します。
1. デバッグする関数を右クリックします。
1. コンテキストメニューから、**[リモートで呼び出す]** を選択します。
1. 開いた呼び出しウィンドウで、**[デバッグを有効にする]** ボックスにチェックを入れます。
1. **[呼び出す]** をクリックしてリモートデバッグセッションを開始します。
**注記**
Lambda 関数には、関数コードとアタッチされたすべてのレイヤーに対して合計で 250 MB の制限があります。リモートデバッグレイヤーは、関数のサイズに約 40 MB を追加します。
リモートデバッグセッションは、次を行うときに終了します。
+ リモート呼び出し設定画面から **[デバッグセットアップを削除]** を選択。
+ VS Code のデバッグコントロールで切断アイコンを選択。
+ VS Code エディタでハンドラーファイルを選択。
**注記**
デバッグレイヤーは、前回の呼び出しから 60 秒間非アクティブ状態が続くと自動的に削除されます。
## リモートデバッグの無効化
この機能を無効にする方法は 3 つあります。
+ **関数の更新を拒否する**: `lambda:UpdateFunctionConfiguration` を `deny` に設定します。
+ **IoT 許可を制限する**: IoT 関連の許可を拒否します。
+ **デバッグレイヤーをブロックする**: 次の ARN で `lambda:GetLayerVersion` を拒否します。
+ `arn:aws:lambda:*:*:layer:LDKLayerX86:*`
+ `arn:aws:lambda:*:*:layer:LDKLayerArm64:*`
**注記**
この機能を無効にすると、関数設定の更新中にデバッグレイヤーが追加されなくなります。
## 追加情報
VS Code での Lambda の使用に関する詳細については、「[VS Code を使用した Lambda 関数のローカル開発](foundation-iac-local-development.md)」を参照してください。
詳しいトラブルシューティング手順、高度なユースケース、利用可能なリージョンについては、「AWS Toolkit for Visual Studio Code User Guide」の「[Remote debugging Lambda functions](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html)」を参照してください。