未分類

ログ出力レベル使い分け

ログの出力レベルにはEmergencyやAlertなど色々ありますが「どう使い分ければいいのか?」わからない方も多いのではないでしょうか。
今回はsyslogの8段階を元に、実際の業務でどう使い分けているかについてです。

syslogのログレベルについてはRFC5424(RFC3164)にて定義されています。
いますが、

           0       Emergency: system is unusable システムが使えない
           1       Alert: action must be taken immediately ただちに行動をとる必要がある
           2       Critical: critical conditions 重大な状態
           3       Error: error conditions エラー状態
           4       Warning: warning conditions 警告状態
           5       Notice: normal but significant condition 正常だけど重要な状態
           6       Informational: informational messages 情報メッセージ
           7       Debug: debug-level messages デバッグメッセージ

と、説明になっているようでなっていないものがいくつかあります。
では実際具体的にどういう基準で設定すればいいのかというところですが、下記に実際に業務で設定している基準を記載しました。

Emergency深夜でも担当者を叩き起こすアプリケーションでは設定しない(サーバーが動いていないなどシステム用)
Alert深夜でも担当者を叩き起こすサーバーが落ちた、DBがつながらない、決済システムのエラーなど
Critical一度でも出力があれば業務時間内最優先対応、残業とかもする一部のサブ機能が使えないなどある程度影響範囲の大きいエラー あまり使わない
ErrorSlackなどに通知を設定するラインで、頻度が高いようならそれに応じて対応優先度を上げる緊急度の低い通常のエラー
Warning余裕あれば直す廃止予定のメソッドやパラメータが使われているなど、今問題はないが望ましくはないもの
Notice特に対応不要あまり使わない
Informationalプログラムの修正を目的としない情報 関係者以外は気にする必要無し実行されるタイミングや頻度を確認したり不具合の有無に関わらず情報出力したいときなど
Debug一時的に仕込んだもの 関係者(主に設定した本人)以外は気にする必要無し原因が特定できない不具合のデバッグのために色々なところにログ出力をしこむときなど

元は前述のRFCのものなので解釈は人により色々ありますが、
「そのレベルのログが出ていたらどう対応するか」は統一しましょう。
そうでなければ「最近Alert多いなー、どうせいつものだろう」と警告に慣れてしまい重大なものを見逃すことになります。
もし出ても緊急度の低いAlertログなのであれば出力するログのレベルをErrorに下げるなど、各ログレベルに対する対応は統一しましょう。

-未分類