Lambdaのログレベル方針について、チームで話して明文化してみた
ERRORログやINFOログなど適切なログを残すことは大切です。そこでLambdaのログレベルについてチームで話し合ってみました。
Lambdaを実装しているとき、ふと「ログのレベルって決めてたっけ？」となりました。 個人の基準はあってもチームとしては曖昧だったので（開発者のさじ加減）、チームで話し合って明文化してみました。
前提
- 対象はLambdaのログです
ERRORレベルのログがあるとき、Slackに通知する仕組みがあります- この通知を元に開発者が確認を行い、必要に応じて対処します
- AWSの環境は3つです
- development
- staging
- production
ログを残す理由
- Lambdaの処理で何かあったことを認識するため
- 何らかの対応（暫定・恒久）を行うとき、参考情報とするため
CloudWatch AlarmでLambdaのエラー監視をすればLambdaの実行が失敗したことは分かりますが、適切なログが無ければ、「何をしようとして失敗したのか？」「その時のパラメータは何か？」などが分かりません。
また、不具合の暫定対応や恒久対応を行うにしても、適切なログが無ければ「そもそも何をすれば良いの？」「効果検証はどうするの？」となってしまいます。
ログレベルのポリシーを決めた
| レベル | 概要 |
|---|---|
| ERROR | Slack通知したい情報（対処が必要な事象が起きた） |
| WARNING | Slack通知しないが、残したい情報（対処は不要だけど気にしておきたい） |
| INFO | 開発者がLambdaの処理を追うのに必要な情報（対処する際の参考情報） |
| DEBUG | 開発時にあると嬉しい情報 |
ERROR
- Slack通知したい情報（対処が必要な事象が起きた）
具体的には下記です。
- Lambdaが落ちた
- デプロイパッケージに必要なライブラリが無かった
- コードをtypoしてた
- など
- DynamoDBからデータ取得しようとしたけど失敗し、処理続行できなかった
- 想定外のデータがあり処理続行できなかった
- など
ただし、API Gatewayの裏側にいるLambdaの場合、API利用者から見て400系の場合は意図的にエラーログを出さないようにします（クライアント要因のエラーをSlackに通知しても、開発者がやることは無いため）。
- 400：API Request Bodyの値が想定外である
- 404：存在しないIDに対するReadアクセス
- など
WARNING
- ノイズになるのでSlack通知しないが、残したい情報（対処は不要だけど気にしておきたい）
- エラーが発生したが、期待通りの動作が行われた
具体的には下記です。
- DynamoDBからデータ取得に失敗したが、リトライ処理では成功した
- 必須データが無いけど、デフォルト値を使って処理を続行した
- など
INFO
- 開発者がLambdaの処理を追うのに必要な情報（対処する際の参考情報）
具体的には下記です。
- Lambdaの入口(event, 環境変数)
- Lambdaの出口(処理の結果)
- Lambda以外に関するアクセスやデータ(DynamoDB・S3・IoTなど)
- Requestの内容
- Responseの内容
DEBUG
- 開発時にあると嬉しい情報
具体的には下記です。DEBUGレベルのログは、development環境のみで出力させます。
- 関数の出入り
- 特定変数の内容
- など
頭の隅に置いておくこと
ログが多すぎると料金が高くなる
なんでもかんでもログ出力すると、CloudWatch Logsの料金が地味に高くなります。
CloudWatch Logsは、ログの取込料金が0.76USD/GBです。
もし、「とりあえずログに残しとくか」というログが1日1GBあるなら、30日で約23USDです。
さいごに
私のいるチームでは上記のようになりました。ログに何を求めているか、そしてログレベルはどうするのか、これらはチーム毎に異なると思います（ERRORとWARNINGはビジネスに与える影響を考慮するなど）。
改めて話し合ってみると良さそうですね。
