ログのセマンティクスマッピング

mapping.md

ログライブラリ移行に伴うセマンティクスのマッピングについて

• 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 で提供

--enable-debug をつけない場合は、TRACE(現在不使用), DEBUG はコンパイル段階で除去

debugログの位置づけにもよりますが、システム運用中に debug にすることは、ないと思いますので、まずは 現行にならえ で良いと思います。商用環境の再現確認を 開発環境とかで再現確認することはあるが、その場合は debug 版 であれば良い)

@rimms ありがとうございます

---

デフォルトのロガー設定ファイル置場について、追記

5/26 の MTG でお話したのですが、以下の変更も入ります。

---

• ログファイル名に pid が入らなくなる。

影響は下記のとおりです。

• ファイル出力を選択し、同一OS内で複数プロセスを起動する場合には、ログの設定ファイルを分ける必要がある。

デフォルトの設定ファイルは標準出力にしておき、別途、ログファイルの設定に関するドキュメント(リンク)を用意しておく方法で良いと考えている。デフォルトをファイル出力にしておくと、以下の影響がある。

• 分散チュートリアルの修正。(書くこと/説明することが増えそう)
• server, proxy, command ごとにデフォルトの設定ファイルを用意する必要がある。

@rimms マルチテナントが無い現状では、複数のプロセスが同一 OS 上で稼働するユースケースは十分想定可能と考えます。以下のように環境変数を経由することで PID の出力が可能なようなので (あんまり綺麗じゃないですが...)、デフォルトで PID が出力される (現状維持) のが好ましいのではないかと思います。

kmaehashi/rimms-misc@df9ca6d

デフォルトのロガー設定の考え方についてアップデートしました。

特にlog4cxx向けのツッコミはありませんが、
例外発生時のFATAL出力は仰々しいので、例外が不要な箇所はログのFATALを使わずstderrへ出力するのはどうでしょうか。
いまはエラー処理 = 例外として実行している場所がいくつかあると思います。ログライブラリとあわせてエラー表示（エラーとして例外を扱うときのポリシーみたいなもの）も整理できるとよいのですが。