logback入門 〜logbackアーキテクチャ
logbackアーキテクチャ
https://logback.qos.ch/manual/architecture_ja.html
基本構成
最終的に全てのロガーがレベルを継承できるように、ルートロガーには必ずレベルが割り当てられている。デフォルトDEBUG。
LoggerContextは、接続してきたロガーを階層的な木構造として保持。
階層はX.Y.Zのように定義。
ルートロガーは、ロガー階層の最上位に存在。複数の階層構造すべてに含まれる。
レベルを定義すると、そのロガーの子よりも下位にレベルが引き継がれる。
ルート X X.Y X.Y.Z
レベルは次の順序。
ロガーのレベルがINFOだと、debugレベルでロギング要求(Logger.debug()呼出し)しても無視される。
TRACE < DEBUG < INFO < WARN < ERROR
一度ロガーのインスタンスを設定すれば、わざわざ参照を渡さなくても、コード中のどこででも同じインスタンスを取得できる。
アペンダーとレイアウト
アペンダーは、ログの送り先。
具体的にはコンソール、ファイル、データベースへのリモート接続(MySQLやPostgreSQLやOracle)、JMS、リモートSyslogデーモン。
リモート接続は性能劣化するので注意。
デフォルトでは、ロガー階層からアペンダーも引き継ぐ。
例えば、ルートロガーにコンソールアペンダー割り当てたなら、有効なロギング要求は少なくともコンソールに出力される。
ロガーのadditivityフラグをfalseに設定すれば、アペンダーを継承しないよう振る舞いを変更できる。
アペンダーとレイアウトを関連付けることで、ロギング要求を整形できる。
性能
メソッドの呼び出しによっては隠れたパラメータ構築のコストが発生。
例えば、ロガーxについて次のように実装されているケース。
x.debug("Entry number: " + i + "is " + entry[i]);
コスト回避するため、SLF4Jのパラメータ化されたロギングを利用すること。
x.debug("Entry number: {} is {}", i, entry[i]);