14

Linux で実行されている WebSphere Portal Server にデプロイされたポートレット アプリケーションを構築しています。すべてのポートレット WAR は、次のような構成でログ記録に Log4j を使用し、すべての WAR に 2 つのログ ファイルがあります。

log4j.logger.im.the.package=DEBUG, InfoAppender, DebugAppender

log4j.appender.InfoAppender=org.apache.log4j.RollingFileAppender
log4j.appender.InfoAppender.Threshold=INFO
log4j.appender.InfoAppender.File=/tmp/infoWARName.log
log4j.appender.InfoAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.InfoAppender.layout.ConversionPattern=%d %p [%c] - %m%n

log4j.appender.DebugAppender=org.apache.log4j.RollingFileAppender
log4j.appender.DebugAppender.Threshold=DEBUG
log4j.appender.DebugAppender.File=/tmp/debugWARName.log
log4j.appender.DebugAppender.layout=org.apache.log4j.PatternLayout
log4j.appender.DebugAppender.layout.ConversionPattern=%d %p [%c] - %m%n

展開後、すべてがチャームのように機能し、ログ ファイルがいっぱいになり始めました。数時間後、同時にログが停止しinfo.log、debug.logまったく更新されません。ロギングを再開するには、ポートレット WAR をサーバーに再デプロイする必要があります。

何か案は？

アップデート：

Logging JARS と関係があるのではないかと疑い始めています。WEB-INF/lib現在、これは私のフォルダー内のJARです：

com.springsource.org.apache.commons.logging-1.1.1.jar
com.springsource.org.apache.log4j-1.2.15.jar
com.springsource.slf4j.api-1.5.6.jar
slf4j-log4j12-1.5.6.jar

2 回目の更新:

バウンティから終了までの数時間、これがすべてのポートレット アプリケーションで Log4j が構成されている方法です。ここにありweb.xmlます：

<context-param>
    <param-name>log4jConfigLocation</param-name>
    <param-value>classpath:miAppLog4j.properties</param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
</listener>

miAppLog4j.propertiesファイルは、WAR およびポータルの外部のフォルダーにあります。WebSphere Portal の共有ライブラリーを介して Portlet Classpath で利用できるようにしました。

4

5 に答える 5

25

あなたはいくつかの基本的な情報を提供したので、いくつかの候補となる原因と可能性をスケッチすることしかできません:

1. ファイル ロック/ハンドル/IO ストリームの問題

  • ログローリングによってトリガーされましたか?

    あなたの場合は否定的です。2 つの個別のログ ファイル (情報とデバッグ) は、任意の WAR で同時に停止します。各ファイルは、デフォルトの最大サイズ (10MB) でロールバックされます。両方のログが常に同時にロールされる可能性はほとんどありません。ログのローリングによってエラーが発生してはなりません。構成による追加の確認log4j.appender.InfoAppender.MaxFileSize=200MB

  • Linux ファイルを操作するユーザーによってトリガーされますか?

    あなたの場合は否定的です。ユーザー/システム管理者がファイルを操作すると、ロックや古いファイル ハンドルが作成される可能性があります。Linux では、ファイルのユーザーテールイングで問題が発生することはありません (ただし、Windows では発生します)。Linux では、ユーザーがファイルを圧縮または編集する際に問題が発生する可能性があります。しかし、あなたの問題は非常に再現性が高いように思われるため、ログファイルを操作する自動化されたスクリプトがない限り、これは起こりそうにありません。

  • Websphere または Spring の「競合する」構成設定によってトリガーされ、サーバー/フレームワークによって同じログ ファイルが重複して使用されていますか?

    あなたの場合はありそうにないようです。Websphere Commons のロギング構成を設定していないようです。Commons ロギングは Websphere サーバーの親 ClassLoader に自動的に含まれ、次のように構成することで Log4J に「ラップ」するように構成できます。

    ファイルcommons-logging.properties

    # Set application classloader mode as PARENT_LAST when deploying in WAS as .ear
priority=1
org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl

  • ハードウェアの問題/ディスク障害が原因ですか?

    ??? そのような問題が非常に繰り返し可能であることは奇妙に思えます。

2. Java スレッドに問題がありますか?

  • スレッドの死またはデッドロック

  • 「その他」のコードで大量のスレッド処理/競合が発生し、ログ記録のあるコードが実行されない

    あなたの説明から、アプリケーションはまだ実行されており、通常のパフォーマンスと機能で正常に動作していると思いますが、ログは書き込まれていません。確認できますか？もしそうなら、それは webapp スレッドのスレッドの問題ではありません。

    また、Log4J ロジック内のスレッドの問題ではないことを確認できます。独自のスレッドを作成/使用するのは、AsynchAppender/ExternallyRolledFileAppender/SocketAppender/TelnetAppender のいずれかが使用されている場合、または PropertyConfigurator.configureAndWatch または DOMConfigurator.configureAndWatch の場合のみであるためです。メソッドが呼び出されます。

    すなわち負。

