この節では、Monitoring Console および Monitoring Framework における既知の問題点について説明します。Monitoring Framework は、監視を有効にするためにほかのコンポーネントとともに自動的にインストールされる共有コンポーネントです。
Monitoring Framework における特定の既知の問題を回避するために、次のパッチが必要です。これらのパッチは通常、Java ES に必要なほかのパッチバンドル、または Solaris オペレーティング環境の更新されたバージョンに含まれています。ただし、Java ES 製品コンポーネントを監視するホスト上で、これらのパッチまたは代替パッチの存在を確認することをお勧めします。
表 1 Solaris オペレーティング環境を監視するためのパッチ
Solaris のバージョン |
パッチ番号 |
---|---|
Solaris 9 SPARC プラットフォーム (バージョン s9u7_06 およびそれ以前) |
114344-17 |
Solaris 9 i386 プラットフォーム (バージョン s9u7_06 およびそれ以前) |
114345-08 (非推奨。現在の推奨パッチは 117172-17)、118559-28 (またはそれ以降) |
Solaris 10 SPARC Platform (バージョン s10_58 およびそれ以前) |
114344-17 |
Solaris 10 i386 プラットフォーム (バージョン s10_58 およびそれ以前) |
114345-08 (非推奨。現在の推奨パッチは 117172-17)、118855-15 (またはそれ以降) |
HP-UX オペレーティングシステムの場合、監視に必要なパッチは「HP-UX の要件と問題点」で説明するパッチに含まれています。
監視対象の新しいホストを追加する場合、Monitoring Console は SSL を使用して接続をセキュリティー保護しますが、選択されたホストで示された証明書を表示しません。Monitoring Console はホストのルートパスワードをノードエージェントに送信するため、対象ホストの IP アドレスを偽造し、パスワードを受信する攻撃者に対する脆弱性があります。ノードエージェントの大半は、すでにセキュリティー保護されたネットワーク内で動作するホストで実行されているため、この状況が発生するリスクは非常に低くなります。
解決方法: ノードエージェントホストがセキュリティー保護されたネットワーク内で動作していない場合は、これらのホストを Monitoring Console に新規ホストとして追加する前に、信頼性を検証します。ホストの信頼性を検証するには、ホストにログインし、ホストの構成とファイルシステムを認識できることを確認します。UNIX ホストの場合は、ssh でログインし、証明書情報を表示します。
製品に含まれるオブジェクトが、Monitoring Console で「アプリケーションサーバー」として表記されています。この用語を Sun Java System Application Server と混同しないでください。
解決方法: Monitoring Console のコンテキストにおける「アプリケーションサーバー」は、インストールされた Java ES コンポーネントの実行中のインスタンスを指します。
Monitoring Console でのページの表示と切り替えに 30 秒ほどかかる場合があります。
解決方法: 高速なプロセッサと多くのメモリーを搭載した、ほかのアプリケーションを実行していないホスト上で Monitoring Console を実行します。
Monitoring Console では、コンポーネント単位で監視を有効または無効にすることができません。
解決方法: 各コンポーネント独自の機構を通じ、コンポーネントの監視を有効化、および無効化する必要があります。手順については、『Sun Java Enterprise System 5 Update 1 Monitoring Guide』の第 2 章「Enabling and Configuring the Monitoring Framework」のコンポーネント固有のセクションを参照してください。
監視対象コンポーネントがクラッシュしたり、通常の操作によって停止されたりすると、監視対象オブジェクトがノードエージェントから削除されず、Monitoring Console の左側のツリーで表示されたままになります。同様に、ノードエージェント全体を停止すると、ホストノードが左側のツリーから削除されないことがあります。この問題は断続的に発生します。
解決方法: サーバーインスタンスを停止または再起動するとき、ノードエージェント、マスターエージェント、および Monitoring Console も再起動しなければならないことがあります。ホストとノードエージェントを停止した場合、マスターエージェントと Monitoring Console を再起動しなければならないことがあります。『Sun Java Enterprise System 5 Update 1 Monitoring Guide』の「To Restart a Node Agent」の手順は、その両方を行う方法を説明しています。
Monitoring Console からホストを削除するとき、監視対象コンポーネントと関連付けられた監視ルールおよびアラームは自動的に削除されません。そのため、同じホストが再度追加されても、ルールとアラームの状態が持続します。
解決方法: 同じホストを再度追加しない場合は、「ルール」ダイアログを使用し、そのホストに関連するすべてのルールを検索し、削除します。ホストが削除されたときに発生しているアラームが確認されることがありますが、これは Monitoring Console に残ります。アラームをトリガーした監視対象の属性にはアクセスできなくなるためです。アラームを確認状態のまま残しておかないためには、監視対象コンポーネントのすべてのアラーム状態を解決し、ホストを削除する前に Monitoring Console のアラームを確認します。
ルールにスケジュール間隔が設定されている場合、そのルールを無効にすることはできません。
解決方法: ルールを無効にするのではなく、削除します。
次の一覧は、Monitoring Console で確認されているその他の既知の問題を示しています。
複数のテーブルがデフォルトでソートされない
インストール済み製品を使用するオブジェクトからリンクされたホストが不明なオブジェクトになっている
AppServer プラグインの使用時に、サーバーに含まれるオブジェクトに孫のオブジェクトが含まれているが、これは適切でない
ホストのテーブルで機能の有効化および無効化が正しく機能しない
「統計」および「設定」オブジェクトに対してはキャプションおよび説明フィールドが表示されるが、ベースオブジェクトに対しては表示されない
オブジェクトを選択して「監視ルール」、「新規作成」の順にクリックしたときに、ユーザーがオブジェクトをもう一度選択しなければならないが、これは適切ではない
特定のホストに対して一覧表示される JVM オブジェクトの名前が一貫していない
Application Server によって作成される CMM_Cluster オブジェクトがどこにも表示されない
「新しいルール」ダイアログの監視可能オブジェクトのリストが明瞭でない
Portal Server、Web Server、および Application Server オブジェクトのオブジェクトおよび動作ステータスが不明として表示される
Application Server で配備される Enterprise JavaBeans の名前が説明的でない
Application Server 監視オブジェクトで属性の名前が使用できない
Application Server の内部設定の変更が Monitoring Console に反映されない
Monitoring Console は、ドメイン表示を公開できなければならない
de ロケールで、オンラインヘルプの索引が英語版と一貫性がない
「選択されたオブジェクトを表示」が設定されていると「次のステータスを持つオブジェクトを表示」機能が動作しない
スクリプトのエラーで、ルールからスケジュール間隔の削除ができない
JVM-General テーブルで一部の文字列がローカライズされていない
スペイン語のユーザーインタフェースで、著作権の文字列がローカライズされていない
Monitoring Console のユーザーインタフェースで多くの文字列がローカライズされていない
ルールのスケジュール間隔を 0:00 から 0:00 に変更すると、ルール自体が削除される
Monitoring Framework とのインタフェースを C ライブラリに依存するコンポーネントは、Linux オペレーティング環境で動作するときに Monitoring Console での表示が遅くなる場合があります。
解決方法: なし。
C ライブラリに依存するコンポーネントと、同じホスト上のノードエージェント間のプロセス間通信はセキュリティー保護されません。デフォルトでは、通信はループバックインタフェースを使用してセキュリティーリスクを軽減します。
解決方法: なし。
Monitoring Framework とのインタフェースを Java ライブラリに依存するコンポーネントでは、SNMP 経由でのアクセス時にパフォーマンスの問題が発生する場合があります。
解決方法: なし。
Solaris 9 のバグが原因で、宛先が IPv4 アドレスであるパケットが IPv6 ソケット上のリスナーに配信されません。これにより、ノードエージェントと、そのホスト上の監視対象コンポーネントの間で検出メカニズムが遮断されます。
解決方法: 次のコマンドを使用して、ノードエージェントの JVM に強制的に IPv4 ソケットを待機させます。
cacaoadm stop oldvalue=`cacaoadm get-param java-flags --value` cacaoadm set-param java-flags="${oldvalue} -Djava.net.preferIPv4Stack=true" |
次に、ノードエージェント、マスターエージェント、および Monitoring Console を、『Sun Java Enterprise System 5 Update 1 Monitoring Guide』の「To Restart a Node Agent」で示す手順で再起動します。
ノードエージェント上の時刻と、マスターエージェントホスト上の時刻のずれが大きすぎる場合、Monitoring Console でのそのノードの追加は失敗します。マスターエージェントの Monitoring Framework のエラーログには、「JRMP 接続確立中の」重大なエラーが報告されます。
解決方法: 両方のホストで時刻が同期するように設定します。
HP-UX オペレーティングシステムのノードエージェントで、多数の監視ルールが並行的に作成されると、Java 仮想マシン (JVM) のスレッド数がカーネルパラメータの上限を超え、OutOfMemory 例外が発生することがあります。
解決方法: 『Sun Java Enterprise System 5 Update 1 Monitoring Guide』の「To Optimize Kernel Parameters for Monitoring Framework on HP-UX」で示すように、HPjconfig ツールをダウンロードし、実行します。
Windows で mfwkadm コマンドを実行すると、次のエラーが生成されます。
'C:\Program' is not recognized as an internal or external command, operable program or batch file. |
解決方法: ファイル C:\Program Files\Sun\JavaES5\share\mfwk\bin\masetup.bat の 4 行目で、行頭に REM を追加してコメントにします。
編集前: |
|
|
編集後: |
|
次の一覧は、Monitoring Framework で確認されているその他の既知の問題を示しています。
Linux で、IPv6 が有効なときに、検出が機能しない