はじめに

こんにちは。NTTデータ先端技術の@tsuchidahrkです。
皆さんはエラーログから原因を切り分けする際、解析に時間がかかり、他の作業が圧迫されて困った経験はありませんか？
私は、AWSサービスを利用したシステムの運用保守業務に携わっており、毎日困っています！
業務でシステムエラーが発生したらBedorockに解析をさせて作業時間を短縮したいと考え、社内で若手メンバーの有志を募り、簡易的なシステムを作り検証してみたいと思います。
本記事では、検証内容やシステム構成について紹介します。

検証内容

業務では、以下のフローでシステムからエラーログの通知を受け取っています。

アプリケーションが出力したログをCloudWatch Logsに送信
メトリクスフィルターでエラーログを検出
CloudWatch Alarmが発報
発報をトリガーにSNSでエラーログをメール通知

今回の検証では、上記3の処理後、イベント通知でLambda関数を起動し、Bedrockにエラーログを解析させ、解析結果をSNSによるメール通知で受け取るフローを試してみます。
フローとしては以下になります。

アプリケーションが出力したログをCloudWatch Logsに送信
メトリクスフィルターでエラーログを検出
CloudWatch Alarmが発報
発報をトリガーにLambda関数を起動
Lambda関数によりBedrockでエラーログを解析
Lambda関数により解析結果をSNSでメール通知

メトリクスフィルターでのエラーログの検出をトリガーにLambdaが起動し、Bedrockにエラーログを解析させ、原文と解析結果をSNSを用いてメール通知と飛ばします。

システム構成＆説明

EC2：稼働しているアプリケーションが動作している想定。こちらからエラーログを出力。
CloudWatch Logs & Alarm : アプリケーションからのエラーログ出力を検知し、アラートを発報する。
EventBridge：CloudWatch AlarmのアラートをトリガーにLambdaを起動させる。
Lambda&Bedrock：エラーログをCloudWatch Logsから読み取り、これを入力文としてBedrockを実行する。分析した結果をSNSに出力する。
SNS：Lambdaが出力したログをメールで通知する。

今後に向けて

今回の記事では、業務で課題に感じていたシステムエラーの解析をBedrockで効率化出来ないか考え、今後実施する検証内容や検証を行うシステムの構成について紹介してみました。
次回の記事では、実装内容について紹介したいと思います。