darjeeling-tea's blog

オープンな個人ノートです。

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

一度ロガーのインスタンスを設定すれば、わざわざ参照を渡さなくても、コード中のどこででも同じインスタンスを取得できる。

アペンダーとレイアウト

アペンダーは、ログの送り先。
具体的にはコンソール、ファイル、データベースへのリモート接続(MySQLPostgreSQLOracle)、JMS、リモートSyslogデーモン。
リモート接続は性能劣化するので注意。

デフォルトでは、ロガー階層からアペンダーも引き継ぐ。
例えば、ルートロガーにコンソールアペンダー割り当てたなら、有効なロギング要求は少なくともコンソールに出力される。

ロガーのadditivityフラグをfalseに設定すれば、アペンダーを継承しないよう振る舞いを変更できる。

アペンダーとレイアウトを関連付けることで、ロギング要求を整形できる。

性能

メソッドの呼び出しによっては隠れたパラメータ構築のコストが発生。
例えば、ロガーxについて次のように実装されているケース。

  x.debug("Entry number: " + i + "is " + entry[i]);

コスト回避するため、SLF4Jのパラメータ化されたロギングを利用すること。

  x.debug("Entry number: {} is {}", i, entry[i]);