- glog のセマンティクス (現行)
- DEBUG / non-DEBUG ログの 2 系統がある (DLOG() / LOG())
- それぞれの系統ごとに、ログレベルが 4 種類定義されている (INFO, WARN, ERROR, FATAL)
--enable-debug
付きでコンパイルしない限り、DLOG はコンパイル段階で除去される
- log4cxx のセマンティクス
- ログレベルのみ、6 種類定義されている (TRACE, DEBUG, INFO, WARN, ERROR, FATAL)
- マッピングの考え方
- LOG(*) は、それぞれ同等ログレベルに移行。
- DLOG(*) は、一律 DEBUG に移行。
--enable-debug
をつけない場合は、TRACE(現在不使用), DEBUG はコンパイル段階で除去
- その他
- log4cxx では FATAL 出力時に自動停止しない
- 現行版で LOG(FATAL) を利用している個所は abort(); などの追記が必要
- スタックトレースを出す機能が使えなくなる
- ソースファイル名、行番号が同時に出るため、Jubatus の規模感であれば、スタックトレースに依存した解析の必要性は薄いと考える
- jubatus_core の glog を利用したアサーション機構を移植する必要あり
- assert() に置き換えれば要は足す? (教えてください > 斎藤さん)
- ロガー設定の与え方
- 設定ファイルを指定しない場合、コンソール出力で動作 (現状維持)
--log_config
コマンドラインオプションを新規追加し、log4cxx 設定ファイルを渡せるようにする- サンプル設定ファイルを $PREFIX/share/jubatus/example/logging/log4cxx.xml で提供
- log4cxx では FATAL 出力時に自動停止しない
Last active
August 29, 2015 14:01
-
-
Save kmaehashi/e17222f721b49f7a62ba to your computer and use it in GitHub Desktop.
ログのセマンティクスマッピング
特にlog4cxx向けのツッコミはありませんが、
例外発生時のFATAL出力は仰々しいので、例外が不要な箇所はログのFATALを使わずstderrへ出力するのはどうでしょうか。
いまはエラー処理 = 例外として実行している場所がいくつかあると思います。ログライブラリとあわせてエラー表示(エラーとして例外を扱うときのポリシーみたいなもの)も整理できるとよいのですが。
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
デフォルトのロガー設定の考え方についてアップデートしました。