# 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)