今年もやるよ!AWS Lambda縛り Advent Calendar 2015の10日分です。
背景
AWS Lambdaで開発してるとちょこちょこ実行ログを見たりします。cliであれば、@sgwr_dtsさんのlambchopがtail
的に使えて素敵なんだけど、後で見返したり、検索したりするので、最近ではログをSlackに通知するようにしているのでその紹介を。
イメージはこんな感じ。
ログはCloudWatch logsに溜まるのでsubscriptionさえ出来れば、別にソースはLambdaじゃなくても良いんですけどね。
Lambda
CloudWatch logsのイベントをparseして、日付の色付けやタイムゾーン変換等ちょっこっと加工してメッセージと共に指定の#channel
に飛ばすようにし、別のSlack通知用lambda functionをinvokeしているだけですね。
(Slack用のlambdaは以前のエントリを参照)
何故Slackの部分を別functionにしてるかというと、最小単位の機能の切り出しによるportabilityとcross-account間のinvokeが可能となるreusabilityからです。
紐付け
cloudwatch logsにlambda呼び出しの権限設定
1 2 3 4 |
|
subscription filterの作成
1 2 3 4 |
|
実行
これでlambda functionが実行されると、Slackにログが通知されます。
うん、見やすい。
問題点
これでログが飛ぶようになったのは良いですが、Lambdaが実行されてからSlackへの通知まで10数秒とやや長めの時間がかかってしまうのが現在の難点です。(Immediate Feedbackはないものの履歴や検索用途には十分だけど)
調べてみるとLambdaからCloudWatch logsへの書き出しが一番時間がかかっているのが判明。Logsへ書き出されたら、そこからの処理時間は1〜2秒とちょっと前に発表されたCloudWatch logsのnear realtime processingの通りなので、早くLambda -> CloudWatch logs
も同じような処理時間を実現して欲しいものです。
まあ、別にCloudWatch logsにさえ入れば早いので、lambda logに限らずいろいろ応用できそうですが。
では、Happy Lambda Life!
参考