Lambdaのログレベル方針について、チームで話して明文化してみた

ERRORログやINFOログなど適切なログを残すことは大切です。そこでLambdaのログレベルについてチームで話し合ってみました。
2020.05.19

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です。

さいごに

私のいるチームでは上記のようになりました。ログに何を求めているか、そしてログレベルはどうするのか、これらはチーム毎に異なると思います(ERRORWARNINGはビジネスに与える影響を考慮するなど)。 改めて話し合ってみると良さそうですね。

参考