2

クラスター化されたグラスフィッシュ環境で複数の Web アプリケーションをホストする必要があります。Logback は、Web アプリケーションで使用されるロギング フレームワークです。ログ構成 (ログ レベルなど) の変更については、専門家の意見や提案が必要です。

現在、いくつかの理由から、logback 構成ファイルを個々の war ファイルに配置しています。

  1. logback.xml を war ファイルの外に手動で配置すると、インストーラー/アップグレード担当者に追加のタスクが追加されます。
  2. Web アプリケーションの将来のバージョンで構成ファイルに加えられた変更は、ソフトウェア アップグレード担当者が処理する必要があります。このような変更の例は、ログ ファイルの場所を JNDI プロパティとして受け入れることです。Web アプリケーションの数が増えると、このタスクがさらに複雑になります。

構成ファイルを war に配置することの欠点は、変更を行うのが難しくなることです。たとえば、新しいロガーを追加したり、ログ レベルを変更したりします。JMX は logback でサポートされている代替手段ですが、2 つの問題があります。

  1. JMX を介して行われた変更は永続化できません。サーバーを再起動すると、構成された変更が失われます。
  2. logback によって提供される JMX サポートでは、新しいファイル アペンダーなどの新しいアペンダーを追加することはできません。

logback 構成ファイルの配置または上記の JMX の問題について何か提案をいただければ幸いです。

4

1 に答える 1

0

私たちは同様の問題に直面しており、他のロギング メカニズムで解決しなければなりませんでした。実際、不快なトレードオフが発生するため、苦痛になる可能性があります。LogBack を使い始めたばかりですが、設定ファイル ( http://logback.qos.ch/manual/joran.html#variableSubstitution ) で変数の置換が可能であると理解しています。私の計画は、この機能を使用して、リンクされた例に示すように、システム プロパティを使用して必要に応じてログをルーティングすることです。

JMXに関しては、同意しました。JMX は監視のため、および条件が整ったときに内部構成を一時的に変更するために広く使用されていますが、JMX は永続的な変更を行うのに最適な選択肢ではありません。少なくとも、変更管理プロセスを経る必要があります。

私の推奨事項: 変数置換アプローチを検討し、JMX を使用して一時的なランタイム調整を行います。

于 2011-11-05T16:50:15.593 に答える