S3バケットにアップロードされたファイルを処理するLambda関数を設定しようとしています。ファイルをアップロードするときにconsole.log
の出力を確認する方法が必要ですが、Lambda関数をCloudWatchにリンクする方法がわかりません。
ロググループが/aws/lambda/wavToMp3
であり、ログストリームが2016/05/23/[$LATEST]hex_code_redacted
であるcontext
オブジェクトを見ることで考えました。そのため、CloudWatchでそのグループとストリームを作成しましたが、まだ何もログに記録されていません。
ラムダ関数がログストリームを作成し、ログをクラウドウォッチに発行するには、ラムダ実行ロールに次の権限が必要です。
{
"Statement": [
{
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Effect": "Allow",
"Resource": "arn:aws:logs:*:*:*"
}
]
}
詳細については、次のAWSドキュメントを参照してください http://docs.aws.Amazon.com/lambda/latest/dg/intro-permission-model.html#lambda-intro-execution-role
ポリシーを更新した後、すべてのジョブインスタンスを更新して新しいポリシーを読み取るには、関数の設定を更新する必要があるようです。
そのため、IAMでロールポリシーを更新した後、Lambdaコンソールから「テスト」ボタンをクリックするだけで、キャッシュされたLambdaインスタンスには古いロールのアクセス許可が残っているため、Cloudwatchログにログが書き込まれません。
タイムアウトを1秒ずつ変更して[保存してテスト]ボタンをクリックするだけで、Cloudwatchにログが表示されます。
ラムダ関数がログストリームを作成し、ログをクラウドウォッチに発行するには、ラムダ実行ロールに次の権限が必要です
私はすでにこれらの権限を持っていますが、うまくいきませんでした。
タイムアウトを1秒ずつ変更して[保存してテスト]ボタンをクリックするだけで、Cloudwatchにログが表示されます。
タイムアウトを変更して保存しましたが、ログはまだ機能しませんでした。
別の役割を割り当てましたが、ログはまだ機能しませんでした。
最終的には、「カスタムロールの作成」をクリックしてから「許可」をクリックしました。これでログが生成され始めましたが、新しいロールではなく既存のロールを使用したくないので、後で既存のロールを割り当てるだけで機能しました。技術的には、機能しなかった元の構成に戻す必要がありましたが、現在は機能しています。図を移動します。
ロギングが発生するためのもう1つの必要性は、Lambda関数が完了を示す必要があることです。たとえば、Pythonコンテキストでは、ハンドラーはNone
以外の何かを返す必要があります。
ラムダ関数「構成」に「既存のロール」の完全なパスがあることを確認します。
役割:既存の役割を選択します既存の役割:service-role/yourRoleName
何らかの理由で、yourRoleNameのみを入力すると、一部のサービス(SESなど)では機能しますが、CloudWatchでは機能しません。
また、既存のロールを使用する代わりに、新しいロールを作成してみてください。これにより、適切な構成でロールが作成されます(うまくいけば)。
問題は、AWS :: Logs :: LogGroupによってCloudformationスクリプトでロググループを作成しようとしてから、このロググループにLambdaログをプッシュしようとしていたことでした。 :P初心者注意深く読んだ後、Lambdaが前述の形式で独自のログを作成することがわかりました。 logs ::: *
お役に立てれば
既にログに記録されている可能性がありますが、期待するログが見つかりませんでした...
app.use(function simpleLogger (req, res, next) {
console.info('[Logger]', req.method, req.originalUrl)
next()
})
GET /hello?world=1
を実行した後、
ローカルコンソール:(シンプルでわかりやすい、ナイス!)
[Logger] GET /hello?world=1
CloudWatch Logs:(以下で正確なログを簡単に見つけることができますか?)
START RequestId: a3552c34-f7a6-11e8-90ba-2fb886f31fb0 Version: $LATEST
2018-12-04T09:26:11.236Z a3552c34-f7a6-11e8-90ba-2fb886f31fb0 [Logger] GET /hello?world=1
END RequestId: a3552c34-f7a6-11e8-90ba-2fb886f31fb0
REPORT RequestId: a3552c34-f7a6-11e8-90ba-2fb886f31fb0 Duration: 41.02 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 29 MB
結論:元のログを見つけるには冗長すぎる
他の回答が示すように、クラウド監視ログにログを投稿するためのラムダ許可を与える必要があります。 AWSはそのためにAWSLambdaExecute
ポリシーを提供していました。それはjsonです-
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:*"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::*"
}
]
}
ラムダに割り当てられているロールにこのポリシーを追加すると、ログの表示を開始する必要があります。
注:S3読み取り/書き込みアクセスもあります。不要な場合は、ログ部分のみでカスタムポリシーを作成できます。
CloudWatch
とCloudWatch Logs
は異なるアクセス許可です。ロールにアタッチしたポリシーにCloudWatch Logs
を追加する必要があります。
CloudWatchでAWS Lambdaを監視する方法 というセクションがあり、「LambdaでCloudWatch Logsを使用する方法」のセクションがあります。あなたはすでに答えを見つけたように見えますが、IAM固有の問題のない人にとってはこれが役立つかもしれません。
少し遅いかもしれませんが、クラウドウォッチでラムダログを見ることにまだ苦労している人のために。ラムダ関数の実行ロールに関してこれに気付きました:「この関数で既存のロールを使用できます。ロールはLambdaが引き受けることができ、Cloudwatch Logsパーミッションが必要であることに注意してください。」そのため、IAMでは、機能に割り当てられたロールに「CloudWatchLogsFullAccess」を付与しました。その後、cloudwatchのログの下に、このロールが割り当てられた機能のログが表示されます。
この問題に遭遇しましたが、上記の回答のどれも私の問題を解決しませんでした。私がCloudWatchを最初に起動したとき、その地域は何らかの形でオハイオに設定されていたことがわかりました。米国東部(バージニア北部)に変更した後、すべて正常に動作します。