# 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)」を参照してください。