Oracle® Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド 12cリリース3 (12.1.0.3) B65085-09 |
|
前 |
次 |
この章の内容は次のとおりです。
ホスト・コンピュータにOracle Management Agentをインストールすると、そのホスト上の各ターゲットのパフォーマンスおよび可用性の監視に使用可能なデフォルト・メトリック・セットの収集がEnterprise Managerで自動的に開始されます。これらのターゲット・メトリックの一部については、メトリックに問題があることをいつ通知するかを決定するデフォルトのしきい値設定がEnterprise Managerで提供されます。
関連項目: Enterprise Managerのオンライン・ヘルプのアラートに関する項 |
選択したメトリックについて、デフォルトのしきい値をカスタマイズできます。このようなカスタマイズを実行すると、新規の設定がローカル・ディスク上のファイルに保存されます。これらの設定の保存について、次の項でより詳しく説明します。
Enterprise Managerでは、各ターゲットに対するデフォルトの収集基準が各Oracle Management Agentホストの次の場所に保存されます。
AGENT_HOME/sysman/admin/default_collection/
パスは、default_collectionおよびターゲットのメタデータが含まれるプラグイン・ホームでは異なります。エージェント・ホームには、ホストやoracle_emdなどのターゲットに対してのみ収集やメータデータの詳細が含まれます。
一部のターゲットについては、Enterprise Manager Cloud Controlコンソールを使用してデフォルトのメトリック収集設定を変更できます。たとえば、ホスト・ターゲットのデフォルトのしきい値を変更できます。このような変更を実行すると、新規のインスタンス収集ファイルが次のディレクトリに作成されます。
AGENT_HOME/sysman/emd/collection/
この収集ファイルは、sysman/admin/default_collection
ディレクトリに保存されているデフォルトの収集情報を上書きします。
Oracleソフトウェア製品をホスト・コンピュータにインストールするたびに、Oracle Universal Installerによってソフトウェアのインストール情報がハード・ディスクに保存されます。このソフトウェア構成情報を含むディレクトリおよびファイルは、Oracle Universal Installerインベントリと呼ばれます。
関連項目: 『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド』 |
Enterprise Managerを使用してOracleソフトウェアのインストールを監視する際、Universal Installerインベントリに保存されている情報が利用されます。
ホスト・コンピュータの構成に関する情報を収集する際、デフォルトでは、ホスト上に1つのOracle Universal Installerインベントリがあるものと想定されます。具体的には、Enterprise Managerはホスト上でOracle Universal Installerを実行する際に使用されるインベントリを認識します。
ただし、複数のインベントリがある場合もあります。たとえば、Oracleサポートに連絡をとり、Oracleソフトウェア・インストールのクローンを作成しているような場合です。このような場合は、次の手順を使用して、同一ホスト上の複数のインベントリのソフトウェア情報をEnterprise Managerで追跡および管理できるようにしてください。
注意: 複数のインベントリに対するサポートの有効化はオプションであり、Oracle Universal Installerインベントリのアーキテクチャを熟知し、以前に管理対象ホストで複数のインベントリを管理した経験を持つ上級ユーザーのみが使用できます。この手順は、通常のインストールが行われたホストについては不要です。 |
ホスト上の複数のインベントリを認識できるようにEnterprise Managerを設定するには、次の手順を実行します。
次のディレクトリにあるOUIinventories.addファイルを探します。
<agent_inst>/sysman/config
この例で示した管理エージェントの状態は、Database Controlのインストールを表します。他のインストールに使用する管理エージェント状態の詳細は、第10.2.1項「AGENT_HOMEディレクトリとAGENT_STATEディレクトリ」を参照してください。
テキスト・エディタを使用してOUIinventories.addを開きます。
ファイル内の指示には、Oracleホームのマッピングに関するその他の技法とともに、複数のインベントリの指定時に使用する書式が記述されています。
ファイル内の指示を注意して確認します。
管理対象ホスト上の各追加インベントリについて、エントリをファイルに追加します。
変更を保存してファイルを閉じます。
次のホスト構成情報の収集時に、通常Enterprise Managerで収集されるデフォルト・インベントリに加えて、OUIinventories.addファイルで指定したインベントリからもソフトウェア構成情報の収集が開始されます。
もう1つの方法として、次の定期収集スケジュールの前に追加インベントリから収集されるデータを確認するには、Cloud Controlコンソールのホストのホームページにナビゲートして、「構成」タブをクリックし、ページ・タイムスタンプの横にある「データのリフレッシュ」アイコンをクリックします。
注意: デフォルト・インベントリの収集時にリカバリ不能な問題がある場合(インベントリ・ファイルまたはディレクトリの保護機能によってEnterprise Managerでインベントリの読取りができない場合など)は、OUIinventories.addファイルに列記されたインベントリも収集されません。Enterprise Managerでデフォルト・インベントリの読取りはできても、OUIinventories.addファイルに列記された追加インベントリの読取りに問題がある場合、これらのインベントリに対する収集警告が発行されます。しかし、他のインベントリに対する構成情報は収集されます。 |
管理エージェントでは、ソフトウェア・バイナリおよびすべての未変更メタデータが格納されるインストール・ディレクトリと、すべてのカスタマイズ内容および出力/ログの内容が格納または生成、あるいはその両方が行われる構成/状態ディレクトリの主要な2つのディレクトリ構造を認識します。標準の管理エージェント・インストールでは、この2つのディレクトリは同じです。ただし、次の場合は、これらが別になることもあります。
Database Controlインストール($ORACLE_HOMEと$ORACLE_HOME/<nodename>_<sid>)
(emctl deploy agent
コマンドを使用する)状態のみの管理エージェント・デプロイ($ORACLE_HOMEと$EMSTATE)
前述の各例では、同じバイナリ・インストールから管理エージェントの複数のインスタンスが実行されます。これらのインスタンスは個々の構成を保守するために別々の場所を持ちますが、同じバイナリ・セットを使用します。コマンドemctl status agent
を使用すると、管理エージェントのバイナリおよび状態の場所の値がわかります。
AGENT_BASEディレクトリまたはORACLE_BASEディレクトリには、管理エージェントのバイナリが含まれます。ディレクトリのこの部分は読取り専用です。新規管理エージェントでは、AGENT_BASEまたはORACLE_BASEと呼ばれる1つの親ディレクトリ下に複数のOracleホームを作成します。
エージェントの状態ディレクトリは通常AGENT_BASE下に配置されます。エージェントの状態ディレクトリを意図的に他の場所に配置することもできます。たとえば、NFSインストールの場合、エージェントの状態ディレクトリはAGENT_BASE下に配置されません。これは、非デプロイメント・エージェント・コードが書き込まれる唯一のディレクトリです。
インストーラによって設定される状態ホーム(インスタンス・ホーム)のデフォルト名はagent_instです。状態ホームには、ワールドに対する読取り権限と実行権限を設定する必要があります。
Oracle Databaseターゲットを最初に検出したときは、監視資格証明をチェックして、DBSNMPデータベース・ユーザー・アカウントのパスワードがデータベース・ターゲット・プロパティで正しく設定されていることを確認してください。
監視資格証明の設定以外に、Oracle Databaseターゲットを監視するために必要な構成タスクはありません。
ただし、Oracle9iデータベースを監視するときは、Cloud Controlコンソールを使用して特定のタイプのデータベース・パフォーマンス・メトリックを監視する場合に追加構成が必要になります。
これらの追加パフォーマンス・メトリックを監視するには、Oracle Statspackおよびその他のEnterprise Managerパッケージが、監視中のデータベースにインストールされ構成されていることが必要です。
関連項目: Oracle9iドキュメント・ライブラリの『Oracle Databaseパフォーマンス・チューニング・ガイド』のStatspackの使用方法に関する項 |
これらの追加オブジェクトがデータベース内になく構成もされていない場合、Enterprise Managerは完全なパフォーマンス・メトリック・セット用のデータを収集することができません。また、「エラーSQL」や「上位SQLレポート」のような、通常ならデータベースのホームページから容易に入手できるような情報もEnterprise Managerでは収集できなくなります。
Cloud Controlコンソールでデータベースの構成ウィザードを使用して必要なパッケージをデータベースにインストールするか、または次の手動による手順を使用できます。
関連項目: データベース・ターゲットを含む管理対象ターゲットの構成の詳細は、Enterprise Managerのオンライン・ヘルプのターゲット・プロパティ変更に関する項 |
Statspackおよびその他の必須データベース・オブジェクトを、Enterprise Managerで管理中のOracle9iデータベースに手動でインストールするには、SQL*Plusおよび次の手順を使用します。
データベース・ホーム・ディレクトリおよび管理エージェント・ホーム・ディレクトリへの書込み権限を持つアカウントを使用して、データベース・ホストにログインします。
この手順の各コマンドについて、AGENT_HOMEをOracle Management Agentホーム・ディレクトリの実際のパスに置き換え、ORACLE_HOMEをデータベース・ホーム・ディレクトリのパスに置き換えてください。
SQL*Plusを起動し、SYSDBA権限を持つSYSアカウントを使用してデータベースに接続します。
次に例を示します。
$PROMPT> ./sqlplus "connect / as sysdba"
次のコマンドを入力して、データベースのdbmonスクリプトを実行します。
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/dbmon
次のプロンプトが表示されます。
Enter value for dbm_password:
プロンプトが表示されたら、DBSNMPアカウントのパスワードを入力します。
スクリプトで各種の構成変更が実行され、再びSQL*Plusプロンプトが表示されます。
次に例を示します。
SQL> connect DBSNMP
次のコマンドを入力します。
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/response.plb SQL> grant EXECUTE on dbsnmp.mgmt_response to OEM_MONITOR;
注意: 前述のスクリプトは、リリース8.1.7以下のOracleデータベースでは実行しないでください。Oracleでは、8.1.7以下のデータベースのSQLレスポンス時間はサポートしていません。 |
SYSユーザーとして接続し、次のコマンドを入力してPERFSTATユーザーを作成します。
SQL> @ORACLE_HOME/rdbms/admin/spcreate
注意: spcreate スクリプトでは、PERFSTATユーザーに対するデフォルト表領域とデフォルト一時表領域が求められます。SYSTEM表領域は、PERFSTATユーザーに対するデフォルト表領域として指定しないでください。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のStatspackの使用方法に関する項を参照してください。 |
PERFSTATユーザーとして接続します。
次に例を示します。
SQL> connect PERFSTAT;
PERFSTATユーザー・アカウントから次のコマンドを入力します。
SQL> define snap_level='6'; SQL> define cinterval='1'; SQL> define cjobno='-1'; SQL> @AGENT_HOME/sysman/admin/scripts/db/config/spset
SYSユーザーとして接続し、次のコマンドを入力します。
SQL> grant OEM_MONITOR to dbsnmp;
変更するデータベースがOracle8iデータベースの場合は、SYSユーザーとして次のコマンドも入力します。
grant select on sys.ts$ to OEM_MONITOR;grant select on sys.seg$ to OEM_MONITOR;grant select on sys.user$ to OEM_MONITOR;grant select on sys.obj$ to OEM_MONITOR;grant select on sys.sys_objects to OEM_MONITOR;grant select on sys.file$ to OEM_MONITOR;grant select on sys.attrcol$ to OEM_MONITOR;grant select on sys.clu$ to OEM_MONITOR;grant select on sys.col$ to OEM_MONITOR;grant select on sys.ind$ to OEM_MONITOR;grant select on sys.indpart$ to OEM_MONITOR;grant select on sys.indsubpart$ to OEM_MONITOR;grant select on sys.lob$ to OEM_MONITOR;grant select on sys.lobfrag$ to OEM_MONITOR;grant select on sys.partobj$ to OEM_MONITOR;grant select on sys.tab$ to OEM_MONITOR;grant select on sys.tabpart$ to OEM_MONITOR;grant select on sys.tabsubpart$ to OEM_MONITOR;grant select on sys.undo$ to OEM_MONITOR;
サポートされるすべてのデータベース・バージョンについて、SYSアカウントから次のコマンドを入力します。
SQL> show parameter job_queue_processes
show parameterコマンドの出力がゼロの場合は、次の手順を実行してjob_queue_processes初期化パラメータを変更します。
spfileを使用してデータベースを起動する場合は、次のコマンドを入力します。
SQL> alter system set job_queue_processes = 2 SCOPE=BOTH;
その他の場合は次の手順を実行します。
次のコマンドを入力します。
SQL> alter system set job_queue_processes = 2;
SQL*Plusを終了し、データベースがいつ再起動してもパラメータが適用されるように、init.oraデータベース構成ファイルを次のエントリで更新します。
job_queue_processes=2
SQL*Plusを終了し、ディレクトリを、データベースを監視している管理エージェントのホーム・ディレクトリ内の次のディレクトリに変更します。
AGENT_HOME/bin
次のコマンドを入力して管理エージェントをリロードします。
$PROMPT> ./emctl agent reload
Cloud Controlコンソールを使用して、データベースのホームページに戻り、「エラーSQL」や「上位SQLレポート」などのメトリックが収集されているかを確認します。
表10-1は、Enterprise Managerコンポーネントのタイムアウト値について説明しています。
表10-1 Enterprise Managerコンポーネントのタイムアウト値
コンポーネント | 説明 | タイムアウト値(分) | コマンド |
---|---|---|---|
Apacheセッションがアクティブな状態の秒数。 Apacheのタイムアウトがオペレーティング・システムのTCPタイムアウト以上に設定されている場合、予測できない結果が生じる場合があります。オペレーティング・システムのタイムアウトは、デフォルトで2時間に設定されています。 |
5分(デフォルト) |
次のコマンドを実行します。 $ omsvfy show tcp Parameters Incoming Value -------------------- tcp_keepalive_time 7200 tcp_keepalive_intvl 75 tcp_fin_timeout 60 -------------------- |
|
これは、OMSごとに設定可能な ログインのタイムアウト値を変更する場合は、デフォルトのタイムアウト期間以外にもセッションをオープンにすることのセキュリティ上の問題を十分に考慮してください。 注意: デフォルトのタイムアウト値は、WebサーバーまたはOMSの再起動の際には適用されません。これらのケースの両方で、デフォルトのタイムアウト値に関係なくCloud Controlコンソールへログインすることを求められます。 |
45分(デフォルト) |
次のコマンドを実行します。 次に、OMSを再起動して値を有効にします。 |
|
この値は、変数 |
10分 |
なし |
|
パラメータ
|
デフォルト: 0 最小値: 0 推奨値:10 |
例: SQLNET.EXPIRE_TIME=10 |
この項では、クラスタ・データベースおよび検出インスタンスの構成方法について説明します。特に、次の内容について説明します。
クラスタ・ターゲットを追加した後は、「データベース」ページまたは「すべてのターゲット」ページからクラスタ・データベース・ターゲットを追加できます。
クラスタ・データベース・ターゲットを追加するには、次の手順を実行します。
Enterprise ManagerのCloud Controlコンソールで、次のいずれかの開始場所を選択します。
「データベース」ページから「追加」をクリックします。「データベース・インスタンス・ターゲットの追加: ホストの指定」ページが表示されます。
「すべてのターゲット」ページで、「追加」ドロップダウン・メニューから「データベース・インスタンス」を選択し、「実行」をクリックします。「データベース・インスタンス・ターゲットの追加: ホストの指定」ページが表示されます。
クラスタ・データベースが存在するクラスタ・ターゲットのホスト・メンバーを指定し、「続行」をクリックします。「データベースの追加: ソースの指定」ページが表示されます。
(クラスタ内のすべてのホストに対して)選択されているデフォルト・オプションを使用し、「続行」をクリックします。このオプションによって、クラスタ内のすべての管理エージェントに、検出を実行するためのリクエストが送信されます。
ターゲットの検出が完了すると、「クラスタでターゲットが検出されました: {0}」ページに、新しく検出されたRACデータベースが表示されます。データベースが表示されない場合は、後述の「トラブルシューティング」の項を参照してください。
「クラスタ・データベース」表に目的のターゲットが表示されない場合、または検出されたターゲットが適切に構成されていない場合は、「手動で追加」をクリックします。クラスタ・データベースの構成ウィザードの「プロパティ」ページが表示されます。
「プロパティ」表に必要な値を入力します。
「インスタンス」表には、少なくとも1つのインスタンスを指定する必要があります。この表にインスタンスが表示されない場合は、「追加」をクリックします。「プロパティ: インスタンスの追加」ページが表示されます。必要な値を入力し、「OK」をクリックします。クラスタ・データベースの構成ウィザードの「プロパティ」ページが再び表示されます。
「次へ」をクリックします。データベース・リリース10.1以上の場合、Enterprise Managerは「パッケージのインストール」、「資格証明」および「パラメータ」のステップを省略し、直接「確認」ページに進みます。
「OK」をクリックします。「クラスタでターゲットが検出されました」ページが再び表示され、新しく追加されたクラスタ・データベースおよびインスタンスが表示されます。
関連項目: クラスタ・データベースの構成方法の詳細は、Enterprise Managerのオンライン・ヘルプ |
追加のインスタンスを構成する必要がある場合、次の手順に従います。
Enterprise Managerで、「ターゲット」ページの「データベース」を選択し、目的の「クラスタ・データベース」ホームページに移動します。
「関連リンク」セクションで「監視構成」をクリックします。クラスタ・データベースの構成ウィザードの「プロパティ」ページが表示されます。
ページの上部にある「プロパティ」表に必要な情報を入力します。
「インスタンス」表を調べます。1つ以上の追加のインスタンスが存在していても、「インスタンス」表に表示されていないことがあります。その場合は、「追加」をクリックしてクラスタ・データベース内のインスタンスを検出します。「プロパティ: インスタンスの追加」ページが表示されます。
必要な情報を入力し、「OK」をクリックします。ウィザードの「プロパティ」ページが再び表示され、追加されたインスタンスのビューが表示されます。
「接続のチェック」をクリックして、その接続が機能していることを確認します。
関連項目: クラスタ・データベースに追加されたインスタンスの検出方法の詳細は、Enterprise Managerのオンライン・ヘルプ |
構成の問題が発生した場合は、次の必要な条件をチェックして、自動検出が正常に機能することを確認してください。
管理エージェントを実行しているホスト・ユーザーが、Oracleホーム内のSRVCTLユーティリティを実行でき、データベース構成を取得できること
管理エージェントを実行しているホスト・ユーザーが、OS認証を使用してSQLPLUSを介してデータベースに接続できること
Oratab (UNIX)またはRegistry (Windows)にデータベースに関する情報が含まれていること
前述の条件を確認した後も自動検出で構成の問題が解決されない場合は、クラスタ・データベースを手動で構成できます(第10.5.1項「クラスタ・データベースの構成」を参照)。
クライアントは、ホストおよびオペレーティング・システムのユーザーです。収集されるクライアント構成データには、次のものがあります。
クライアントのハードウェア。
クライアントのオペレーティング・システム(オペレーティング・システムのプロパティ、ファイル・システム、パッチなどの情報を含みます)。
オペレーティング・システムに登録されたソフトウェア。
ネットワーク・データ。これには次のものが含まれます。
Webサーバーに対する待機時間
Webサーバーに対する帯域幅
クライアント構成収集アプレットへのアクセスに使用されるブラウザの構成が記述されたクライアント固有のデータ項目。これには次のものが含まれます。
ブラウザ・タイプ(ベンダー)
ブラウザ・バージョン
(クライアント構成収集アプレットの実行に使用されるJVMの)JVMベンダー
(クライアント構成収集アプレットの実行に使用されるJVMの)JVMバージョン
プロキシ・サーバー(指定されている場合)
プロキシ・サーバー例外
ブラウザ・キャッシュ・サイズ(MB)
ブラウザ・キャッシュの更新頻度
サポートされているHTTPバージョン
その他のクライアント指向のデータ項目。これには次のものが含まれます。
クライアント構成収集アプレットの識別子(アプレット・コード内で定義されるバージョン)
(クライアント構成収集アプレットへのアクセスに使用された)アプリケーションURL
ブート・ドライブのシリアル番号(ディスクがないシステムでは使用不可)
(クライアント構成収集アプレットJSPからの)収集タイムスタンプ
収集期間(ミリ秒)
クライアントのIPアドレス
有効なクライアントIPアドレス - クライアントと、クライアント構成収集アプレットを提供するWebサーバーの間でネットワーク・プロキシ・サーバーが使用されている場合、有効なクライアントIPアドレスは、そのプロキシ・サーバーのIPアドレスになります。
クライアント・システム・アナライザ(CSA)を使用すると、Webサーバーの管理者はエンドユーザーのクライアント・データを収集および分析できます。クライアント・データはアプレットにより収集され、診断されてCSAアプリケーションに送り返されます。Oracle Management Agentは、このデータをEnterprise Managerの管理リポジトリにアップロードします。クライアント構成収集アプレットによりクライアント構成データが収集され、CSAアプレットで指定されたWebサーバー・ディレクトリに書き込まれた後、そのクライアント構成データはOracle Management Repositoryにアップロードされます。
Enterprise ManagerとともにプリインストールされているCloud Controlアプリケーションでクライアント・システム・アナライザを使用するか、またはCSAを別個にWebサーバーにデプロイできます。
Cloud Controlのクライアント・システム・アナライザ(CSA)のインスタンスは、Enterprise Managerとともにプリインストールされています。このオプションを使用すると、個別のWebサーバーを設定しなくてもクライアント・データを収集できます。プリインストールされているCSAアプリケーションをEnterprise Managerでアクティブにするには、「構成」をクリックし、「Cloud Controlのクライアント・システム・アナライザ」をクリックしてアプリケーションをアクティブにするためのボタンを使用します。CSAがアクティブになると、エンドユーザーは、CSAアプレットを実行するために提供されたURLを使用できるようになります。CSAアプレットは、クライアント・システムから基本クライアント構成情報を収集し、Oracle Collaboration Suiteクライアント・システムからOracle Collaboration Suiteクライアント情報を収集できます。
CSAアプレットをダウンロードし、アプレットにより基本クライアント構成情報を収集する場合、クライアントは、http[s]://management-service-host:port/em/public/ecm/csa/CSAという形式のクライアント・システム・アナライザURLを使用する必要があります。
CSAアプレットをダウンロードし、アプレットによりOracle Collaboration Suiteクライアント構成情報を収集する場合、クライアントは、http[s]://management-service-host:port/em/public/ecm/csa/CSA?application=OCSという形式のクライアント・システム・アナライザURLを使用する必要があります。
クライアント・システム・アナライザ・アプリケーションは、別個に任意のJ2EE対応Webサーバーにデプロイできます。「デプロイ」タブをクリックします。次に「クライアント・システム・アナライザの開始」をクリックし、「クライアント・システム・アナライザ・アプリケーションのデプロイ」をクリックします。次の手順に従ってCSAアプレットをデプロイし、クライアント構成データを収集します。
CSAアプリケーションをダウンロードします。
CSAアプリケーションには、CSAディレクトリと必要なJSPアプレット・ファイルが含まれています。CSAアプリケーションは、EARファイルとしてパッケージ化されています。このデフォルトEARファイルをダウンロードするには、「クライアント・システム・アナライザ・アプリケーションのダウンロード」をクリックします。デフォルトのCSA EARファイルをカスタマイズするには、次の要素を変更します。
ルール - このファイルには、クライアント・データの評価に使用されるデフォルトのルール・セットが含まれます。CSAのデプロイ前に、ルールのカスタマイズおよび追加を行うことができます。
コンテキスト・パラメータ - web.xmlファイル内のコンテキスト・パラメータをカスタマイズできます。
カスタム・クラス - 追加データの収集、アプレットの動作の変更、クライアントに対する特定の操作の実行といったタスクに使用できる、カスタマイズしたアプレット・クラスを指定できます。
CSAを任意のJ2EE Webサーバーにデプロイします。
CSAアプリケーションは、標準のJ2EEアプリケーションとしてアプリケーション・サーバー上にデプロイされます。CSAアプリケーションをデプロイした後は、他のWebアプリケーションと同様に、コンテキスト・パラメータを変更できます。
ユーザーをCSAにダイレクトします。
クライアント・データを収集するためには、ユーザーがCSAアプリケーションにアクセスする必要があります。ユーザーはCSA JSPページに直接アクセスするか、または別のアプリケーションからリンクを使用してアクセスできます。次の方法を使用すると、ユーザーをCSAに自動的にリダイレクトできます。
HTTPサーバー(Apacheのmod_rewrite) - このオプションを使用する場合、Webアプリケーションを変更する必要はありません。
サーブレット・フィルタ - サーブレット・フィルタは、サーバーを往来するリクエストをフィルタ処理するプログラムです。CSA_filter.jarファイルには、サーブレット・フィルタ・クラスが含まれています。サーブレット・フィルタおよびフィルタ・マッピングをWebアプリケーションに追加する必要があります。
CSAリダイレクションJSP - CSAリダイレクションJSP (CSARedirect.jsp)のページをWebアプリケーションに組み込むことができます。
Enterprise Managerを構成します。
収集されたクライアント・データは、Webサーバー上の受信ファイル・ディレクトリ内に記録されます。収集されたクライアント・データをEnterprise Managerにアップロードするには、次の操作を実行する必要があります。
CSAコレクタ・ターゲットをEnterprise Managerの管理エージェントに追加します。これを行うには、「コレクタの追加」をクリックし、リストからターゲットを選択します。
受信ファイル・ディレクトリの絶対パスを指定します。CSAアプリケーションのoutputDirパラメータと同じパスを指定する必要があります。デフォルトでは、クライアント・データはクライアント・システム・アナライザWebアプリケーションのコンテキスト・ルートの下の受信ファイル・ディレクトリcsa_resultsに格納されますが、アプリケーションのoutputDirコンテキスト・パラメータを変更することで構成できます。
CSAデプロイをテストします。
CSAデプロイをテストするには、CSAページのURLをクリックし、クライアント・データが収集されていることを確認します。
クライアント・システム・アナライザ(CSA)を詳細に構成するには、CSAアプリケーションのWARファイル内のコンテキスト・パラメータを変更します。
表10-2 構成パラメータ
パラメータ | 説明 | デフォルト値 |
---|---|---|
alertWhenDone |
trueに設定した場合、アプレットの実行の完了を示すメッセージが表示されます。 |
false |
appletJAR |
JARファイルの名前。 |
CSA.jar |
application |
このCSAインスタンスに関連付けられたアプリケーションの名前。アプリケーション・パラメータ値を指定しない場合、「収集タグ」の値は「デフォルト」になります。 |
なし |
autoRedir |
JVMがJInitiatorに設定されているが、クライアントに適切なバージョンのJInitiatorがインストールされていない場合、このパラメータをtrueに設定すると、CSA JSPページは自動的にSun JVMを使用します。 |
false |
bwTestFile |
帯域幅テスト中にサーバーからダウンロードされるファイルの名前。 |
CSA.mb (CSAに付属) |
bwTestMsec |
アプレットが帯域幅テストの実行に必要とする時間。アプレットは、この時間中にダウンロード可能なバイト数をカウントすることで、帯域幅を計算します。 |
200ミリ秒 |
classid |
OBJECTタグのclassidフィールド。JVMがJInitiatorに設定されている場合にのみ使用されます。Sunのclassidは、clsid:8AD9C840-044E-11D1-B3E9-00805F499D93コードベースです(OBJECTタグのcodebaseフィールド)。JVMがJInitiatorに設定されている場合にのみ使用されます。 |
なし。JVMをJInitiatorに設定した場合は、このフィールドを設定する必要があります。それ以外の場合、このフィールドは無視されます。 |
codebase |
OBJECTタグのcodebaseフィールド。JVMをJInitiatorに設定した場合のみ、適用可能です。 |
Sunのデフォルトは、http://java.sun.com/products/plugin/autodl/jinstall-1_4_2-windows-i586.cab#Version=1,4,0,0です。 |
collectCookie |
収集されるCookieの名前のリスト。このパラメータは、Cookie名のカンマ区切りリストです。現行ブラウザでの現行OSユーザーのCookieのみが収集されます。管理者は、アスタリスク(*)を指定して、現行ブラウザの現行ユーザーのCookieすべてを収集できます。 |
このフィールドが存在しない場合、Cookieは収集されません。 |
cookieDomain |
CSA Cookieのドメイン。 |
Cookieのドメインまたはパスが設定されていない場合、Cookieは無効になります。 |
cookieMaxAge |
クライアント・マシン上のCookieの最大存続期間(秒)。 |
1年 |
cookiePath |
CSA Cookieのパス。 |
ドメインまたはパスが指定されていない場合、Cookieは無効になります。 |
customClass |
カスタム・データの収集に使用されるクラスの名前。 |
なし。デフォルトの動作では、カスタム・コードの実行はありません。 |
customKey1customKey2customKey3 |
3つのカスタム・キーの値。このデプロイメント・ディスクリプタを使用するCSA JSPページにより実行されるクライアント収集ではすべて、これらの値がカスタム・キーに対応しています。これらの値は、カスタム・コードで上書きできます。 |
カスタム・キーの値を指定しない場合、(カスタム・コードにより収集される場合を除き、)なにも収集されません。 |
descriptionFile |
「デプロイ」ページに表示される説明が入っているテキスト・ファイルのフルパス。このファイルの内容は、HTML形式のテキストである必要があります。 |
なし |
destURL |
宛先のURLを指定します。これは、CSA JSPページ上の「続行」ボタンのリンク先のURLです。 |
destURLを指定しない場合、ユーザーが「続行」ボタンを押すと、参照ページが表示されます。参照ページがない場合、「続行」ボタンは表示されません。 |
destURLResultsParam |
宛先URLに追加される、クライアントのコンプライアンス・レベルを示すURLパラメータの名前を指定します。たとえば、値がcomplianceであり、クライアントの全体的なコンプライアンス・レベルがcriticalである場合、パラメータcompliance=criticalが宛先URLに追加されます。 |
Sun |
JVM |
このパラメータは、使用されるJVMのタイプを決定します。値がSunの場合、JSPページはSun JVMを使用するようにブラウザを設定します。値がOracleの場合、JSPページはOracle Jinitiatorを使用するようにブラウザを設定します。値がanyの場合、JSPページは標準のappletタグを書き出すため、クライアントはブラウザにプラグインされている任意のJVMを使用することになります。 |
Sun |
maxExecInterval |
CSA Cookieペイロードに追加されるパラメータ。リダイレクション・ロジックによりCookieが読み取られるときに、Cookieのタイムスタンプと現在時刻との差がこの値よりも大きい場合、アプレットは再びデプロイされます。このパラメータは、リダイレクションJSPフィルタ内のcsa execIntervalコンテキスト・パラメータで上書きできます。 |
90日 |
maxFileSize |
1つのリクエストでレシーバにポストして戻せる最大データ量(KB)。この制限を超えるサイズのデータがポストされた場合、リクエストは拒否され、ハード・ドライブにすでに書き込まれたデータが削除されます。 |
100 |
maxOutputFiles |
XML OutputDirに存在できる出力ファイルの最大数。 |
100 |
outputDir |
CSAの構成xmlファイルが書き込まれるディレクトリ。アプレット・ページとレシーバ・ページの両方がこのパラメータを読み込む必要があり、どちらのページに対しても同じ値である必要があります。 |
デフォルトでは、出力ファイルはアプリケーション・ルート・ディレクトリのcsa_resultsサブディレクトリに書き込まれます(アプリケーション・ルート・ディレクトリが存在し、かつcsa_resultsサブディレクトリが存在しているか、作成可能な場合)。このパラメータにデフォルト値を使用することはお薦めしません。 |
outputEnabled |
出力XMLファイルの作成を有効または無効にします。アプレット・ページとレシーバ・ページの両方に適用可能です。 |
デフォルトでは、XMLファイルはXMLOutputDir内に作成および格納されます。 |
pluginspage |
Netscapeでは自動インストールがサポートされていないため、NetscapeのユーザーをJVMインストーラにダイレクトするために使用されます。JVMがJinitiatorの場合のみ、適用されます。Sunの場合、デフォルトは |
なし。JVMをJinitiatorに設定した場合は、このフィールドを設定する必要があります。それ以外の場合、このフィールドは無視されます。 |
receiver |
アプレットが収集済データをポストする宛先のURL。 注意: このパラメータを設定する際、管理者はレシーバのバージョンとアプレットのバージョンが同じであることを確認する必要があります。 |
デフォルトでは、CSA JSPページと同じパスでCSAr.jspが検索されます。 |
ruleFile |
評価するルールが含まれるファイルのサーバー上のパスを、Webアプリケーション・ルートを基準にして指定します。 |
rules.xml |
script |
管理者により提供されたスクリプトを指定します。このスクリプトを、管理エージェントによってアップロードのマークが付けられる前のCSA XMLファイルに対して実行できます。 |
なし。スクリプトを指定しない場合、どのスクリプトも実行されません。 |
type |
アプレットをデプロイするためにCSA JSPページによりレンダリングされるOBJECTタグのtypeフィールド。これは、JVMをJinitiatorに設定した場合のみ適用可能です。JVMをSunに設定した場合、typeは |
なし。JVMをJinitiatorに設定した場合は、このフィールドを設定する必要があります。それ以外の場合、このフィールドは無視されます。 |
viewData |
このパラメータをtrueに設定した場合、収集データがサーバーにポストされた後、エンド・ユーザーはそのデータを表示できます。 |
false |
これらのパラメータの他に、CSAリダイレクション・パラメータも構成可能です。リダイレクションを有効にするには、サーブレット・フィルタを使用するか、他のいくつかのページにCSAリダイレクションJSPファイルを追加します。リダイレクションが機能するためには、次のコンテキスト・パラメータが使用可能になっている必要があります。
表10-3 構成パラメータ
パラメータ名 | 説明 | デフォルト値 |
---|---|---|
csaURL |
ユーザーをリダイレクトする宛先CSA JSPページのURL。 |
デフォルトなし。この値を設定しないと、リダイレクションは機能しません。 |
execInterval |
CSAの実行間隔(秒)。Cookieの存続期間と現行サーバー時間の差がexecIntervalより大きい場合、ユーザーはリダイレクトされます。 |
なし。execIntervalを設定しない場合、CSA Cookieが存在する場合のみ、ユーザーはリダイレクトされます。 |
redirectURL |
CSAの実行完了後にユーザーをダイレクトする宛先のURL。 |
なし。 このパラメータを設定しない場合、ユーザーは、最初にリクエストしたページにダイレクトされます。 |
UIMode |
0 - synchronous (現在のブラウザ・ウィンドウ) 1 - asynchronous visible 2 - asynchronous invisible |
synchronous |
異なるアプリケーションに対して、異なるパラメータ・セットが必要となる場合もあります。たとえば、異なるルール・セットおよびカスタム・コードを持つ2つの異なるアプリケーションがあり、管理者がそれらを異なるCSAコレクタ・ターゲットに関連付けるとします。このようなシナリオでは、管理者は、<application name> ruleFileや<application name> appletJarなどのコンテキスト・パラメータを使用して、特定のアプリケーションに対してruleFile、appletJar、scriptおよびoutputDirパラメータを指定することができます。コンテキスト・パラメータとして、またはURLを介してアプリケーションを指定すると、CSAはそのアプリケーションに固有のパラメータ値を使用して実行されます。アプリケーションを指定しない場合、またはアプリケーションのパラメータが1つも上書きされていない場合は、デフォルトのパラメータが使用されます。
システムが特定の制約条件を満たしているかどうかに関する即時のフィードバックをユーザーが受けられるように、CSAアプリケーションにカスタム・ルールを指定できます。例10-1にRULESファイルの例を示し、その後に、ファイル内に含まれる各タグについて説明します。
例10-1 RULESの例
<RULES> <RULE> <NAME>Client has sufficient memory</NAME> <DESCRIPTION>Checks to see if the client has enough memory to run the application</DESCRIPTION> <VIOLATION> //ROWSET[@TABLE='MGMT_ECM_HW']/ROW/AVAIL_MEMORY_SIZE_IN_MB[number() < $arg=SIZE$] </VIOLATION> <SEVERITY level="CRITICAL"> <PARAM id='SIZE'>100</PARAM> <MOREINFO> <TEXT>Application cannot run with less than 100 MB. </TEXT> </MOREINFO> </SEVERITY> <SEVERITY level="WARNING"> <PARAM id='SIZE'>150</PARAM> <MOREINFO> <TEXT>Approaching minimum memory level</TEXT> </MOREINFO> </SEVERITY> </RULE> </RULES>
例10-1は、クライアントにアプリケーションを実行するための十分なメモリーがあるかどうかをチェックするために使用可能なルールを示したものです。<VIOLATION>は、アプレットが、すべての収集済データが含まれたXMLファイルに対して評価するXPATH式です。この違反はXMLファイルに組み込まれたXPATH式であるため、XPATH内の<、>、&などの特定の文字は、実体に置き換える必要があります。XPATH式がNull以外のノード・セットを返す場合、ルールは失敗しています。この例では、クライアントの使用可能メモリーが特定量に満たない場合、ルールは失敗します。違反をトリガーする実際の量は、様々な重大度レベルを使用して構成できます。
表10-4では、アプレットはまずVIOLATION式の部分文字列$arg=SIZE$を100に置き換え、次に式を評価します。クライアントの使用可能なメモリーが100MBより少ない場合、ステータスはcriticalとなりこのルールは失敗します。アプレットは、「Application cannot run with less than 100 MB of memory」というメッセージとともにステータスを表示します。ルールが正常にパスした場合、アプレットは$arg=SIZE$を150に置き換えて再度試行しますが、ルールが失敗した場合、アプレットは、「Approaching minimum memory level」というメッセージを表示します。アプレットが指定したすべての重大度レベルを通過して違反を発見しない場合、ルールは成功です。
表10-4 RULESファイル内のタグ
タグ名 | 説明 |
---|---|
RULES |
これは、XMLファイルの最上位レベルのタグです。 |
BUNDLE |
このタグは、変換に使用するリソース・バンドルを指定します。タグの値は、ファイル名またはJavaクラス名のどちらかです。ルール・エンジンはこの文字列を読み取り、最初にこの名前が含まれるアプレットJAR内でファイルを検索します。このファイルでは、リソースIDが各言語の文字列にマッピングされているとみなされます。そのようなファイルが存在しない場合、文字列はJavaリソース・バンドル・クラスとして扱われます。リソース・バンドル内の文字列は、構文 |
PRECONDITION |
このタグを使用して、ルールを評価するためにNullでないノード・セットを返す必要のあるXPATH式を指定します。id属性は、事前条件のIDを指定します。1つのルールで、評価する必要のある事前条件のリストを、そのIDを列記することにより指定できます。 |
RULE |
このタグは、評価される個々のノードを表します。ルールの重大度は<SEVERITY>タグを使用して指定します。ルールには少なくとも1つのSEVERITYタグを指定する必要があります。このタグにはオプションでprecondition属性を指定できます。この属性には、事前条件IDをカンマで区切って指定します。ルールが評価されるためには、事前条件がすべて満たされる必要があります。事前条件が満たされない場合、ルールのステータスは「Not Applicable」となり、クライアントUIには表示されません。RULEタグの子はNAME、DESCRIPTION、VIOLATION、SEVERITYおよびMOREINFOです。 |
NAME |
このタグはルールの名前を指定し、リポジトリ内のタグを識別します。 注意: このタグは値を含む必要があり、空白にはできません。 |
DESCRIPTION |
これはルールの説明です。 |
VIOLATION |
このタグは、指定されたルールに対してチェックする違反をリストします。違反は「CSA条件の言語」で指定します。 |
SEVERITY |
ルールには、INFO、WARNINGおよびCRITICALの3つの重大度レベルを指定できます。SEVERITYノードには、VIOLATIONノード内の式が使用できる引数と同数の子ARGが含まれている必要があります。ルール・エンジンは、ルールを評価する際、重大度の最も高いCRITICALから順に、重大度レベルで指定された引数セットごとにVIOLATION内の条件を評価します。失敗する条件が検出されるとすぐに、そのルールは失敗が宣言され、ルールの重大度レベルは原因となった引数の重大度レベルと同じになります。指定されたすべてのレベルに対する条件が満たされるている場合、ルールは成功します。 |
PARAM |
このタグは、式に代入される引数の値を指定します。このタグのid属性が、式の中の引数の1つの名前と一致している必要があります。 |
MOREINFO |
このタグは、失敗したルールの隣に表示される「詳細」ボタンをユーザーがクリックしたときに表示される情報を指定します。MOREINFOの子は、TEXTおよびARGです。 注意: MOREINFOノードは、重大度ノードの子(複数の重大度が指定されている場合)か、またはルール自体の子にすることができます。 |
TEXT |
このタグは、「詳細」ボタンがクリックされたときに表示するテキストを指定します。resource属性はリソース・バンドル内の文字列を指定しますが、この文字列がない場合、ノードの値がかわりに表示されます。(リソース・バンドルまたはノード自体の中の)テキストでは、{0}、{1}などを使用して挿入する引数の場所を指定できます。この場合、ARGノード内の式が評価され、指定した順序でテキスト内に挿入されます。文字列内の挿入位置よりも多くのARGノードが指定されている場合、余分なノードは無視されます。 |
ARG |
このタグは、評価してMOREINFOテキストに挿入できる「CSA条件の言語」内の式を指定します。 |
関連項目: 「CSAの開始」ページの詳細は、Enterprise Managerのオンライン・ヘルプ |
管理者は、カスタム・プロパティを収集するためのカスタム・クラスを作成する他に、デプロイメント・ディスクリプタ内にカスタム・プロパティを指定することができます。カスタム・プロパティ名を指定するには、csa value_<name>という形式のコンテキスト・パラメータを含めます。コンテキスト・パラメータ名の<name>フィールドは、クライアント・システム・アナライザ(CSA)によってカスタム・プロパティ名として扱われ、パラメータの値はカスタム・プロパティ値として扱われます。同様に、管理者はパラメータcsa_type_<name>
、csa_type_ui_<name>
、csa_name_ui_<name>
、csa_display_ui_<name>
およびcsa_history_tracking_<name>
を使用して、type、type_ui、name_ui、display_uiおよびhistory_trackingフィールドをそれぞれ指定できます。また、同じネーミング規則を使用して、CSAアプレットURLに対してカスタム・プロパティを指定することもできます。
次の各項では、クライアント構成のユースケースの例を概説します。
管理者は、2つの異なるWebアプリケーションを使用してユーザーの互換性をチェックできます。1つ目は、多数の各種プラグインを使用してコンテンツを配信するオンライン教育Webサイトで、これにより管理者は、必要なプラグインをすべてのユーザーがインストールしていることを確認できます。2つ目はソフトウェアのディストリビューション・ポータルで、これにより管理者は、ポータルからソフトウェアをダウンロードするすべてのユーザーが必要なハードウェアおよびオペレーティング・システムを使用していることを確認できます。この場合、両方のアプリケーションに固有のルール・セットが必要ですが、管理者は次のリストに表示される収集タグを使用することで、両方のアプリケーションに対して1つのCSAインスタンスを使用できます。
teaching、distributionなど、アプリケーションごとに収集タグを選択します。
各アプリケーションに1つずつ、異なる2つのルール・ファイルを作成します。
例10-2に示すように、コンテキスト・パラメータを使用して、各ルール・ファイルを対応するアプリケーションにマップします。
各アプリケーションからCSAへの適切なリンクを作成します。問合せ文字列内で、teachingアプリケーションからのリンクにはapplication=teachingを、distributionアプリケーションからのリンクにはapplication=distributionを含める必要があります。これにより、各アプリケーションのユーザーはCSAの実行時に適切な収集タグを使用できます。
例10-2 ルール・ファイルを選択するための収集タグの使用
<context-param> <param-name>csa teaching ruleFile</param-name> <param-value>teaching_rules.xml</param-value> </context-param> <context-param> <param-name>csa distribution ruleFile</param-name> <param-value>distribution_rules.xml</param-value> </context-param>
例10-2は、ルール・ファイルを選択するための収集タグの使用のみを示しています。しかし、収集タグはどのCSAコンテキスト・パラメータに対しても使用できます。
収集タグは、クライアント構成がEnterprise Manager管理リポジトリに格納される方法にも影響を与えます。ユーザーが例10-2のteachingアプリケーションからのリンクを使用してCSAにアクセスした場合、CSAは収集タグteachingのルールを実行するだけでなく、このタグをクライアント構成データとともに管理リポジトリに格納します。収集タグは、クライアント構成の一意の識別子の一部となるため、1つのクライアントが管理リポジトリ内に、それぞれ固有のタグを含む複数の構成を持つことが可能になります。クライアント・データへのアクセスを制限するために、収集タグをEnterprise Managerターゲットに関連付けることができますが、Enterprise Managerユーザーがクライアント構成の収集タグに関連付けられたターゲットに対する表示権限を持つ場合は、そのクライアント構成の表示のみが可能です。
たとえば例10-2で、teachingアプリケーションのホスティングにホストH1、アプリケーション・サーバーA1およびデータベースD1が使用され、distributionアプリケーションにホストH2、アプリケーション・サーバーA2およびデータベースD2が使用されるとします。6つのターゲットはすべてEnterprise Managerにより監視されており、ユーザーXはA1、H1およびD1へのアクセス権を、ユーザーYはA2、H2およびD2へのアクセス権を持っています。2人のEnterprise Managerユーザーそれぞれが、アプリケーションの1つに使用されるリソースを監視しているため、各ユーザーがそのアプリケーションのクライアントも監視していると考えられます。その場合、Enterprise Managerのスーパーユーザーは、teachingタグをA1、D1またはH1に関連付け、distributionタグをA2、D2またはH2に関連付けます。これにより、ユーザーXはteachingタグを持つすべてのクライアント構成を表示でき、ユーザーYはdistributionタグを持つすべての構成を表示できます。
Enterprise Managerでクライアント・データへのアクセスを制限するには、収集タグを使用します。ユーザーが表示権限を持つターゲットにクライアント構成の収集タグが関連付けられている場合のみ、ユーザーはそのクライアント構成を表示できます。たとえば、収集タグCがターゲットT1と関連付けられている場合、ターゲットT1を表示できるユーザーのみが、タグXを持つクライアント構成を表示できます。例10-2では、ユーザーXはteachingタグに関連付けられたターゲットに対する表示権限を持つため、teachingタグを持つクライアント構成を表示できます。ただし、distributionタグは、ユーザーXが表示できるどのターゲットにも関連付けられていないため、ユーザーXはndistributionタグを持つクライアント構成を表示できません。スーパーユーザーは、「収集タグ・アソシエーション」ページ(「デプロイ」タブ、または「設定」ページの「Cloud Controlのクライアント・システム・アナライザ」リンクからアクセスできます)を使用して、収集タグをターゲットに関連付けることができます。スーパーユーザーは、収集タグの関連付けの内容に関係なく、すべてのクライアント構成を表示できます。
通常のCSAデータ以外に電子メール・クライアントのユーザー設定も行う必要のある管理者は、例10-3に示すように、カスタマイズAPIを使用することにより、このデータをCSAにより収集された他のデータに追加できます。
情報の収集に必要なJavaクラスを作成します。管理者は必要な数のクラスをいくつでも作成できますが、少なくとも、oracle.symsan.eml.ecm.csa.CSAResultInterface
を実装する1つのクラスと、oracle.sysman.eml.ecm.csa.CSACustomInteface
を実装する1つのクラスが必要です(どちらのクラスも、例10-3に示されています)。前者はacme.csa.custom、後者はacme.csa.resultとしています。
CSA内のcustomClassパラメータの値をacme.csa.customに設定します。
例10-3 カスタマイズAPI
public interface CSACustomInterface { /** * requires: none * effects: returns a CSAResultInterface object that may contain custom * properties. Other effects are determined by the customActions method * in the implementing class * modifies: unknown - dependent on implementing class. * @param inputData contains client config data collected by default, plus * applet parameters, etc.None of the data in the inputData is guaranteed * to be there as there could have been collection errors. * @return a data structure that may contain custom properties */ CSAResultInterface customActions(CSAInputInterface inputData); } public interface CSAResultInterface { /** * requires: none * effects: returns an array of custom properties * modifies:none * @return String[][7] where ... * * String[i][0] is a name * String[i][1] is a value of the i-th row. (Type and name must be unique.) * String[i][2] is a type/category of data (could be null), * String[i][3] is the displayed value of the name of the property * String[i][4] is the displayed value of the type of the property * String[i][5] indicates data item (ie "Y") whose history should be computed * String[i][6] indicates data item (ie "Y") should be displayed in default UI */ String[][] getResultsData(); } public interface CSAInputInterface { /** * Get data value for given name * requires: name is not null * effects: returns the data value associated with the name * modifies: none * @param name the name of the key whose value is to be returned * @return the value assocaited with name * */ String getDataValue(String name); /** * Get table-formatted data. * requires: name is not null * effects: returns the table with this name * modifies: none * @param name the name of the table * @return the rows of the child tables * */ CSAInputInterface[] getDataTable(String name); }
カスタム・コードにより収集された追加データは、表MGMT_ECM_CSA_CUSTOMに格納されます。カスタム・コードは、データをこの表に追加するために、CSAResultInterfaceを実装するオブジェクト内にデータを返します。また、アプレットによりcustomActionsメソッドに渡されるCSAInputInterfaceオブジェクトを変更することで、CSAによって収集された標準のデータを操作できます。
カスタム・コードはルールの評価前に実行されるため、管理者はカスタム・データに基づくルールを記述することもできます。管理者が、適切なIMAPサーバーでユーザーの電子メール・クライアントが設定されていない場合にクリティカル・エラーが発生するようなルールを記述する場合は、IMAPサーバーの設定を取り出してMGMT_ECM_CSA_CUSTOM表に格納するカスタム・コードを記述してから、これらの値をチェックするルールを記述します。
CSAはユーザーのマシン上での管理エージェントの使用には関与しないため、管理リポジトリ内のデータを最新の状態に保つには、エンド・ユーザーがCSAを定期的に実行するしかありません。これを確実に行うために、ユーザーがCSAを最近実行したかどうかをチェックし、実行していなければCSAを再び実行するようユーザーに通知するという方法があります。このチェックは、Oracleが提供するCSAサーブレット・フィルタを使用して実施できます。
CSAサーブレット・フィルタは、ユーザーのブラウザが実行されるたびに、CSAで設定されたCookieをチェックします。このCookieのペイロードにより、CSAの最後の実行時刻が示されます。このフィルタを使用するには、管理者が、頻繁にアクセスされるアプリケーション(業員ポータルなど)の前に配置します。次に、ユーザーがCSAを実行する間隔を設定します。ユーザーがポータル・アプリケーションへの接続を試行するたびに、フィルタがそのリクエストを遮断し、CSA Cookieをチェックします。Cookieが存在しない場合や、管理者が指定した実行間隔を超過している場合、ユーザーはCSAページにダイレクトされ、それ以外の場合、ユーザーはアプリケーションへの接続を許可されます。
たとえば、Acme CorporationのCSAインスタンスがwww.acme.com/csa/CSA.jspにデプロイされているとします。また、この会社のポータルがwww.acme.com/portalにあり、従業員はこのポータルを使用して電子メールのチェック、個人情報へのアクセス、または会社に関連するニュースを表示できるとします。ポータルは従業員によって頻繁にアクセスされるため、Acmeの管理者は、CSAデータを最新の状態に保つためにこのポータルを使用することにします。この場合、管理者は次の手順を実行します。
CSAサーブレット・フィルタ・クラスをダウンロードします。これらのクラスはJARファイルのCSA_filter.jar(Enterprise Manager Cloud Controlコンソールの「クライアント・システム・アナライザ・アプリケーションのデプロイ」ページからダウンロードできます)に含まれています。
JARファイルを、フィルタを適用するアプリケーションのWEB-INF/libディレクトリ内に置きます。
フィルタのコンテキスト・パラメータを指定します。ここでは、管理者が30日に1回ユーザーにCSAを実行させ、CSAの完了後にユーザーをポータルのホームページに戻すとします。
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param>
バックグラウンドの別個のブラウザ・ウィンドウ内でCSAを実行する方法もあります。これを設定するには、csa_uiModeパラメータを使用します。このパラメータを1に設定した場合、フィルタは最初のウィンドウと同じサイズの新しいブラウザ・ウィンドウを開き、CSAページに移動します。パラメータを2に設定した場合、CSAは不可視モードで実行され、この場合、フィルタは新しいブラウザ・ウィンドウを開くとすぐに最小化し、CSAが完了すると同時にウィンドウを閉じます。
次のデプロイ例では、主要な3つの要素が登場します。1つ目は、CSAの設定を行うCSA管理者です。2つ目は、Enterprise Managerでクライアント・データを表示するEnterprise Managerユーザーです。3つ目は、データがCSAにより収集されるエンド・ユーザーです。
この例では、CSA管理者はCSAを使用してヘルプデスクの業務をサポートしています。特定のアプリケーションの実行で問題が発生すると、エンド・ユーザーはカスタマ・サポートをコールし、カスタマ・サポートの技術担当者は、必要に応じて、特定のURLにアクセスしてCSAを実行するようにユーザーに指示できます。Enterprise Managerユーザーは、CSAにより収集されたデータを使用してエンド・ユーザーをアシストするサポート担当者です。顧客の問題を診断するプロセスの時間を短縮するため、CSA管理者は、考えられる問題をヘルプデスク担当者が素早く特定できるよう、rules.xmlというファイル内にいくつかのルールを作成します。最も単純な例として、1つのアプリケーションのサポートを行うヘルプデスクを設置するとします。アプリケーションは、ホストapplication.acme.com上のアプリケーション・サーバーで実行されています(このホストにはEnterprise Managerの管理エージェントがインストールされており、oms.acme.com/emにある管理サービスにデータを戻します)。クライアント・データを確認しようとするヘルプデスク担当者は、ユーザーhelpdeskとしてEnterprise Managerにログインできますが、スーパーユーザー権限はありません。
CSA管理者は、CSA.earに含まれているCSA.warファイルにrules.xmlを追加します。
Application Services Controlコンソールを使用して、EARファイルをアプリケーション・サーバーにデプロイします。
Application Services Controlコンソールを使用して、ruleFileやoutputDirなどの必要なコンテキスト・パラメータを設定します。
オプションで、管理者は、applicationコンテキスト・パラメータの値を指定してCSAデータの収集タグを選択できます。タグを選択しない場合、タグDefaultが使用されます。
スーパーユーザー権限を持つEnterprise Managerユーザーは、application.acme.comにある管理エージェントにCSAコレクタ・ターゲットを追加し、その受信ファイル・ディレクトリを、CSAのoutputDirパラメータで指定されているディレクトリに設定します。
Enterprise Managerスーパーユーザーは、helpdeskユーザーにデータの参照を許可するために必要な収集タグの関連付けを作成します。たとえば、スーパーユーザーはタグDefaultをホストapplication.acme.comに関連付け、そのホストに対する表示権限をhelpdeskというEnterprise Managerユーザーに付与します。
前述の設定では、ユーザーがヘルプデスクをコールしてアプリケーションのサポートを依頼すると、ヘルプデスクの技術担当者は、application.acme.comにある適切なURLからCSAを実行するようにユーザーに指示できます。管理エージェントは、一定時間の経過後にデータを収集し、そのデータを管理リポジトリにロードします。ヘルプデスクの技術担当者は、helpdeskとしてEnterprise Managerにログインし、顧客のオペレーティング・システム・ユーザー名やホスト名などの識別フィールドを検索して顧客情報を見つけることができます。デフォルトでは、管理エージェントは2分ごとに出力ディレクトリの新しいデータをチェックしますが、$ORACLE_HOME/sysman/admin/default_collection/oracle_csa_collector.xmlファイルを編集することで、この時間間隔を短くできます。
例10-4では、システム管理者が、人事管理(HR)部と販売部の2つの部署の従業員が使用するハードウェアおよびソフトウェアを監視します。この管理者は、Enterprise Managerユーザーでもあり、CSA管理者でもあります。この例の設定は、サーブレット・フィルタの使用例で説明した設定と似ていますが、ここでは、各部署がそれぞれのポータル・アプリケーションをhr.acme.com/portalおよびsales.acme.com/portalに置いています。管理者はホストserver1.acme.com上にアプリケーション・サーバーを設定し、URL http://server1.acme.com/csa/CSA.jspを使用してCSAをデプロイします。server1.acme.comの管理エージェントは、データを収集し、oms.acme.com/emのOracle Management Serviceに送信します。管理者は30日に1回データを収集し、不可視モードでCSAを実行しようとしています。また、2つの異なる部署のデータを、hrおよびsalesという異なる収集タグを使用して区別しようとしています。管理者は、sysmanとしてEnterprise Managerにログインできるため、両方のタグを持つクライアントを表示できます。
管理者は、両方のアプリケーションにCSAサーブレット・フィルタをデプロイすることによって、ユーザーがCSAにダイレクトされるように調整します。2つのアプリケーションのフィルタ・コンテキスト・パラメータの大部分は同じです。ただし、各アプリケーションは別々のタグに対応しているため、csa csaURLパラメータの値は少し異なります。HRポータルの値はhttp://server1.acme.com/csa/CSA.jsp?application=hrであり、販売ポータルの値はhttp://server1.acme.com/csa/CSA.jsp?application=salesです。
例10-4 インベントリ・コード
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param> <context-param> <param-name>csa uiMode</param-name> <param-value>2</param-value> </context-param>
この設定では、HRポータルからCSAにダイレクトされるHR部のユーザーはタグhrを持ち、販売部のユーザーはタグsalesを持ちます。このため、管理者がHR部のマシン上のハードウェアのみの情報を表示しようとする場合には、Enterprise Managerで「クライアント構成」ページの「収集タグ」フィルタを使用し、単にこれをhrに設定します。
この例では、CSAを使用して、アプリケーションの実行中に発生する可能性のある問題をエンド・ユーザーに通知することが目標です。設定は、例2で使用した設定と似ています。この例では、CSA管理者はアプリケーションごとにルールを作成します。また管理者は、発生する可能性のある問題をエンド・ユーザーが確認できるように、最初のブラウザ・ウィンドウ内でCSAを実行することにしています。
例10-5は、販売ポータル上のCSAサーブレット・フィルタのコンテキスト・パラメータ値を示しています。
例10-5 CSAサーブレット・フィルタのコンテキスト・パラメータ値
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param> <context-param> <param-name>csa uiMode</param-name> <param-value>0</param-value> </context-param>
例10-6は、ルールを収集タグにマップするためのコンテキスト・パラメータ定義を示しています。
権限委譲プロバイダとは、別のユーザーの権限を使用してアクティビティを実行することをログイン・ユーザーに許可するプログラムのことです。通常、特定のユーザーに付与される権限は、集中管理されます。
Enterprise Managerの優先資格証明を使用すると、次の2つのタイプの権限委譲プロバイダを使用できます。
sudoの場合、許可されているユーザーは、sudoユーザー管理ファイル(sudoers)で指定されているsuperユーザーまたは他のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。
注意: デフォルト構成の場合、これは該当ユーザーのパスワードであり、rootのパスワードではありません。 |
sudoでは、ユーザーに権限が付与されているかどうかは、/etc/sudoersファイルをチェックして判断されます。ユーザーが認証されると、タイムスタンプが更新され、該当ユーザーはパスワードなしで短期間(sudoersファイル内で上書きされないかぎり5分間)sudoを使用することができます。
Symark PowerBrokerの場合、UNIXのシステム管理者は、root (または他の重要なアカウント)として特定のプログラムを他のユーザーが実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。これにより、rootの権限全体を誤用や乱用から保護できます。たとえば、データベースやファイルの権限の変更、ディスクの消去です。
Symark PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスすることができます。Symark PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理することができます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスすることができます。
sudoおよびPowerBrokerの詳細は、各製品のドキュメントを参照してください。
Enterprise Managerのコマンドライン・インタフェース(EM CLI)を使用すると、ホストの権限委任プロバイダ・プロパティの設定や編集を実行できます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。設定および構成の詳細は、権限委譲プロバイダに関するドキュメントを参照してください。
権限委譲設定は、Enterprise Manager CLIコマンドライン・インタフェースのcreate_privilege_delegation_setting動詞を使用して作成できます。
また、権限委任設定を使用したホストの構成、権限委任設定テンプレートの適用、または権限委任設定の構成解除を行うには、Enterprise Managerのホームページで「設定」、「セキュリティ」の順に選択し、左側のメニュー・パネルから「権限委任」を選択します。
EM CLIのcreate_privilege_delegation_setting動詞を使用すると、sudo権限委任設定を作成できます。明示的な構文および例については、EM CLIのコマンドライン・ヘルプまたは『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
変数
EM CLIを使用して権限委任設定を設定する際は、次の変数を使用できます。変数では大文字と小文字が区別されます。
変数 | 定義 |
---|---|
%RUNAS% | コマンドを実行するユーザー。 |
%USERNAME% | コマンドを実行するユーザーの名前。 |
%COMMAND% | sudoコマンド |
構文
emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS:<command to be used with all the options>"
次の例は、EM CLIを使用してsudo設定を作成する方法を示しています。この場合、sudoは/opt/sudo/binにインストールされています。
EM CLIのcreate_privilege_delegation_setting動詞を使用すると、PowerBroker権限委譲設定を作成できます。
変数
EM CLIを使用して権限委任設定を設定する際は、次の変数を使用できます。変数では大文字と小文字が区別されます。
変数 | 定義 |
---|---|
%RUNAS% | コマンドを実行するユーザー。 |
%USERNAME% | コマンドを実行するユーザーの名前。 |
%COMMAND% | sudoコマンド |
%PROFILE% | コマンドの実行に使用するプロファイル。 |
構文
>emcli create_privilege_delegation_setting -setting_name=powerbroker_setting_1 -setting_type=POWERBROKER -settings="SETTINGS:<command to be used with all the options>;[PASSWORD_PROMPT_STRING,<password prompt for PowerBroker>]"
例10-8 EM CLIを使用したsudo設定の作成
./emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS: /opt/powerbroker/bin/pbrun –u %RUNAS% %command%"
注意: この例の場合、PowerBrokerは/opt/powerbrokerディレクトリにインストールされており、そのパスワード・プロンプトは"Password:"です。 |
権限委譲設定は、作成し終わったら、選択したターゲットに適用する必要があります。権限委任設定の作成プロセスの場合と同様に、EM CLIを使用して、指定したターゲットに権限委任設定を適用できます。この設定は、1つまたは複数のホスト、あるいはコンポジット(グループ)ターゲット(グループには、ホスト・ターゲットが1つ以上含まれていること)に適用できます。
Cloud Controlコンソールを使用して、権限委任設定を適用することもできます。Enterprise Managerのホームページで「設定」を選択し、左側のメニュー・パネルから「権限委任設定の管理」を選択します。
EM CLIのapply_privilege_delegation_setting動詞を使用すると、権限委任設定をホスト・ターゲットに適用できます。
構文
emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=host -target_names="host1;host2;..." -input_file="FILE:hosts.txt" -force="yes/no
"
権限委譲プロパティを多数のホストに適用する場合は、次の例のように、-target_namesオプションのかわりに-input_fileオプションを使用して、すべてのホストが含まれるファイルを指定することができます。
EM CLIのapply_privilege_delegation_setting動詞を使用すると、権限委任設定をコンポジット(グループ)ターゲットに適用できます。
構文
emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=composite -target_names="group" -force="yes/no"
例10-10 EM CLIを使用したコンポジット・ターゲットへの権限委任設定の適用
./emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=composite -input_file="FILE: /mydirectory/file.txt" -force=yes
ホスト・ターゲットに対する権限委任設定の適用に成功したら、EM CLIまたはCloud Controlコンソールを使用して、ホスト・ターゲットの優先資格証明を設定できます。
管理者は、権限委譲設定を無効にするために、ステータスが無効な新しい権限委譲設定を作成してターゲットに適用できます。この無効な設定は、任意の権限委譲プロバイダ(sudo/PowerBroker)に適用できます。これにより、設定をホストから削除できます。
新しい権限委譲設定を作成します。
./emcli create_privilege_delegation_setting -setting_name= disabled_setting -setting_type=SUDO –disabled=yes
新しい設定を1つまたは複数のターゲットに適用します。
./emcli apply_privilege_delegation_setting -setting_name= disabled_setting -target_type=host -target_names="host1;host2;..." -force=yes
Enterprise Managerで使用する信頼ベースのモデルでは、高度の粒度で職責を指定できます。管理者は、sudoまたはpbrunの構成エントリを設定し、Enterprise Managerの特定機能の権限をそのOSユーザーに割り当てることができます。管理エージェントには、nmosudoという新しい実行可能ファイルが導入されています。管理者は、sudo/pbrunを構成することにより、権限の低いユーザーが権限の高いユーザーとしてnmosudoを実行できないようにすることができます。
次の例で、管理者がユーザーjoeに任意のEnterprise Managerジョブをユーザーoracleとして実行させる場合、/etc/sudoersファイル内の対応するエントリは次のようになります。
(JOB_USERS) ALL : (RUNAS_USERS) AGENT_HOME /bin/nmosudo *
ここで、joeはJOB_BACKUP_USERSリストの中、oracleはRUNAS_USERSリストの中にあります。
Enterprise Managerにより、実行可能ファイルnmosudoは、OMSから管理エージェントを介したリモート操作実行要求のみを受け取ることが保証されます。nmosudoは、要求が管理エージェントからのものであることを検証できないと、該当するリモート操作を実行しません。そのため、前述の例で示したように、ユーザーjoeがnmosudoをコマンドラインから直接起動し、ユーザーoracleとしてPerlスクリプトを実行することはできません。
注意: システムのセキュリティを確保するために、管理者は実行可能ファイルnmosudoに対するフルパスを設定する必要があります。 |
Enterprise Manager Cloud Controlコンソールでは、ユーザー・インタフェースにより提供される機能を介して、権限委譲プロバイダを構成できます。Cloud Controlを使用すると、コマンドライン・インタフェースを使用しなくても、それと同等の機能を実行できます。
次の各項では、Cloud Controlインタフェースを使用して実行できる機能について説明します。
Enterprise ManagerでCloud Controlコンソールを使用して、sudo設定を作成できます。権限委譲設定を作成するには、ホスト・ターゲットに設定を直接作成するか、または複数のホストに適用できるPDP設定テンプレートを作成します。
権限委譲sudo設定をホストに直接作成するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。「設定」メニューから「管理」を選択し、「権限委任設定」を選択します。
この表に表示されているいずれかのホスト・ターゲットに対して、「編集」をクリックします。Enterprise Managerで「ホスト権限委任設定」ページが表示されます。
「sudo」権限委譲タイプを選択します。
使用する権限委譲コマンドを入力します。
「更新」をクリックし、設定をホストに適用します。
注意: ホストがsudoかPowerbrokerのいずれかの設定で構成されている場合、このページで「なし」を選択すると、設定が削除(無効化)されます。 |
権限委譲設定を作成するには、ホスト・ターゲットに設定を直接作成するか、または複数のホストに適用できるPDP設定テンプレートを作成します。
権限委譲PowerBroker設定をホストに直接作成するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。「設定」メニューから「管理」を選択し、「権限委任設定の管理」を選択します。
この表に表示されているいずれかのホスト・ターゲットに対して、「編集」をクリックします。Enterprise Managerで「ホスト権限委任設定」ページが表示されます。
「PowerBroker」権限委譲タイプを選択します。
使用する権限委譲コマンドと、オプションのパスワード・プロンプトを入力します。
「更新」をクリックし、設定をホストに適用します。
注意: ホストがsudoかPowerbrokerのいずれかの設定で構成されている場合、このページで「なし」を選択すると、設定が削除(無効化)されます。 |
権限委譲設定テンプレートを使用して、権限委譲設定をターゲットに適用します。目的の権限委譲設定を持つテンプレートが存在しない場合は、まず、「権限委任設定テンプレートの管理」ページでテンプレートを作成する必要があります。
テンプレートを作成するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。「設定」メニューから「管理」を選択し、「権限委任設定の管理」を選択します。
「関連リンク」セクションで「権限委任設定テンプレートの管理」をクリックします。
権限委任タイプ(SudoまたはPowerBroker)を選択して、「実行」をクリックします。
権限委任設定の必須情報を入力します。
「保存」をクリックします。
目的の権限委譲設定テンプレートがすでに存在する場合は、そのテンプレートを目的のホストに適用するだけです。テンプレートをホストに適用するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。「設定」メニューから「管理」を選択し、「権限委任設定の管理」を選択します。
「適用」ドロップダウン・メニューから必要な権限委任設定テンプレートを選択します。
「実行」クリックして、設定の適用ページにアクセスします。
権限委任設定テンプレートを適用するターゲット(ホスト)を追加します。
「適用」をクリックします。「過去の適用操作」ページが表示され、スケジュール済の適用操作のキューとスケジュール済/保留中の操作を確認できます。このページでは適用操作を 停止または削除できます。
権限委任設定テンプレートの管理ページから権限委任設定に適用することもできます。
Cloud Controlコンソールを使用して、権限委譲設定を無効にできます。この方法を使用して権限委譲設定を無効化するには、次の手順を実行します。
「設定」をクリックして、「Enterprise Manager構成」ページにアクセスします。
左側のメニューから「権限委任設定の管理」をクリックします。
「権限委任設定の管理」ページが表示されます。
権限委任設定をクリアするホストを選択します。
「クリア」をクリックします。権限設定の無効操作を終了するかどうかが確認されます。
「はい」をクリックします。
OMSがインストールされているホストのIPアドレスを変更した場合、そのIPアドレスを考慮してOMSを再構成します。次の手順を実行します。
OMSを再構成するには、次の手順を実行します。
すべてのOMSインスタンスを停止します。
$<OMS_HOME>/bin/emctl stop oms -all
ホストのオペレーティング・システムおよびネットワークで、ホストのネットワーク構成を変更します(例: DNSの再構成)。
注意: クライアント側(管理エージェントおよびブラウザ)でDNSキャッシュの問題が発生する可能性があるので注意してください。DNSの構成方法によって、OMSホスト・ネットワーク定義での変更はネットワーク全体に伝播するまで時間がかかる場合があります。多くの場合、OMSホストのIPアドレスの変更は簡単ですが、OMSホストのHOSTNAME定義を変更する場合は、『Oracle Enterprise Manager Cloud Control管理者ガイド』で説明するとおり、バックアップおよびリカバリ・オプションの再インストールまたは設定が必要です。 |
すべてのOMSインスタンスを開始します。
$<OMS_HOME>/bin>/emctl start oms
注意: OMSインスタンスの起動後、OMSホスト上で実行しているすべてのWebLogicまたはFusion Middlewareターゲットが、Enterprise Manager Cloud Controlコンソール内で停止しているように表示される場合があります。この問題を解決するには、次の手順で説明するとおりWebLogicドメインをリフレッシュする必要があります。 |
WebLogicドメインをリフレッシュするには、次の手順を実行します。
Enterprise Manager Cloud Controlコンソールにログインします。
「ターゲット」メニューから、「ミドルウェア」を選択します。
「検索」セクションの「ミドルウェア」ページにある、「領域」リストで、「すべて」を選択して、「検索」をクリックします。
すべてのミドルウェア・ターゲットが表示されている表で、EMGC_GCDomainを展開します。
「GCDomain」を右クリックして、「WebLogicドメインのリフレッシュ」を選択します。
「WebLogicドメインのリフレッシュ」ページで、「ターゲットの追加/更新」をクリックします。「確認」ダイアログで「「閉じる」」をクリックします。
「WebLogicドメインのリフレッシュ: エージェントの割当て」ページで、「ターゲットの追加」をクリックします。「確認」ダイアログで「「閉じる」」をクリックします。
「WebLogicドメインのリフレッシュ: 結果」ページで「OK」をクリックします。