2

次のように、中央ログ (またはおそらく 2 つ、それぞれがテストまたは本番専用) サーバーをセットアップするのに最適な方法は次のとおりです。

コードが条件文を参照していることを心配する必要はありません。これにより、製品エラー以外のエラーが製品エラー log4j バスに誤って記録される可能性があります。つまり、次のようなコードは必要ありません。

if (!production)
  logWrapper.logTest(error);
else 
  logWrapper.logProd(error);

サーバー名などを密結合して参照し、コードは prod と test の 2 つのサーバー名のいずれかでしか機能しないため、これは望ましくありません。また、開発者がこれを正しく設定せず、ロギング リポジトリを汚染する可能性があるため、これを設定で宣言的に設定することもできません。助言がありますか？

いくつかの詳細、一部は考慮に入れませんが、とにかくそれらをリストします。

  • 現在、 Oracle Application Server 10.1.3.4 で実行され、将来は Oracle WebLogicで実行される Web アプリケーションのみ
  • http://timarcher.com/?q=node/10 ...例外として、中央サーバーはテキスト ファイルをログに記録し、メール送信は行いません!
  • log4j を使用し、slf4j 経由でラップされる可能性があります (slf4j について言及するのはちょっと不謹慎なので、ほとんど無視してください..)
4

6 に答える 6

2

あなたの環境について多くの詳細がなければ、具体的な答えを出すのは難しいですが、複数の環境を処理するためにロギングを設定している場合、これが私が採用するアプローチです。

1）アプリケーションはロギングを気にするべきではありません。たとえば、以下はすべての環境で機能するはずです。

logger.warn("message", error);

2）log4j（または任意のロギングフレームワーク）構成を作成して、ロギングを構成します。これは、2つの方法のいずれかで実行できます。最初の方法は、環境ごとにtest_log4j。{xml、properties}、prod_log4j。{xml、properties}などを作成することです。これにより、各環境の構成が非常に簡単になり、新しい環境を追加するには、新しいファイルを追加するだけです。別の方法は、1つのlog4j。{xml、properties}を作成し、antスタイルのプロパティ置換を使用して、環境ごとに適切な値を挿入することです。プロパティ値は、環境固有のプロパティファイルから、またはJVMに渡される-Dkey=value引数から取得できます。これは、各環境の構成が非常に類似していることを前提とした、DRYスタイルの構成に近いものです。環境間でログレベルを変更する例として、次のようにします。

<logger name="my.example">
  <level value="${my.example.level}"/>
</logger>

3）環境を決定する開始スクリプトを作成し（おそらくマシンまたはマシン上のファイルに基づいて）、正しい構成をロードします。これは、正しいlog4j構成、正しいプロパティファイル、または正しい-Dkey=value引数のいずれかです。

于 2009-04-24T18:24:53.590 に答える
1

使用しているRDBMSについては言及していません。Oracleを使用している場合は、SYS_CONTEXT（）関数を使用してデータベース名を取得できます。そこから、本番/ dev / qa / test/etcにいるかどうかを判断できます。

これがsys_context（）に関する素晴らしい記事です

于 2009-04-24T19:27:28.400 に答える
1

この特定の問題は、logFacesで対処されています、実際、これはログのフラッディングを一元化して削減するために設計された主要な問題の 1 つです。アプリケーション構成で。「My production app」などのアプリケーション名を指定します。アプリケーションからのすべてのログ ステートメントは、集中ログ サーバーに送られ、クエリ用のストレージやリアルタイム表示に使用できます。コードを変更する必要はありません。構成の問題にすぎません。通常、開発中の同じアプリケーションの複数のインスタンスと、QA 中の複数のバージョンがあり、各開発者はビューアを調整して、他のアプリケーションで何が起こっているかを取得できます。私はよく QA ホストを監視しており、ホストが気付く前に問題があることを知っています。もう 1 つの興味深いシナリオは、すべてのアプリケーションで何が起こっているかを一度に確認したいが、データ レイヤーだけに注目したい場合です。

開示: 私はこの製品の作者です。

于 2009-04-24T21:22:11.947 に答える
0

mattkemp はこれをかなり釘付けにしました。私が追加するかもしれないことの1つは、本番環境とテスト版の間で私が期待する主な違いは、テスト版ではおそらくデバッグログが永続的にアクティブになることですが、本番環境では奇妙な動作のまれな場合にのみデバッグログをアクティブにすることです. .

それ以外は、テスト中に発生する可能性のあることはすべて、本番中にも発生する可能性があるため (そして今後も発生する可能性があるため)、少なくともテストと本番からほぼ同じタイプのログ エントリが予想されます。

サーバーのセットアップ自体に関しては、適切な log4j セットアップを使用して、syslog または Windows NT イベント ログのいずれかを使用することをお勧めします。そうすれば、最終システムの他の部分も同じログ サーバーに記録できます。優れたログ システムは、イベントが生成されたサーバーを示します。そのため、イベントが本番またはテストから発生したかどうかが明確になります。

優れた Web ベースの syslog GUI については、http://www.phplogcon.org/ を参照してください。

于 2009-05-07T22:41:33.207 に答える
0

本番用とステージング用に異なるロギング構成ファイルを使用します。

あなたはこれをいくつかの異なる方法で行うことができます

1）アプリに2つの異なる構成ファイル（ステージ用と本番用）を保持し、アプリケーションに、使用しているマシンまたはアプリケーション構成ファイルの設定に基づいて使用する構成ファイルを認識するスタートアップコードを持たせます環境設定を設定します。

2) 単純に 1 つのファイルを用意し、テスト時または本番環境で適切なファイルと交換します。

于 2009-04-24T18:01:41.990 に答える
0

これを設定で設定する必要があると本当に思います。正しい判断です。

于 2009-04-24T18:04:39.377 に答える