この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
Amazon AppFlow フローの実行が CloudWatch メトリクスに記録されるようになりました。
これまで Amazon AppFlow に対応した CloudWatch メトリクスはなかったんですね。
どんなメトリクスが追加されたのか
メトリクスの一覧は以下ページに記載されています。
名前空間はAWS/AppFlowで、ディメンションはFlowNameです。
| メトリクス | 説明 |
|---|---|
FlowExecutionsStarted |
開始されたフロー実行の数 |
FlowExecutionsFailed |
失敗したフロー実行の数 |
FlowExecutionsSucceeded |
成功したフロー実行の数 |
FlowExecutionTime |
フローが開始してから終了するまでのミリ秒単位の間隔 |
FlowExecutionRecordsProcessed |
フロー実行のために Amazon AppFlow が転送を試みたレコードの数 |
AppFlow ではデータ転送を行う送信元と送信先を定義したフローを作成し、それを実行することで転送が行われます。フローの実行は手動でのオンデマンド実行のほか、スケジュール実行、Event Bridge による定期実行が行えます。
今回サポートされた各種メトリクスは、特にオンデマンド実行以外のケースでその成否をモニタリングするのに役立ちそうです。
やってみた
以前作成した AppFlow フローを実行し、メトリクスにどう記録されるかを確認します。
送信元を Slack、送信先を S3 とするslack-to-s3という名称のフローです。オンデマンドで複数回実行します。
↑気の利いたことにCloudWatch メトリクスの画面に遷移する動線が用意されていますね。
まずは 3 回実行しどれも成功します。
送信先の S3 バケットのバケットポリシーを削除したのちフローを実行し、エラーを発生させます。
slack-to-s3 からエラーを受け取りました
Amazon AppFlow received the following error: The request failed because the service Destination S3 returned the following error: Details: Failed to get AmazonS3 Bucket Acl with message: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: 8B3SZ5BZC4WNP0AF; S3 Extended Request ID: Y6KZFGwyC45HpMYad5u7GpWDQRPo3TIkFAyGaiN23+3cLAl3UtWhk2Xptq8fbvNGD9sdRWkcJ4k=; Proxy: null), StatusCode: 403, ErrorCode: AccessDenied. If you want to know more details about this error. Contact S3 with {S3RequestId=8B3SZ5BZC4WNP0AF}.
メトリクスの画面を確認すると成功およびエラーのカウントがきちんと記録されていました。
フローの実行時間（ミリ秒）のメトリクスはこんな感じ。エラーが発生した場合も実行時間は記録されていますね。
最後に、処理されたレコード数のメトリクスです。こちらもエラーになった実行のものも記録されています。先に送信元で処理するレコードを集計した上で、送信先に対してアクセス可能な状態か確認する、という流れが想像されます。
AppFlow フロー実行に関するメトリクスが確認できました。
終わりに
Amazon AppFlow のフロー実行について CloudWatch メトリクスがサポートされた、というアップデートでした。
オンデマンド実行の場合はその場で成否や所要時間、レコード数が確認できますが、定期実行の場合はそうもいきません。これまでは実行リクエストの戻り値などから判断していたかと思いますが、CloudWatch メトリクスでサポートされたことによってより簡易的にモニタリングが実現できそうです。
以上、 チバユキ (@batchicchi) がお送りしました。
21