3. 別の構成を使用して、ClassLoaders の Log4J クラスに変更を加えましたか?

  • 親 ClassLoader が Webapp ClassLoader と衝突する

    たとえば、Web アプリケーションは、最初は WEBINF ディレクトリから独自に構成されたクラスで開始され、すべて問題ありませんが、しばらくすると、別のアプリケーション (またはポータル サーバー管理ツールの 1 つ) が原因で、衝突するクラスが親 ClassLoader にロードされ、 app は、この新しい不正なバージョンのクラスを「取得」して失敗します。

    おそらく問題です。Google の何千人ものユーザーが Websphere クラス ローダーに苦労しています。

推奨されるアクション:

  • すべての Web アプリが PARENT_LAST ClassLoading を使用していることを確認します - 管理コンソールに移動し、すべての Web アプリ構成内で PARENT_LAST が設定されていることを確認します

  • コンソールに Log4J 内部エラー メッセージが書き込まれていることを確認します。「Log4J:」エラー メッセージがコンソールに表示されない場合、これは深刻な問題です。
    次に問題が発生したときは、そのようなコンソール メッセージをトラップして報告してください。また、JVM/websphere の起動時に "-D log4j.debug" を設定して、問題の発生前/発生中に Log4J が何をしていたかを正確に調べることができます。メッセージはコンソールに送られます。

  • すべてのパッケージとクラスのログ レベルを DEBUG に設定する必要がありますか? INFO または WARN に設定し、特定の問題をデバッグしているときにのみ選択的に設定する方がよいでしょうか?

それはたくさんのテキストです........... B ^)

于 2013-02-26T05:50:24.867 に答える
4

Log4jは、5年以上の間、バグがほとんど修正されていません。事実上、死んだプロジェクトです。許容できる場合は、SLF4jを直接実装するLogbackに置き換えることを検討してください。

LogbackとSLF4Jは、Log4J（Ceki）を書いたのと同じ人によって書かれ、さらにリベラルなライセンスを持ち、優れたコミュニティを持っています。これは、可能な限りすべての点でLog4J 1の後継です（名前を除く）。

于 2013-03-01T09:50:11.087 に答える
3

問題は、同じログ ファイルに複数の WAR が書き込まれていることだと思います。私たちの経験では、特にローリング アペンダーでは、log4j はこれを確実に行うことができません。1 人が転がそうとすると、他の人は混乱し、それ以上記録できなくなります。または、古いファイルへのログを続行します。

それぞれの WAR ログを別のファイルに記録する必要があると思います。

于 2013-01-10T14:35:58.790 に答える
0

ログ ファイルの場所を一時ファイル システム以外の場所に移動してみます。

于 2013-01-10T13:14:44.083 に答える
-2

アプリケーションで log4j が停止する理由がわかりません。しかし、log4j 2.0 にアップグレードできます (すべきです)。切り替えはそれほど手間がかかりません。新しいバージョンではプロパティ ファイルがサポートされなくなったため、log4j.properties ファイルを XML ファイルに書き直す必要があります。

Java Magazin の記事では、log4j 2.0 はマルチスレッド環境でより堅牢に動作するため、問題が解決される可能性があると述べられています。そうでない場合でも、新しいバージョンの利点があります。

いくつかの優れた機能と拡張機能をもたらします ( log4jサイトからコピー):

API分離

Log4j の API は実装から分離されているため、アプリケーション開発者は、前方互換性を確保しながら使用できるクラスとメソッドを明確にできます。これにより、Log4j チームは実装を安全かつ互換性のある方法で改善できます。

改良された性能

Log4j 2 は、重要な領域で Log4j 1.x よりも高速に実行され、ほとんどの状況で Logback と同様に実行されます。詳細については、パフォーマンスを参照してください。複数の API のサポート Log4j 2 API が最高のパフォーマンスを提供しますが、Log4j 2 は SLF4J および Commons Logging API のサポートを提供します。

構成の自動リロード

Logback と同様に、Log4j 2 は変更時に構成を自動的にリロードできます。Logback とは異なり、再構成中にログ イベントが失われることはありません。

高度なフィルタリング

Logback と同様に、Log4j 2 は、Log イベントのコンテキスト データ、マーカー、正規表現、およびその他のコンポーネントに基づくフィルタリングをサポートします。ロガーに渡される前、またはイベントがアペンダーを通過するときに、すべてのイベントに適用するようにフィルタリングを指定できます。さらに、フィルターをロガーに関連付けることもできます。Logback とは異なり、これらの状況のいずれでも共通の Filter クラスを使用できます。

プラグインのアーキテクチャ

Log4j は、プラグイン パターンを使用してコンポーネントを構成します。そのため、アペンダー、レイアウト、パターン コンバーターなどを作成および構成するためのコードを記述する必要はありません。Log4j はプラグインを自動的に認識し、構成がプラグインを参照するときにそれらを使用します。

物件サポート

構成でプロパティを参照することができます。Log4j はそれらを直接置き換えます。または、Log4j はそれらを動的に解決する基盤となるコンポーネントに渡します。プロパティは、構成ファイル、システム プロパティ、環境変数、ThreadContext マップ、およびイベントに存在するデータで定義された値から取得されます。ユーザーは、独自のルックアップ プラグインを追加することで、プロパティ プロバイダーをさらにカスタマイズできます。

于 2013-03-01T16:35:54.670 に答える