- 今回ご説明する内容
- 結論
- 検証環境
- EventBridgeスケジューラの呼び出しイベントはCloudTrailログ上でどのように記録されるのか。
- 確認方法1_CloudTrailイベント履歴から確認する
- 確認方法2_Athenaから確認する
- 確認方法3_CloudWatch Logsから確認する
- 補足_実行スケジューラを特定するには?
- 感想
最近「半沢直樹」を見返している技術4課の前田(青)です。
2013年に放送されていた当時、私はまだ高校生だったなあ…と時代の流れを感じています。
今回ご説明する内容
EventBridgeスケジューラは例えば「毎日0時にLambdaを実行してバッチ処理したい」のように、定期的に別のAPIを呼び出して何らかの処理をさせたい場合に便利なサービスです。
EventBridgeスケジューラを使用していると「定期的な呼び出しが上手く実行できているか」「エラーが発生しているとしたら何が原因なのか」などを知りたい時があります。
今回は、そんな時のための確認方法をお伝えしていきたいと思います!
結論
- CloudTrailログの要素「userAgent」に「AmazonEventBridgeScheduler」が含まれるイベントを探す。
- 下記3つの確認方法が有る。
- CloudTrailイベント履歴から確認
- Athenaから確認
- CloudWatch Logsから確認
- 呼び出しているスケジューラを特定するには、他のスケジューラと重複しないIAMロールをアタッチすることが必要。
検証環境
今回は下図のように、定期的にGlueのAPI「StartWorkflowRun」を呼び出すEventBridgeスケジューラの実行ログを取得していきたいと思います。
EventBridgeスケジューラの呼び出しイベントはCloudTrailログ上でどのように記録されるのか。
いきなりですが、実際にEventBridgeスケジューラから呼び出されるログはCloudTrailにおいて下記のように記録されます。
重要なのは30行目の「userAgent」要素で、EventBridgeスケジューラから呼び出されると「AmazonEventBridgeScheduler」の文字列が含まれるため、この要素の確認方法を工夫すればよいという話になります。
{ "Records": [ { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA4BIFDEYZQWO7W6ISG:19bdad09bdcb34aeb0e3685c9c38bf23", "arn": "arn:aws:sts::111111111111:assumed-role/role-from-eventbridge-to-glue/19bdad09bdcb34aeb0e3685c9c38bf23", "accountId": "111111111111", "accessKeyId": "ASIA4BIFDEYZ3OSSHRFO", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA4BIFDEYZQWO7W6ISG", "arn": "arn:aws:iam::111111111111:role/role-from-eventbridge-to-glue", "accountId": "111111111111", "userName": "role-from-eventbridge-to-glue" }, "attributes": { "creationDate": "2023-08-25T10:29:31Z", "mfaAuthenticated": "false" } } }, "eventTime": "2023-08-25T10:29:31Z", "eventSource": "glue.amazonaws.com", "eventName": "StartWorkflowRun", "awsRegion": "ap-northeast-1", "sourceIPAddress": "18.176.22.181", "userAgent": "AmazonEventBridgeScheduler, aws-sdk-java/2.20.126 Linux/5.10.184-175.749.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/11.0.20+8-LTS Java/11.0.20 kotlin/1.6.21-release-334(1.6.21) vendor/Amazon.com_Inc. md/internal exec-env/AWS_ECS_FARGATE io/async http/NettyNio cfg/retry-mode/legacy", "errorCode": "EntityNotFoundException", "errorMessage": "Entity not found", "requestParameters": { "name": "MyData" }, "responseElements": null, "requestID": "ed64e882-6c8b-4f6d-aba2-7bcdba1c5c92", "eventID": "62017fdd-3085-4c3b-94f1-1c8ff79cc834", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111111111111", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "glue.ap-northeast-1.amazonaws.com" } } ] }
確認方法1_CloudTrailイベント履歴から確認する
CloudTrailイベント履歴から確認する際は、「userAgent」要素で検索することは出来ないため、イベント名や実行時間で絞り込む必要があります。
コンソール上に全てのCloudTrail要素は表示されませんが、ダウンロードできるCSV・JSONファイルには全ての要素が記載されています。
確認方法2_Athenaから確認する
CloudTrailログをAthenaから確認します。
1.CloudTrailログのテーブルを作成
CloudTrailログのテーブルをAthenaに作成し、SQLを実行して確認します。
CloudTrailログをAthenaで確認する方法については弊社の山﨑のブログをご覧ください。(今回使用したCloudTrailログテーブルも、下記ブログのCREATE文を使用して作成しました。)
blog.serverworks.co.jp
2.SQLを実行して確認する。
確認のためのSQLは下記になります。
SELECT eventtime, eventname, errorcode, errormessage FROM "default"."cloudtrail_logs_pp" where "useragent" like 'AmazonEventBridgeScheduler%' --左記のように指定することで、EventBridgeスケジューラから呼び出されているログを取得できます。 and eventname = 'StartWorkflowRun' and eventtime like '2023-08-25T10:%:%'--左記のように指定すると、日本時間で8月25日19時台に呼び出されたログを取得します。 and timestamp = '2023/08/25' --今回の例で作成したテーブルはパーティション化しているため、クエリ実行速度を速めるために指定しています。 order by eventtime desc
実行結果は下記のようになります。呼び出し結果でエラーが発生している場合、列「errorcode」「errormessage」から確認できます。
確認方法3_CloudWatch Logsから確認する
EventBridgeスケジューラの呼び出しイベントが記録されたCloudTrailログを下記画像のようにCloudWatch Logsから確認します。
実現するには、「EventBridgeスケジューラが特定のAPIをコールを呼び出す」イベントで、CloudTrail経由で送信されるイベントをCloudWatch Logsへ転送するよう、EventBrigeルールを作成する必要があります。
1.EventBridgeルールを作成
①Amazon EventBridgeトップ画面の左メニューにおいて、「ルール」リンクを押下します。
②「ルールを作成」ボタンを押下します。
③「ルールの詳細を定義」画面において下記項目に下記の値を入力・選択し、「次へ」ボタンを押下します。
- 名前…任意の文字列
- ルールタイプ…イベントパターンを持つルール
④「イベントパターンを構築」画面において下記項目に下記の値を入力・選択肢、「次へ」ボタンを押下します。
- イベントソース…その他
- メソッド…カスタムパターン(JSONエディタ)
- イベントパターン…下記JSONを記載する(EventBridgeスケジューラがGlue API「StartWorkflowRun」を呼び出したイベントで、CloudTrial経由で送信されるイベントを取得します。)
{ "source": ["aws.glue"], "detail-type": ["AWS API Call via CloudTrail"], "detail": { "eventName": ["StartWorkflowRun"], "userAgent": [{ "prefix": "AmazonEventBridgeScheduler" }] } }
⑤「ターゲットを選択」画面において下記項目に下記の値を入力・選択して「次へ」ボタンを押下します。
- ターゲットタイプ…AWSのサービス
- ターゲットを選択…CloudWatchロググループ
- ロググループ…ロググループ名となる、任意の値を入力
⑥「タグを設定」画面において、付与したいタグのキー、値があれば設定し、「次へ」ボタンを押下します。
⑦「レビューと作成」画面において設定値に問題がなければ「ルールの作成」ボタンを押下し、作成されたらOKです。
2.CloudWatch Logsのロググループから確認する。
EventBridgeスケジューラの実行後、「1.EventBridgeルールを作成」の⑤で作成したCloudWatch Logsロググループを見てみましょう。すると、下記画像のようにログストリームが記録されているはずです。
ログストリームのリンクを押下してみると…EventBridgeスケジューラがGlue API「StartWorkflowRun」を呼び出した時のCloudTrailログが記載されています!
補足_実行スケジューラを特定するには?
例えばスケジューラAとスケジューラBが同時刻に定期実行されているとして、どちらのスケジューラが実行したのかCloudTrailログから特定することは出来るのでしょうか?
結論を言うと、スケジューラそれぞれに一意のIAMロールをアタッチして要素「userIdentity」下の「arn」や「username」の差別化を図ることでしか特定できません。
CloudTrailログにはEventBridgeスケジューラのスケジューラ名やARNが含まれず、唯一差別化できる要素がIAMロールになるためです。
感想
確認方法が色々とあったためまとめてみました。どなたかの一助になれば幸いです。