5

log4jまたは同様のライブラリのログカテゴリにどのような規則を使用しますか？通常、クラス名はカテゴリとして表示されますが、他のシステムを使用したことがありますか？

ログレベルはどうですか？どのレベルを使用しますか？その場合は？

更新：あなたの何人かが答えたように、「正しい」答えはありません。インスピレーションの源として人々が使用するさまざまな慣習を探しています。

4

5 に答える 5

1

私には3つのレベルがあります。エラー、警告、およびプログラムが一度に実行していることを示す詳細なログです。

クラス+関数をコンテキストとして使用します。

于 2008-10-02T16:47:10.070 に答える
1

Vaibhav の回答に同意します。ログを記録している理由を知る必要があります。

  • 内部の技術的なデバッグ情報をデバッグする場合は、log4j またはその他のライブラリで問題ありません (それらの使用によって関数のサイクロマティックな複雑さが人為的に増加しない場合)。
  • 横断的な時間厳守ロギング (コード全体) の場合、アスペクト指向のアプローチの方が適しています。
  • 監視の場合は、まったく別のレベルのロギング、つまりKPIに入ります。これらの情報は、パブリケーション バス (たとえば TIBCO など) を介してある種のデータベースに記録する必要があります。

したがって、内部ログのみについては、かなり標準的なアプローチに従います。

  • プログラムを危険にさらす可能性のあるエラーに対して重大
  • 内部進行をフォローするための情報
  • いくつかのサブステップの詳細については問題ありません

粒度 (従来の内部ロギングの場合) はメイン クラスであり、プロセスの主要なステップを担当します。

于 2008-10-02T17:17:18.347 に答える
0

私たちはこれについて何年にもわたって広範な議論を重ねてきましたが、私たち全員が同意する唯一のことは、完璧な答えはないということです！

私たちが決めたのは、トップレベルのカテゴリ名を使用して幅広いカテゴリを区別することです。たとえば、「操作」はユーザーが気にする可能性のあるものすべてに関連し、「内部」は開発者だけが気にするものに関連します。「監査」は次の目的で使用されます。興味深いイベントの追跡。

それを超えて、カテゴリの数を制限しようとしています。これは、より詳細なレベルでカテゴリをオン/オフにする人がいないためです。したがって、クラス名の代わりに、それらを機能領域にグループ化しようとします。クエリ、更新など。

于 2008-10-02T16:55:21.377 に答える
0

ロギングは要件によって異なります。問題（ログの例外など）が発生したかどうかを確認するだけのログを作成する場合は、クラス名と関数名のみが必要になる場合があります。

ただし、ある種の証跡を作成および監査するための機能要件がある場合は、ロギングをまったく異なるレベルの詳細にする必要があります。

于 2008-10-02T16:56:53.043 に答える
0

クラス + メソッドのデバッグ ログがあります。

また、特定のアクション (ソケットで受信した接続など) の特定のログもあります。これらは、私が「ファクト ログ」または「監査証跡ログ」と呼んでいるもので、単一の種類のものを記録します。もちろん、最近はこれらをデータベースに貼り付けています。取得している事実は、テキストの文字列よりもはるかに複雑になる可能性があり、特定の時点での状態が含まれる可能性があるためです。つまり、必要な監査ごとに独自の監査証跡記録メカニズムを作成します。

デバッグするとき、デバッグしているパッケージ/クラスを log4j で DEBUG に設定し、ルートロガーを ERROR のままにします。アプリケーションの他の領域からのすべての gumpf ロギングを除外するデバッグ ログ ファイルを作成します。

しかし、これらのことを行うための「正しい方法」は実際にはありません。メカニズムの組み合わせは良いように思えますが、何をログに記録するかによって異なります。

于 2008-10-02T17:14:24.217 に答える