私の組織では、あなたが追加したりコメントしたりできるかどうか知りたい、ロギングに関するいくつかのルール/ガイドラインをまとめました。
Javaを使用しますが、ログインについて一般的にコメントできます-ルールとアドバイス
正しいログレベルを使用する
何をログに記録しているかを確認してください。
ロギングがアプリケーションの動作に影響することを回避する
ロギングの機能は、ログにメッセージを書き込むことです。
トラブルシューティングの際に、意味のないメッセージを使用することはあまりありません。
適切なメソッドとクラスが自動的に作成されることを確認してください。
例:
Datedfile -web
_log4j.rootLogger=ERROR, DATEDFILE
log4j.logger.org.springframework=INFO
log4j.logger.waffle=ERROR
log4j.logger.se.prv=INFO
log4j.logger.se.prv.common.mvc=INFO
log4j.logger.se.prv.omklassning=DEBUG
log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender
log4j.appender.DATEDFILE.layout=org.Apache.log4j.PatternLayout
log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n
log4j.appender.DATEDFILE.Prefix=omklassning.
log4j.appender.DATEDFILE.Suffix=.log
log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/
_
アプリケーションから値を記録してください。
アプリケーションのどの部分からロギングが書き込まれたかを示します。できれば、プロジェクトで合意された接頭辞を使用してください。 _Pandora_DB
_
ロギングテキストが多すぎないように注意してください。アプリのパフォーマンスに影響を与える可能性があります。
-log4jで使用するいくつかのバリアントとメソッドがありますが、例外でログを記録するときは、次の形式を統一して使用したいと考えています。
logger.error("Pandora_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", e);
上記の例では、クラスとメソッドを自動的に書き込むようにlog4jプロパティを設定していると想定しています。
次のものではなく、常にロガーを使用します。
System.out.println(), System.err.println(), e.printStackTrace()
Webアプリがフレームワークを使用している場合、ハンドラーでtry-catchを使用し、上記のモデルに従ってロギングすると、EJBから非常に詳細なエラー情報を取得できます。
プロジェクトでは、この変換パターンを使用して、メソッドとクラスの名前が自動的に書き出されます。ここでは、コンソールとdatedfileappenderに2つの異なる特許を使用しています。
_log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
log4j.appender.DATEDFILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
_
上記の例の両方で、メソッドとクラスは書き出されます。コンソールには行番号も書かれています。
toString()
すべてのオブジェクトに対してtoString()
を用意してください。例:
_@Override
public String toString() {
StringBuilder sb = new StringBuilder();
sb.append(" DwfInformation [ ");
sb.append("cc: ").append(cc);
sb.append("pn: ").append(pn);
sb.append("kc: ").append(kc);
sb.append("numberOfPages: ").append(numberOfPages);
sb.append("publicationDate: ").append(publicationDate);
sb.append("version: ").append(version);
sb.append(" ]");
return sb.toString();
}
_
これらの出力を行う特別なメソッドの代わりに
_public void printAll()
{
logger.info("inbet: " + getInbetInput());
logger.info("betdat: " + betdat);
logger.info("betid: " + betid);
logger.info("send: " + send);
logger.info("appr: " + appr);
logger.info("rereg: " + rereg);
logger.info("NY: " + ny);
logger.info("CNT: " + cnt);
}
_
ロギングを使用するこれらの方法で、追加、コメント、または疑わしいと思われることはありますか? Javaに関連していなくても、お気軽に回答またはコメントしてください。Javaであり、log4jは、これが推論される方法の単なる実装です。
アプリケーション内のログステートメントがどこから来たかを記録するルールの拡張として、モジュールレベルのログフラグを追加することができます。これにより、常にすべてをログに記録する代わりに、アプリケーションのセクションを選択してターゲットにすることができます。これにはオーバーヘッドがあり、ロギングを有効/無効にできる機能を作成する必要があります。理想的には、アプリケーションの実行中にオンザフライで有効/無効にすることができます。
私は「トレース」と呼ぶデバッグの下のレイヤーを見るのに慣れていますが、それは必ずしも普遍的な用語ではありません。 「トレース」レベルのロギングは、モジュールの入り口/出口、入り口/出口のあるタイムスタンプ、渡された値を取得するためのボーナスポイントなど、可能な限り追跡します。明らかに、それは大量のデータを生成し、それはあなたがすぐに有効にするものではありません。ただし、プロセスにアタッチできない場合、またはエラーのあるアプリケーションのコアダンプがない場合は、デバッグに関して有利です。
ログ情報とともにファイル/モジュール参照とタイムスタンプを確認したい。これは、スレッド間の競合状態を突き止めたり、アプリケーションの複数の領域のアクティビティを調整したりするときに便利です。公平を期すために、これらの詳細がログファイルを散らかしていると考える一部の人々を知っています。タイムスタンプを追加することは、チームと話し合うためのものです。 (log4jがすでにそれを行っている場合はお詫びします。)
ロギングがそれ自体のスレッド/プロセスによって処理されていない場合は、それも考慮する必要があります。ロギングの処理をアプリケーションスレッドに待機させる代わりに、ログメッセージがログハンドラーに渡され、アプリケーションスレッドは陽気に進みます。あるいは、ログメッセージを処理するための何らかのバッファメカニズムを作成することは、アプリケーションの応答性を高速化するもう1つの方法です。
ログファイルのサイズと履歴を制御することは、考慮すべきもう1つの機能です。アプリがホストシステムのすべてのディスク領域を使い果たしてほしくないし、すべてのログファイルを永遠に保持する必要もありません。
覚えておくべきことの1つは、ログの文字列操作を行う前に、ログレベルを確認することです。つまり、実際にログを記録する予定がない場合は、日付フォーマッターを設定したり、一連の文字列を連結してログメッセージを作成したりする作業のすべてに取り掛からないでください。これは、アプリケーションの速度を低下させる無駄な作業です。
ちなみに、Apache CommonsプロジェクトにはToStringBuilder
class があり、toString()
メソッドの作成を簡素化しています。
ここでニックを追加したところ、疑わしいものは何も見つかりません。これは私がしばらくそれをしている方法です。あなたが提供した投稿は非常に詳細であり、おそらくロギングの一種のチュートリアルとして使用できます。ただし、ここで1つ追加したいと思います。つまり、多くの場所で、条件付きロギングを使用した問題が発生しています。 :
if(env_local)
{
write_to_local();
}
else if(env_IT)
{
write_to_IT();
}
else if(env_PROD)
{
write_to_prod();
}
else
dosomething();
この種の条件付きトレースやデバッグは、最善の方法ではないと思います。
エラーを発生させたクラス/メソッドをログに記録することに加えて、そのメソッドに渡されたパラメーターをログに記録すると便利です。エラーが発生した場所を知ることは、エラーが1000回に1回しか発生しない場合、あまり役に立ちません。また、エラーの原因となったデータを知る必要があります。
また、アプリケーションのロギングのデフォルトレベルを定義する変数があると便利です。これにより、WARNINGおよびERRORコードとともにDEBUGおよびINFOコードを使用できます。本番モードで実行する場合、デフォルトではDEBUG情報を出力しないようになっていますが、バグが表示された場合は、フラグを更新して、DEBUGメッセージをログに書き込むこともできます。
ロギングは、ほとんどの場合、横断的な関心事です。 Javaだけでは、実際のビジネスロジックからロギングを分離するのに十分な表現力がありません。これは、たとえば、1つのメソッドを使用してそれを別のプロジェクトに入れることはできませんが、行う前にすべてのログを削除して調整します。これは氷山の一角にすぎません。
ロギングと「実際の」ビジネスロジックを混ぜ合わせるときに、この問題やその他の問題を防ぐには、アスペクト指向プログラミングの使用を検討する必要があります。 Javaの場合、最も使用されるフレームワークはAspectJです。 Google techトークからのこのyoutubeビデオがあります これは、AspectJとその使用法をかなりログに記録する以外にも説明しています。もちろん、自分でログを記録する例 ここではstackexchangeでも 。
私が提案することの1つは、特定のログファイルに関連付けられた複数のログコンテキストを保持する手段があり、任意のログコンテキストに書き込まれたものがログに記録されるように調整することですnlessコードが明示的にログに要求するその内容を破棄するコンテキスト。このような設計により、操作中にかなり詳細なログをキャプチャし、操作が成功した場合はログを破棄できますが、操作が失敗した場合は利用できるようになります。そのようなロギング機能がない場合、何かが失敗したときに適切なログを利用できるようにするには、すべてが機能するときに、アプリケーションが99.99%の時間で無駄なデータのロギングに多くの時間を浪費する必要がある場合があります。