0

Java でのロギングの構成は、(複数の既存のロギング API が原因で) 難しい場合があり、さまざまなレベル (サーバー、アプリケーション、両方?) で行うことができます。では、これらのレベルでログを構成することの長所と短所は何ですか?

私はこのリストを持ってきましたが、他の人に自分の経験を共有してもらいたいです:

  • サーバーレベル
    • 長所
      • 一元化された構成
      • デプロイ前にアプリケーションを変更してはなりません
      • サーバーによって管理されるリソースにログを記録できます (サーバー パスに関連するファイル、DB...)
    • 短所
      • 各アプリケーションが同じロギング API を使用していることを確認する必要があります
      • より多くのアプリケーションが展開されると、構成が大きくなる可能性があります
      • サーバーは、カテゴリについて知りすぎている可能性があります=>各アプリケーションのログレベルのマッピング
  • アプリケーションレベル
    • 長所
      • アプリケーションは、選択したロギング API を使用できます
      • アプリケーションは独自のログ レベルを構成できます
    • 短所
      • ログファイルへのパス (サーバーからの相対パスの場合) またはログデータベースの JNDI 名を指定するために、デプロイメントの前に構成を編集する必要があります。

プロだけを維持するために2つを組み合わせる方法はありますか? サーバーレベルでロガーを構成してから、アプリケーションレベルでカテゴリ=>ログレベルのマッピングを構成するのが好きですか?

4

1 に答える 1

0

プロだけを維持するために2つを組み合わせる方法はありますか? サーバーレベルでロガーを構成してから、アプリケーションレベルでカテゴリ=>ログレベルのマッピングを構成するのが好きですか?

  • この質問に答えるには、はい、できます。ただし、この場合、サーバーとアプリケーションは適切な設計に従う必要があり、マイナス面として、すべてのアプリケーションが密結合になる可能性があります。


アプリが Java ベースの場合、実際にはすべてのアプリケーションに対して 1 つのロガー ファイルを作成できます。アプリケーションが異なるパッケージ構造に従っている場合は、そこでアプリケーション ロガー レベルを設定する必要があります。


app1 がパッケージ構造 com.app1 に従うとします。. app2 は com.app2 に従います。. 、次に、以下のようにロガーレベルを変更できます。 

*.*.com.app1 = logger_level1
*.*.com.app2 = logger_level2

しかし、app2 が app1 に依存している場合、またはこの com.app1.app2.* のようなパッケージやいくつかの一般的なパッケージ名がある場合は、ロガー プロパティをさらに定義する必要がある可能性があるため、パッケージの構造と設計は非常に重要です。単一のロギング メカニズムに従います。

于 2013-04-23T10:45:10.563 に答える