リソースの発見とプロモーション

ホスト名の前提条件

hostname -dコマンドがドメイン名を返すか、hostname -aコマンドが正しい短縮名を最初の別名として返すことを確認します。短縮名は、検出するデータベースのv$instances表のHOST_NAME列に表示されます。これを行うには、/etc/hostsファイルを更新して、前述のとおり正しい別名を最初の別名として戻します。

エージェントの前提条件

• Oracle Databaseクラスタの各ノードには、ローカルにインストールされた管理エージェントが必要です。

• lsnrctl、srvctlおよびcrsctlコマンドを実行できるように、インストールされたエージェントのタイプに基づいてmgmt_agentまたはoracle-cloud-agentユーザーが、/etc/oraInst.locから取得されたOracle Inventoryグループ(通常はoinstall)に含まれていることを確認します。

  次の手順を使用して、インストールされているエージェントのタイプに基づいて、oinstall権限をmgmt_agentまたはoracle-cloud-agentユーザーに付与します。

  • Oracle Cloud Agentを使用するホスト:

    usermod -aG oinstall oracle-cloud-agent

  • スタンドアロン・エージェントがあるホスト:

    usermod -aG oinstall mgmt_agent

• グループには、Oracleインストール・ディレクトリに対する実行権限が必要です。

  グループ実行権限をディレクトリに追加する例:

  chmod g+x /u01/app/oracle

OS権限を付与したら、次の手順を使用してエージェントを再起動します。エージェントとOSの適切な手順をそれぞれ使用します。

• Oracle Cloud Agent:

  sudo systemctl stop oracle-cloud-agent

  その後、startコマンドを使用してエージェントを起動します。

• スタンドアロン・エージェント

  sudo systemctl stop mgmt_agent

  その後、startコマンドを使用してエージェントを起動します。

モニタリング資格証明の前提条件

スタック・モニタリング内でデータベースを検出する前に、モニタリング・ユーザーにアクセスできることを確認してください。Oracle Databaseに組み込まれており、データベースの監視に必要な権限を持っているDBSNMPユーザーを使用するか、必要な権限のみを持つカスタム・ユーザーを作成できます。データベース・モニタリング・ユーザーを作成するステップは、CMOSノートKB57458を参照してください。

ASMの場合:

• ASMSNMPユーザープロファイルまたはその権限を使用する必要があります。
• ユーザーはASMのシークレット・パスワードが必要です。シークレットの作成を開始するには、シークレットの管理を参照してください。

TCPS対応のOracle Database前提条件

Stack Monitoringは、OracleデータベースのTCP接続プロトコルとTCPS接続プロトコルの両方をサポートします。TCPSプロトコルにより、クライアント上のOracleアプリケーションは、TCP/IPおよびSSLを介してリモート・データベースと通信できます(これにより、TCPのみよりも高いセキュリティが提供されます)。この新しいリスナーは、セキュアなチャネルを介してデータベースと通信するために使用できます。TCPSを使用してデータベースを検出するには、次の4つのステップに示すように、前提条件としてTCPSリスナーをOracleデータベースに追加し、ウォレットの場所にアクセスする必要があります。

ステップ1: TCPSをサポートするためのOracle Databaseおよびリスナーの構成については、Transport Layer Security認証の構成を参照してください。

ステップ2: KeyStore/TrustStoreを管理エージェントにインポートし、その権限を更新します。

1. 使用されるKeyStoreタイプ(PKCSまたはJKS)に従って、Oracle Databaseウォレットの場所を識別およびエクスポートします。

   PKCS

   export WALLET_LOCATION=<database_wallet_location>/dbwallets

   JKS

   export WALLET_LOCATION=<database_wallet_location>/jkswallets

2. エージェント・ホスト上のセキュアで読取り可能なディレクトリにウォレットをコピーします。

   cp -r $WALLET_LOCATION <secure_readable_dir>/

3. ウォレット権限を更新します。

   OCIコンピュート上

   PKCS

   sudo chown -R oracle-cloud-agent:oracle-cloud-agent <secure_readable_dir>/dbwallets

   JKS

   sudo chown -R oracle-cloud-agent:oracle-cloud-agent <secure_readable_dir>/jkswallets

   オンプレミス・コンピュート:

   PKCS

   sudo chown -R mgmt_agent:mgmt_agent <secure_readable_dir>/dbwallets

   JKS

   sudo chown -R mgmt_agent:mgmt_agent <secure_readable_dir>/jkswallets

ステップ3: OCI Secretを作成します。

シークレットの作成を開始するには、シークレットの管理を参照してください。

シークレットの例:

PKCS

{
    "sslTrustStoreType": "PKCS12",
    "sslTrustStoreLocation": "/<secure_readable_dir>/dbwallets/cwallets/ewallet.p12",
    "sslTrustStorePassword": "<truststore_password>",
    "sslKeyStoreType": "PKCS12",
    "sslKeyStoreLocation": "/<secure_readable_dir>/dbwallets/swallets/ewallet.p12",
    "sslKeyStorePassword": "<truststore_password>",
    "sslServerCertDn": "C=US,O=MyCorp,CN=sslclient"
}

JKS

{
    "sslTrustStoreType": "JKS",
    "sslTrustStoreLocation": "/<secure_readable_dir>/jkswallets/truststore.jks",
    "sslTrustStorePassword": "<truststore_password>",
    "sslKeyStoreType": "JKS",
    "sslKeyStoreLocation": "/<secure_readable_dir>/jkswallets/keystore.jks",
    "sslKeyStorePassword": "<truststore_password>",
    "sslServerCertDn": "C=US,O=MyCorp,CN=sslclient"
}

ステップ4: ポリシーの検証

シークレットの作成に加えて、スタック・モニタリング管理グループには、シークレットが保持されているボールトを読み取る機能が付与されている必要があります。指定したコンパートメント内のシークレット・ファミリに対する読取り権限の付与の詳細は、必要なポリシーの作成を参照してください。

Oracle Databaseで古いパスワード・バージョンを使用している場合

特定のE-Business Suiteデータベースなど、12未満のパスワード・バージョン(SQLNET.ALLOWED_LOGON_VERSION < 12)を使用するように構成されているデータベースの場合、エージェント構成で適切なSQLNET.ALLOWED_LOGON_VERSION値を設定して、古いパスワード・バージョンを使用してデータベースと通信するように管理エージェントを構成するには、次の追加ステップに従います。

次の手順は、オンプレミスで実行されているエージェントに適用されます。

1. このファイル/opt/oracle/mgmt_agent/agent_inst/config/emd.propertiesを変更して、プロパティを追加します。

   dbaas.ALLOWED_LOGON_VERSION = 8 

   必要なログイン・バージョンに応じて、8 / 10 / 11 /12 / 12aの値を指定できます。

2. エージェントを再起動します。

   sudo systemctl restart mgmt_agent

次の手順は、OCI Computeで実行されているエージェントに適用されます。

1. ファイル/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/config/emd.propertiesを変更して、次のプロパティを追加します。

   dbaas.ALLOWED_LOGON_VERSION = 8

   必要なログイン・バージョンに応じて、8 / 10 / 11 /12 / 12aの値を指定できます。

2. エージェントを再起動します。

   sudo systemctl restart oracle-cloud-agent

Oracle Databaseの検出手順

• Oracle Databaseがすでに検出されている場合のDB Systemの検出
• 検出入力
  • UI検出入力
  • CLI検出入力

Oracle Databaseがすでに検出されている場合のDB Systemの検出

1. クラスタの最初のDB SystemのUI検出:

   「リソース検出」ページで、空白のOracle Database検出を完了します。

   UI検出入力の詳細は、「UI検出入力」表を参照してください。

2. 残りのDB SystemリソースのCLI検出:

   ノート
   
   すでに検出されているOracle Databaseの場合は、次のステップを実行して、関連するDB Systemを検出します。
   1. 新しく作成したOracle Databaseホームページ内の「構成」タブに移動します。次のフィールドを「一般的なOCIプロパティ」表からノートパッドにコピーします:

      プロパティー名	CLI変数名	ノート
      OCID	<Database_Resource_OCID>
      compartmentId	<Compartment_OCID>
      managementAgentId	<Additional_Agent#_OCID>	これは、CLI検出時に使用されるエージェントのOCIDです。

   2. Oracle Databaseリソースの名前を「スタック・モニタリングOracle Database」ホームページの上部からコピーします。
   3. クラスタ内の他のノードの管理エージェントOCIDを取得します。

      1. 「監視および管理」にナビゲートし、「管理エージェント」に移動して、「エージェント」をクリックします。

      2. DB Systemクラスタ内の追加のエージェントごとに、アクション・メニューを選択します。
      3. 「OCIDをクリップ・ボードにコピー」を選択します。

         エージェントOCID	CLI変数名
         クラスタ内の最初の追加ノード	<Additional_Agent1_OCID>
         クラスタ内の2番目の追加ノード(など)	<Additional_Agent2_OCID>

   4. 取得した値でJSON_INPUT_FILEを更新し、次の構文を使用してOracle DBシステムを検出します。

      oci stack-monitoring discovery-job create --compartment-id "<Compartment_ID>" --from-json file://<JSON_INPUT_FILE>

   CLI検出入力の詳細は、CLI検出入力の表を参照してください。

   次に、残りのDB Systemリソースを検出するJSONペイロードの例を示します:

   {
     "discoveryType": "REFRESH",
     "discoveryClient": "APPMGMT",
     "compartmentId": "<COMPARTMENT_OCID>",
     "discoveryDetails": {
       "agentId": "<OCID of the Management agent>",
       "resourceType": "ORACLE_DATABASE",
       "resourceName": "<Resource name to display in Stackmonitoring UI>",
       "properties": {
         "propertiesMap": {
               "resource_id":"<DATABASE_OCID>",
               "asm_host":"<ASM HOSTNAME>",
               "asm_service_name":"+ASM",
               "is_asm_discovery":"true",
               "asm_port":"1521",
               "additional_agent_1":"ADDITIONAL_AGENT1_OCID",
               "additional_agent_2":"ADDITIONAL_AGENT2_OCID"
         }
       },
       "credentials": {
         "items": [
               {
             "credentialName" : "QVNNUGFzc3dvcmRJblZhdWx0",
             "credentialType" : "U1NMX1NFQ1JFVF9JRA==",
             "properties": {
               "propertiesMap": {
                 "ASMUserName": "<ASM user name in base64 encoded format>",
                 "PasswordSecretId": "<Encoded ASM user secret ocid in BASE64 encoded format>",
                 "ASMRole":"<ASM user role in base64 encoded format>"
               }
             }
           }
         ]
       }
     }
   }

Oracle DBシステムのリフレッシュの詳細は、Oracle Databaseシステム・コンポーネントのリフレッシュを参照してください。

Oracle Database

UIを使用したデータベース・システムを含むOracle Databaseの検出: 「リソース検出」ページから、空欄のUIを完了して、データベース・システムとそのコンポーネントを含むOracle Databaseを検出します。

マルチノードRACのデータベース・システムの検出時に複数のエージェントを含めるには、次のステップを実行します。

検出入力

• UI検出入力

  「入力」フィールド	摘要
  リソース名	データベースの名前
  DNSホスト名またはSCAN名	ドメイン・ネーム・システム(DNS)またはデータベースの単一クライアント・アクセス名(SCAN)
  ポート	Oracle Cloud Infrastructureの外部のデータベースがデータベース接続に使用するポート
  サービスの名前	接続で使用されるOracle Cloud Infrastructure外部のデータベースのサービス名
  プロトコル	Oracle Databaseに使用されるプロトコル。TCPまたはTCPSプロトコルのいずれかを選択します
  <compartment_name>コンパートメントのデータベース・ユーザー・パスワード・シークレット	ドロップダウン・リストからデータベース・ユーザー・パスワードを含むシークレットを選択します。このフィールドは、「プロトコル」フィールドで「TCPS」が選択されている場合にのみ表示されます。後述を参照してください。
  管理エージェント	データベースがインストールされているホストをモニターする管理エージェント ノート 複数のホストにまたがるデータベース・システムの場合は、データベース・システムのすべてのホストにデプロイされているすべての管理エージェントを選択します。
  モニタリング用のデータベース資格証明	.
  ユーザ名	Oracle Databaseモニタリング資格証明のユーザー名
  パスワード	Oracle Databaseモニタリング資格証明のベース64エンコード形式のパスワード
  役割	データベース・モニタリング・ユーザー(通常またはSYSDBA)のベース64エンコード形式のデータベース・ロール
  ASM情報
  管理エージェント	データベースがインストールされているホストをモニターする管理エージェント。クラスタおよびリスナー・エージェントを検出するには、データベース・ホストにインストールする必要があります。
  自動ストレージ・マネージャ	有効化または無効化デフォルトでは有効になっています。
  DNSホスト名またはスキャン名	ASMインスタンスが存在するデフォルトのdnsまたはSCAN名。
  ポート	ASMで使用されるポート。デフォルト値は1521です。
  サービスの名前	ASMサービス名
  モニタリング用のASM資格証明
  ユーザ名	ベース64でエンコードされた形式のASMユーザー名
  現在のコンパートメントのASMユーザー・パスワード・シークレット	OCI Vaultサービスで定義されている、ベース64エンコード形式のパスワード・シークレット
  役割	ベース64エンコード・フォーマットのロール。デフォルトではSYSMANです。使用可能な値: SYSASM、SYSDBA、SYSOPER
  検出対象
  スタック・モニタリングとログ・アナリティクス(推奨)	検出結果は、Stack MonitoringおよびLog Analyticsに送信されます。 ノート Log Analyticsの詳細は、クイック・スタートを参照してください。
  スタック・モニタリングのみ	検出結果はスタック・モニタリングにのみ送信されます。
  ログ・アナリティクスのみ	検出結果はLog Analyticsにのみ送信されます。
  ライセンス
  Enterprise Edition	リソースにはEnterprise Editionライセンスが割り当てられます。
  Standard Edition	リソースにはStandard Editionライセンスが割り当てられます。
  タグ(「拡張オプションの表示」の下)	フリーフォームおよび定義済タグは、検出中にスタック・モニタリング・リソースに適用できます。定義済みタグを使用するには、最初にタグネームスペースを作成します。を参照してください。定義済タグのタグ・ネームスペースの作成と管理の詳細は、タグおよびタグ・ネームスペースの概念を参照してください。リソースを検出すると、割り当てられた任意のタグが、検出されたすべてのリソースに適用されます。タグの前提条件およびタグの伝播の詳細は、タグの管理を参照してください。
  タグ・ネームスペース	フリーフォーム・タグを追加するには、「なし」を選択します。ネームスペースを選択して、定義されたタグをネームスペースに追加します。リソースを作成する権限がある場合、そのリソースにフリーフォーム・タグを適用する権限もあります。定義済タグを適用するには、タグ・ネームスペースを使用する権限が必要です。タグ付けの詳細は、リソース・タグを参照してください。タグを適用するかどうかがわからない場合は、このオプションをスキップするか(後でタグを適用できます)、管理者に問い合せてください。
  タグ・キー	タグを参照するために使用する名前を指定します。
  タグ値	タグ値を指定します。タグ・キーおよびタグ値の詳細は、タグ付けの概要を参照してください。

• CLI検出入力

  CLI入力変数	摘要
  <Additional_Agent1_OCID>	クラスタ内の最初の追加ノード
  <Additional_Agent2_OCID> (など)	クラスタ内の2番目の追加ノード(クラスタ内の追加ノードごとに続行)
  Agent_OCID	最初の検出OCIDのエージェント
  Compartment_OCID	Oracle Databaseシステムが監視されるコンパートメントOCID

前提条件

• OSBの場合、監視がサービス・バス・モニタリングが有効になっていることを確認します。

  1. FMW control: http:/<host>:<port>/emにログインします。
  2. サービス・バスのホーム・ページで、「操作」タブに移動します。
  3. 「モニタリング」チェック・ボックスを選択します。

• SOA検出の場合、WebLogicユーザーはAdministrator権限を持っている必要があります。

• Oracle WebLogicノード・マネージャの場合、Oracle WebLogicノード・マネージャ・リソースのMonitoringStatusメトリックの計算を確認するには、listenAddressを「すべてのローカル・アドレス」、有効なIPアドレスまたは解決可能なDNS名に設定します。listenAddressプロパティをlocalhostまたはnullに設定しないでください。listenAddressをlocalhostに設定する必要がある場合は、検出にローカル管理エージェントを使用してステータスを正確に計算します。

SSLを使用してOracle WebLogic Serverを有効にした場合は、キーストアから証明書をエクスポートし、管理エージェントKeyStoreにインポートします。WebLogicサーバーでのSSLの構成の詳細は、「SSLの構成」を参照してください。

管理エージェントへのTrustStoreのインポート

1. スタック・モニタリングのトラストストアおよびキーストアを保持するように、管理エージェントのファイルシステムに永続的なサブディレクトリを指定します。WLSインスタンスJMX SSLキーストアからスタック・モニタリング・トラストストアに証明書をエクスポートします。たとえば、UNIXホストの場合は次のようになります。

   keytool -exportcert -alias <alias of WLS SSL key> -file <Exported Cert Name> -keystore <path to the WLS SSL Keystore>.keystore -storepass <WLS SSL Keystore password> -rfc

2. WLSインスタンスのJMX SSLキーストアを管理エージェントのファイル・システム上のStack Monitoring Truststoreにインポートします。

   keytool -importcert -noprompt -alias <alias agent's truststore key> -file <Exported Cert Name>.cer -keystore AgentTrust.jks -storepass <Agent truststore password, default is "welcome">

3. スタック・モニタリング・トラストストア・ファイルをコピーし、その権限を更新します。

   エージェント・ホスト上の管理エージェントの読取り可能なセキュアな場所を識別します。

   cp <path_to_truststore_file/AgentTrust.jks <secure_readable_dir>/

   OCI Computeの場合:

    sudo chown oracle-cloud-agent:oracle-cloud-agent <secure_readable_dir>/AgentTrust.jks

   オンプレミス・コンピュート:

   sudo chown mgmt_agent:mgmt_agent <secure_readable_dir>/AgentTrust.jks

4. T3SがWebLogicドメインで「トラストストア・タイプ」がJKSの場合は、リソース検出の「TrustStoreパス」の<secure_readable_dir>/AgentTrust.jksなどの完全なトラストストア・パスを使用します。

Oracle WebLogic ServersでのMBeansの構成

JVMパフォーマンス・メトリックをプラットフォームMBeansから収集するには、ランタイムMBeanServerからMBeansにアクセスできるようにする必要があります。MBeansをアクティブ化するには、Oracle WebLogic Serverにログインし、WLSTスクリプトを実行してアクティブ化を確認します。

1. Oracle WebLogic ServersでのMBeansのアクティブ化

   次のように、各Oracle WebLogic Serverにログインするか、WebLogicコンソールからアクセスして、MBeansをアクティブ化します。

   • Oracle WebLogic Serverにログインします:

     『Enterprise Manager Cloud Control Middleware Management Guide』のActivating Platform MBeans on WebLogic Server 9.x to 10.3.2 versionsにあるWebLogic Scripting Toolセッション・デモストレーションのユーザー・アクションに従います。

   • WebLogicコンソールにアクセスします。

     「ドメイン」→「構成」→「一般」ページ→「詳細」オプションにナビゲートします。「Platform MBean Server Used」チェック・ボックスを選択します。

   前述のステップを実行した後にMBeansが登録されていない場合は、次のシステム・プロパティを使用してOracle WebLogic Serversを起動します。

   -Djavax.management.builder.initial=weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder

2. MBeansのアクティブ化の確認

   MBeansが正常にアクティブ化されているかどうかを確認するには、『Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のプラットフォームMBeanサーバーの使用に関する項にあるWLSTスクリプトを実行します。WLSTスクリプトは、プラットフォームMXBeansを使用して、実行中のOracle WebLogic Serverドメインのリソースをモニターする方法を示します。

   MBeansがjava.langに登録されていることを確認します。

管理エージェントとWebLogic内のすべてのサーバー間の接続性の確保

検出中に、スタック・モニタリング・エージェントはAdminServerと通信して、ドメイン・トポロジを検出します。検出後の監視は、管理対象サーバーと直接通信することによって行われます。これが発生するには、次を確認します。

• 管理エージェントは、ドメイン内のすべての管理対象サーバーと通信できます。
• 管理対象サーバーのホストおよびポートは、エージェントからアクセスできます。
• 管理対象サーバーの受信トラフィックをブロックするようにフィルタが構成されている場合は、エージェントが管理対象サーバーと通信するようにフィルタを調整します。

WebLogicシナリオ固有の検出結果

1. WebLogicドメインには2つのサーバーがあり、そのうちの1つが停止しています。

   検出結果: WebLogicドメインは、実行中の状態にある1つのサーバーのみで検出され、実行中の状態ではないサーバーは無視されます。

2. WebLogicドメインには、2つのサーバーを含むクラスタがあり、そのうちの1つが停止しています。

   検出結果: WebLogicクラスタは、実行中の状態にある1つのサーバーのみで検出されます。

3. WebLogicドメインには、実行中の状態ではない1つのサーバーのみを含むクラスタがあります。

   検出結果: クラスタもサーバーも検出されません

WebLogic検出入力

EBSトポロジ

E-Business Suiteインスタンスが検出されると、EBSとWebLogicの両方のリソースが検出されます。OHSとデータベースの検出は個別に実行する必要があります。

EBSにコロケートされたOracle HTTP Serverを監視するには、"OHS Discovery"を参照してください。OHSが個別に検出されると、EBSリソースとOHSリソースとの間にアソシエーションを作成できます。

EBSデータベースを監視するために、データベースが最初に検出されてからEBSが後で検出された場合、EBSリソースとEBS検出の終了時にデータベース・リソースとの間に使用タイプの関連付けが自動的に作成されます。ここでは、EBSリソースはスタック・モニタリング・リソース・タイプebs_instanceを参照し、データベース・リソースはスタック・モニタリング・リソース・タイプoci_oracle_dbまたはoci_oracle_pdbを参照します。

データベース検出の前にEBSが検出された場合、トポロジは2つの方法で更新できます。

• EBSインスタンスとデータベース・リソース間のアソシエーションの作成
• EBSトポロジのリフレッシュ

アソシエーションの作成:

コンポジットEBSリソースをホストに直接関連付けることはできません。ただし、EBSの子リソースは、次のように関連付けることができます。

• EBS Concurrent Manager usesホスト
• EBS CPノード・usesホスト

2つのリソース間のアソシエーションを作成するためのOCI CLIコマンド構文を次に示します。

oci stack-monitoring resource associate --association-type uses --compartment-id "<Compartment_OCID>" --source-resource-id "<Resource_OCID>" --destination-resource-id "<Database_Resource_OCID>"

次に例を示します:

oci stack-monitoring resource associate --association-type uses --<Compartment_OCID>
      ocid1.compartment.oc1..unique_ID --<Source_Resource_OCID>
      ocid1.stackmonitoringresource.oc1.iad.unique_ID --<Destination_Resource_OCID>
      ocid1.stackmonitoringresource.oc1.iad.unique_ID

EBSの場合、EBSリソースIDとして <Source_Resource_OCID>、データベースリソースIDとして <Destination_Resource_OCID>を指定することにより、上記のコマンドを使用して EBSとデータベースリソース間のアソシエーションを作成できます。

EBSディスカバリは、その基礎となるリソースに関連付けられており、次の図に示すようにスタック・モニタリングで表現されます。

前提条件

1. Oracle WebLogic ServersでのMBeansの構成
2. Formsセッション・データの収集の検証
3. Oracle E-Business Suite環境でのDNSの設定
4. E-Business Suiteアプリケーションで使用されるデータベースを追加します。

   まだ追加していない場合は、E-Business Suiteアプリケーションに使用するデータベースを追加します。Oracle Database (Discovery)を参照してください。

5. アプリケーション・リスナー・モニタリングのエージェント権限
6. スタック・モニタリングのE-Business Suiteデータベース・モニタリング要件

Formsセッション・データの収集の検証

次のタスクを実行して、Formsシステム・リソース・メトリックでFormsセッション・データの収集を確認して、後でそれを表示します。これは、Oracle WebLogic Domain (Oracle WebLogic ServersでのMBeansの構成)で実行されるステップに加えて行います。このステップが構成されていない場合、Formsシステム・メトリックの一部が収集されません。

Oracle E-Business Suiteにログインすると、APPSスキーマ資格証明を使用して、一意のセッションID (SID)で識別されるデータベースにユーザー・セッションが作成されます。各データベース・セッションは、Oracle E-Business Suiteアプリケーション・ユーザーに関連付けられます。これにより、トラブルシューティングの目的でデータベース・セッションをアプリケーション・ユーザーとリンクできます。Formsセッションを使用して、Oracle E-Business Suiteユーザーがデータベース・セッションをオープンした方法を決定できます。

1. Oracle E-Business Suiteにログインします。
2. ユーザー・インタフェースから、「システム管理者」に移動し、「プロファイル」、「システム」の順にクリックします。
3. 「サインオン: 監査レベル」の値が「フォーム」に設定されていることを確認します。これをサイト・レベルで設定します。
4. AuditTrail: Activateの値がYESに設定されていることを確認します。

変更を保存します。

Oracle E-Business Suite環境でのDNSの設定

Oracle E-Business Suiteホストは、ネットワーク上で相互に検出できる必要があります。たとえば、UNIX環境では、DNSサーバーは各ホストのファイル/etc/resolv.confに構成されます。

DNSサーバーが正しく構成されていることを確認するには、次のコマンドを実行します。

nslookup any_publicDomain_hostname

<any_publicDomain_hostname>をlocalhost以外で EBS環境の他のホストのホスト名に置き換えます。

次に、DNSサーバーが正しく構成されていることを検証する正常な出力の例を示します。

$ nslookup node02.examplehost.com

Server:         937.486.274.354
Address:        937.486.274.354

Non-authoritative answer:
Name:   node02.examplehost.com
Address: 135.756.247.46

アプリケーション・リスナー・モニタリングのエージェント権限

EBSアプリケーション・リスナーを監視するには、エージェントがEBSと同じホストにインストールされている必要があります。それ以外の場合、リソースは常に「停止中」と表示されます。

lsnrctl、srvctlおよびcrsctlコマンドを実行できるように、インストールされたエージェントのタイプに基づいてmgmt_agentまたはoracle-cloud-agentユーザーが、/etc/oraInst.locから取得されたOracle Inventoryグループ(通常はoinstall)に含まれていることを確認します。

次の手順を使用して、インストールされているエージェントのタイプに基づいて、mgmt_agentまたはoracle-cloud-agentユーザーにoinstall権限を付与します。

• Oracle Cloud Agentを使用するホスト: usermod -aG oinstall oracle-cloud-agent
• スタンドアロン・エージェントがあるホスト: usermod -aG oinstall mgmt_agent

グループ実行権限をディレクトリに追加する例:

chmod -R g+x+r /u01/install/APPS

OS権限を付与したら、次の手順を使用してエージェントを再起動します。エージェントとOSの適切な手順をそれぞれ使用します。

1. エージェントの停止
   • Oracle Linux 6の場合:
     • Oracle Cloud Agent: sudo /sbin/initctl stop oracle-cloud-agent
     • スタンドアロン・エージェント: sudo /sbin/initctl stop mgmt_agent
   • Oracle Linux 7の場合
     • Oracle Cloud Agent: sudo systemctl stop oracle-cloud-agent
     • スタンドアロン・エージェント: sudo systemctl stop mgmt_agent
2. startコマンドを使用して、エージェントを起動します。

スタック・モニタリングのE-Business Suiteデータベース・モニタリング要件

EBSアプリケーションを検出する前に、E-Business Suite(EBS)データベースの監視に使用するOracleデータベースを検出する必要があります。データベースが最初に検出されると、EBSアプリケーションの検出が完了すると、そのデータベースは自動的にEBSアプリケーションに関連付けられます。データベースが検出される前にEBSアプリケーションの検出が実行された場合、関連付けを手動で作成する必要があります。

E-Business Suiteの監視には、EBSスキーマにアクセスするための特定の権限が必要です。設定は、EBSデータストアとして使用されるデータベースのタイプ(非コンテナDBとコンテナDBとプラガブルDB)によって異なります。Stack MonitoringはEBSのスキーマ所有者(通常はAPPS)をEBSの検出時のデータベース資格証明として使用することをサポートします。EBSアプリケーションの監視に必要な権限のみを持つ監視ユーザーを作成することをお薦めします。同じデータベース・ユーザーを使用して、EBSスキーマを含むOracleデータベースとEBSアプリケーションの両方を監視できます。データベース監視ユーザーを作成する手順はMOS Note: 2857604.1にあります。

データベース権限

EBSモニタリング・ユーザーが必要な権限ですでに作成されたら、モニタリング・ユーザーに必要なEBSアプリケーション権限を適用します。特定の権限は、EBSスキーマ名がAPPSであると仮定して、次のコードで定義されます。設定でスキーマ名が異なる場合は、次のコードでAPPSを実際のスキーマ名に置き換えます。<your_monitoring_user>を、MOS Note: 2857604.1を使用して作成したデータベース監視ユーザーに置き換えます。

GRANT SELECT ON APPS.FND_OAM_CONTEXT_FILES TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_PRODUCT_GROUPS TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONC_PROG_ONSITE_INFO TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_PROGRAMS_VL TO <your_monitoring_user>;
GRANT EXECUTE ON APPS.FND_OAM_EM TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_REQUESTS TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_APPLICATION_VL TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_QUEUES TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_LOOKUPS TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_WORKER_REQUESTS TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_QUEUES_VL TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_OAM_FNDUSER_VL TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_FORM_SESSIONS_V TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CP_SERVICES TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_PROCESSES TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_SVC_COMPONENTS TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_LOG_MESSAGES TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_CONCURRENT_PROGRAMS TO <your_monitoring_user>; 
GRANT SELECT ON APPS.FND_CONFLICTS_DOMAIN TO <your_monitoring_user>; 
GRANT SELECT ON APPS.FND_ORACLE_USERID TO <your_monitoring_user>; 
GRANT SELECT ON APPS.FND_APP_SERVERS TO <your_monitoring_user>; 
GRANT SELECT ON APPS.FND_NODES TO <your_monitoring_user>;
GRANT SELECT ON APPS.ICX_SESSIONS TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_USER TO <your_monitoring_user>;
GRANT SELECT ON APPS.FND_RESPONSIBILITY TO <your_monitoring_user>;
GRANT EXECUTE ON APPS.FND_PROFILE TO <your_monitoring_user>;
GRANT SELECT ON APPS.WF_DEFERRED TO <your_monitoring_user>;
GRANT SELECT ON APPS.WF_NOTIFICATION_IN TO <your_monitoring_user>;
GRANT SELECT ON APPS.WF_NOTIFICATION_OUT TO <your_monitoring_user>;

これらの権限は、次のようにebs_apply_grants.sh (EBSスクリプトに含まれる)を実行することで適用できます。

1. EBSデータベース・ホストにログインします。
2. EBS環境をソーシングします。
3. 次のようにスクリプトを実行します。

   sh ebs_apply_grants.sh <monitoring user> <SYSTEM_password> <APPS_password>

例:

sh ebs_apply_grants.sh MONCS manager apps

EBSインスタンスがプラガブル・データベース(PDB)に対して実行されている場合、EBSモニタリング・ユーザーに追加の権限を付与します。

GRANT INHERIT PRIVILEGES ON USER <monitoring user> TO APPS;

権限を適用した後、次のようにebs_validate_grants.sql (EBSスクリプトに含まれる)を実行して、権限が設定されていることを確認します。

1. EBSデータベース・ホストにログインします。
2. EBSモニタリング・ユーザーとしてEBSデータベースにログインします。
3. 次のように検証スクリプトを実行します。

   @ebs_validate_grants.sql

すべての権限付与が行われた場合のスクリプトの出力は次のようになります。

TABLE_NAME                     PRIVILE STATUS
------------------------------ ------- -------
FND_OAM_EM                     EXECUTE GRANTED
FND_PROFILE                    EXECUTE GRANTED
FND_APPLICATION_VL             SELECT  GRANTED
FND_APP_SERVERS                SELECT  GRANTED
FND_CONCURRENT_PROCESSES       SELECT  GRANTED
FND_CONCURRENT_PROGRAMS        SELECT  GRANTED
FND_CONCURRENT_PROGRAMS_VL     SELECT  GRANTED
FND_CONCURRENT_QUEUES          SELECT  GRANTED
FND_CONCURRENT_QUEUES_VL       SELECT  GRANTED
FND_CONCURRENT_REQUESTS        SELECT  GRANTED
FND_CONCURRENT_WORKER_REQUESTS SELECT  GRANTED

TABLE_NAME                     PRIVILE STATUS
------------------------------ ------- -------
FND_CONC_PROG_ONSITE_INFO      SELECT  GRANTED
FND_CONFLICTS_DOMAIN           SELECT  GRANTED
FND_CP_SERVICES                SELECT  GRANTED
FND_FORM_SESSIONS_V            SELECT  GRANTED
FND_LOG_MESSAGES               SELECT  GRANTED
FND_LOOKUPS                    SELECT  GRANTED
FND_NODES                      SELECT  GRANTED
FND_OAM_CONTEXT_FILES          SELECT  GRANTED
FND_OAM_FNDUSER_VL             SELECT  GRANTED
FND_ORACLE_USERID              SELECT  GRANTED
FND_PRODUCT_GROUPS             SELECT  GRANTED

TABLE_NAME                     PRIVILE STATUS
------------------------------ ------- -------
FND_RESPONSIBILITY             SELECT  GRANTED
FND_SVC_COMPONENTS             SELECT  GRANTED
FND_USER                       SELECT  GRANTED
ICX_SESSIONS                   SELECT  GRANTED
WF_DEFERRED                    SELECT  GRANTED
WF_NOTIFICATION_IN             SELECT  GRANTED
WF_NOTIFICATION_OUT            SELECT  GRANTED

INHERIT_PRIVILEGES_STATUS
--------------------------
INHERIT PRIVILEGES GRANTED

いずれかの付与が欠落している場合、影響は次のように説明されます。

E-Business検出入力

PeopleSoftデータベースの検出

PeopleSoft (PSFT)スキーマを含むOracle Databaseは、PeopleSoftアプリケーションを検出する前に検出する必要があります。データベースが最初に検出されると、PeopleSoftリソース検出が完了すると、データベースは自動的にPeopleSoftアプリケーションに関連付けられます。

データベースが検出される前にPeopleSoftアプリケーション検出が実行された場合、アソシエーションを手動で作成する必要があります。詳細は、アプリケーション・トポロジを参照してください。

Oracle Databaseを検出するには、Oracle Databaseを参照してください。

PeopleSoftモニタリング用のDB付与権限

PeopleSoft (PSFT)の監視には、PSFTデータベース・スキーマにアクセスするための特定の権限が必要です。設定は、PSFTデータストアとして使用されるデータベースのタイプ(非コンテナDBとコンテナDBおよびプラガブルDB)によって異なります。スタック・モニタリングでは、PSFTを検出する際のデータベース資格証明として、PSFTスキーマ所有者(通常はSYSADM)の使用がサポートされます。PSFTアプリケーションの監視に必要な権限のみを持つ監視ユーザーを作成することをお薦めします。同じデータベース・ユーザーを使用して、PeopleSoftスキーマを含むOracleデータベースとPeopleSoftアプリケーションの両方を監視できます。データベース監視ユーザーを作成する手順はMOS Note: 2857604.1にあります。

モニタリング・ユーザーに必要な権限があることを確認し、欠落している権限を適用するには:

1. モニタリング・ユーザーの期限が切れていないことを確認します。
   1. 次のコマンドを実行して、モニタリング・ユーザー・ステータスを確認します。

      select username, account_status from dba_users where username='<your_monitoring_user>'

   2. モニタリング・ユーザーにEXPIREDと表示された場合は、パスワードをリセットします。
2. 次のPeopleSoftスクリプトを実行します。

適用する特定の付与を理解したり、付与を手動で適用するには、実行する次のコマンドのリストを参照してください。

データベース権限

• PeopleSoftアプリケーション権限

  GRANT SELECT ON SYSADM.PSSTATUS TO <your_monitoring_user>;
  GRANT SELECT ON SYSADM.PSRELEASE TO <your_monitoring_user>;
  GRANT SELECT ON SYSADM.PSPMAGENT TO <your_monitoring_user>;

• PeopleSoftアプリケーション・シノニム

  CREATE OR REPLACE SYNONYM <your_monitoring_user>.PSSTATUS FOR SYSADM.PSSTATUS;
  CREATE OR REPLACE SYNONYM <your_monitoring_user>.PSRELEASE FOR SYSADM.PSRELEASE;
  CREATE OR REPLACE SYNONYM <your_monitoring_user>.PSPMAGENT FOR SYSADM.PSPMAGENT;

• 検索エンジン付与

  ノート
  
  検索エンジンは、ElasticsearchとOpenSearchの両方をサポートしています。

  GRANT SELECT ON SYSADM.PS_PTSF_SRCH_ENGN TO <your_monitoring_user>;

• 検索エンジン・シノニム

  ノート
  
  検索エンジンは、ElasticsearchとOpenSearchの両方をサポートしています。

  CREATE OR REPLACE SYNONYM <your_monitoring_user>.PS_PTSF_SRCH_ENGN FOR SYSADM.PS_PTSF_SRCH_ENGN

• プロセス・モニター付与

  GRANT SELECT ON SYSADM.PSPRCSRQST TO <your_monitoring_user>;
  GRANT SELECT ON SYSADM.PSXLATITEM TO <your_monitoring_user>;

• プロセス・モニター・シノニム

  CREATE OR REPLACE SYNONYM <your_monitoring_user>.PSPRCSRQST FOR SYSADM.PSPRCSRQST;
  CREATE OR REPLACE SYNONYM <your_monitoring_user>.PSXLATITEM FOR SYSADM.PSXLATITEM;

PeopleSoft Performance Monitor for Pure Internet Architecture (PIA)の有効化

1. PeopleToolsにナビゲートし、「Webプロファイル」に移動して「Webプロファイル構成」をクリックし、使用中のプロファイル(PRODなど)を検索します。
2. まだチェックされていない場合は、「PPMエージェントの有効化」チェック・ボックスを選択します。
3. すべてのPIAドメインを再起動します。

アプリケーション・サーバーおよびProcess Schedulerドメインの前提条件

PeopleSoft Performance Monitor Agentの有効化

1. PSADMINコマンドライン・インタフェースを使用して、「Application Server」(オプション1)または「Process Scheduler」(オプション2)→「Administer a domain」(オプション1)→「select domain」→「Edit configuration/log files」メニュー(オプション6)→「Edit domain configuration file」(オプション1)を選択すると、ドメイン構成ファイルが編集モードで開きます。

2. 「PSTOOLS」セクションで、EnablePPM Agentの値を確認します。「PPMエージェントの有効化」に、値を1に設定し、ファイルを保存します。

JMXエージェントの有効化

この前提条件により、スタック・モニタリングでPeopleSoftアプリケーションの可用性およびパフォーマンス・データを収集できます。

1. PSADMINコマンドライン・インタフェースを使用して、「Application Server」(オプション1)または「Process Scheduler」(オプション2)→「Administer a domain」(オプション1)→「select domain」→「Edit configuration/log files」メニュー(オプション6)→「Edit domain configuration file」(オプション1)を選択すると、ドメイン構成ファイルが編集モードで開きます。

2. 「PSTOOLSの設定」セクションを見つけて以下の値を設定します。

   1. 使用するリモート管理ポートが、ホスト上の他のプロセスによって使用されていないことを確認します。

   2. UserID

      • UserIdはテキスト形式である必要があります。

      • すべてのアプリケーション・サーバー・ドメインおよびプロセス・スケジューラ・ドメインに同じUserIdおよびパスワードを使用する必要があります。

   3. パスワードを暗号化するには、PSCipherユーティリティを使用します。
   4. 次の「パフォーマンス・コレータ」プロパティの変更を構成した後、アプリケーション・サーバーおよびProcess Schedulerドメインを再起動します。

3. • PSFTバージョン8.59以前の場合は、リモート管理ポートのみを設定する必要があります。RMIポート値は、1によって増分されたリモート管理ポート値に基づいて自動的に設定されます。たとえば、リモート管理ポートが10100の場合、ポート10101がPHCのRMIサーバーに使用されます。ポートの使用を計画する場合は、これを考慮する必要があります。前述の例では10101が自動的に選択されるため、そのポートが空いていない場合、PSFTは他のランダムな空きポートを自動的に選択します。構成が正常に保存されたらドメイン構成ファイルを確認し、これらのポートを使用して検出で接続してください。

     例:

     Enable Remote Administration=1
     Remote Administration Port=10100
     Remote Administration UserId=<the userid you have defined in step 2b>
     Remote Administration Password={V2.1}<encrypted password>

   • PSFTバージョン8.60以降では、RMIポートは構成ファイル内の1つの追加パラメータによって制御されます。値が明示的に設定されていることを確認します。パフォーマンス・コレータ・プロパティを構成した後、アプリケーション・サーバーおよびProcess Schedulerドメインを再起動します。

     例:

     Enable Remote Administration=1
     Remote Administration Port=10100
     Remote Administration RMI Server Port=10101
     Remote Administration UserId=<the userid you have defined in step 2b>
     Remote Administration Password={V2.1}<encrypted password>

   ノート
   
   変更が保存された後に、前述の保存済設定が構成ファイルに正しく表示されることを確認してください。

パフォーマンス・コレータ・プロパティの有効化

$PS_CFG_HOMEにあるドメイン・テンプレート・ファイルpsprcsrv.ubx (プロセス・スケジューラ)およびpsappsrv.ubx (アプリケーション・サーバー)で、Perf Collatorの現在の値を確認できます。

Perf Collatorが有効の場合は、次のようにエントリが表示されます。

{PPM} Do you want Performance Collators configured (PSPPMSRV) (y/n)? [y]:

パフォーマンス・コレータが無効の場合は、次のようにエントリが表示されます。

{PPM} Do you want Performance Collators configured (PSPPMSRV) (y/n)? [n]:

パフォーマンス・コレータがすでに有効になっており、変更がEnablePPMエージェントまたはJMX値に実装されている場合: すべてのドメインを再起動します。

パフォーマンス・コレータがすでに有効化されていない場合は、次のステップに進みます。

1. PSADMINコマンドライン・インタフェースを使用して、「Application Server」(オプション1)または「Process Scheduler」(オプション2)→「Administer a domain」(オプション1)→「select domain」→「Configure this domain」(オプション4)を選択します。
2. Do you want to continue (y/n)という質問にyと入力します。このオプションはドメインをシャットダウンします

3. Perf Collatorプロパティの値を確認します。

4. 値がYesに設定され、Collatorがすでに有効になっている場合、アクションは必要ありません。次に示すように、「構成のロード」を選択します(Application Serverの場合はオプション14、Process Schedulerの場合はオプション7)。

5. 値がNoに設定されている場合は、アプリケーション・サーバーの場合は10、プロセス・スケジューラの場合はオプション3を入力し、値をYesに切り替えます

6. Perf CollatorをYesに設定したことを確認した後、次のように「構成のロード」を選択します(アプリケーション・スケジューラの場合はオプション14、プロセス・スケジューラの場合はオプション7)。

7. 最後に、「Boot this domain」オプション1を選択してドメインを起動します。

検出するドメインの識別

スタック・モニタリングでは、Oracle Database内に格納された情報を利用して、検出またはリフレッシュされるドメインを識別します。現在のドメインのリストを検証するには、次の問合せを実行します。

SELECT * FROM PSPMAGENT;

問合せによって戻された、すでに存在しないドメインは、PeopleSoftアプリケーションを検出/リフレッシュする前に削除する必要があります。

リストされていないドメインを追加するには、ドメインを手動で追加するを参照してください。

失効したドメインを削除するには、SYSADMまたは同等のユーザーとして次のSQLを実行します。すべての失効したドメインが削除されるまで、ステップを繰り返します。

• 変更を行う前に、PSPMAGENTテーブルをバックアップします。<DATE>を現在のタイムスタンプに置き換えてください。

  create table PSPMAGENT_BKP_<DATE> as select * from PSPMAGENT;

• 作成されたバックアップ表に親表と同じ内容が含まれていることを確認します。

  select * from PSPMAGENT
  MINUS
  select * from PSPMAGENT_BKP_<DATE>;

PSPMAGENTからの行数がPSPMAGENT_BKP_<DATE>と一致する場合は、失効したドメインの削除を続行します。

delete from PSPMAGENT WHERE PM_AGENTID='&enter_agent_id_of_stale_domain';
Commit;

ドメインの手動追加

最後に、すべての有効なドメインがPSPMAGENT表から参照可能かどうかを確認します。なんらかの理由で有効なドメインが表示されない場合は、次の手順に従います。

バックアップを作成します:

1. システム管理者または同等のユーザーは、変更を行う前に表のバックアップを取得します。<DATE>を現在のタイムスタンプに置き換えてください。

   create table PSPMAGENT_BKP_<DATE> as select * from PSPMAGENT;

2. 作成されたバックアップ表に親表と同じ内容が含まれていることを確認します。PSPMAGENTの行数は、PSPMAGENT_BKP_<DATE>の行数と一致する必要があります。

   select * from PSPMAGENT
   MINUS
   select * from PSPMAGENT_BKP_<DATE>;

Process Schedulerドメインの追加

INSERT INTO  PSPMAGENT values
('&AGENT_ID','&PM_JMX_RMI_PORT','PSMONITORSRV','&DOMAIN_NAME','04','&DOMAIN_DIR','Y','&HOST_PORT:','1','1','N');

例:

SQL>  INSERT INTO  PSPMAGENT values
('&AGENT_ID','&PM_JMX_RMI_PORT','PSMONITORSRV','&DOMAIN_NAME','04','&DOMAIN_DIR','Y','&HOST_PORT:','1','1','N');  2 
Enter value for unique_agent_id: 1000
Enter value for pm_jmx_rmi_port: 10500
Enter value for domain_name: PRCSDOM02
Enter value for domain_dir: /u01/app/oracle/product/psfthcm-midtierlinux-2/ps_cfg_home/appserv/prcs/PRCSDOM02
Enter value for host_name: psfthcm-midtierlinux-2
old   2: ('&unique_agent_id','&PM_JMX_RMI_PORT','PSMONITORSRV','&DOMAIN_NAME','04','&domain_dir','Y','&host_name:','1','1','N')
new   2: ('1000','10500','PSMONITORSRV','PRCSDOM02','04','/u01/app/oracle/product/psfthcm-midtierlinux-2/ps_cfg_home/appserv/prcs/PRCSDOM02','Y','psfthcm-midtierlinux-2:','1','1','N')
  
1 row created.

アプリケーション・サーバー・ドメインの追加

INSERT INTO  PSPMAGENT values
('&unique_agent_id','&JMX_RMI_PORT','PSMONITORSRV','&DOMAIN_NAME','01','&DOMAIN_DIR','Y','&host_name:&jolt_port','1','1','N');

例:

SQL> INSERT INTO  PSPMAGENT values
('&unique_agent_id','&JMX_RMI_PORT','PSMONITORSRV','&DOMAIN_NAME','01','&DOMAIN_DIR','Y','&host_name:&jolt_port','1','1','N');   2 
Enter value for unique_agent_id: 1003
Enter value for jmx_rmi_port: 10500
Enter value for domain_name: APPDOM4
Enter value for domain_dir: /u01/app/oracle/product/psfthcm-midtierlinux-3/ps_cfg_home/appserv/APPDOM04
Enter value for host_name: psfthcm-midtierlinux-3
Enter value for jolt_port: 9033
old   2: ('&unique_agent_id','&JMX_RMI_PORT','PSMONITORSRV','&DOMAIN_NAME','01','&DOMAIN_DIR','Y','&host_name:&jolt_port','1','1','N')
new   2: ('1003','10500','PSMONITORSRV','APPDOM4','01','/u01/app/oracle/product/psfthcm-midtierlinux-3/ps_cfg_home/appserv/APPDOM04','Y','psfthcm-midtierlinux-3:9033','1','1','N')

PIAサーバーの追加

INSERT INTO  PSPMAGENT values
('&unique_agent_id','-1','WEBRESOURCE','&DOMAIN_NAME','02','&DOMAIN_DIR','Y','&host_name:&http_port:&https_port','1','1','N');

例:

INSERT INTO  PSPMAGENT values
('&unique_agent_id','-1','WEBRESOURCE','&DOMAIN_NAME','02','&DOMAIN_DIR','Y','&host_name:&http_port:&https_port','1','1','N');
Enter value for unique_agent_id: 19
Enter value for domain_name: peoplesoft03
Enter value for domain_dir: /u01/app/oracle/product/psfthcm-midtierlinux-3/ps_cfg_home/webserv/WEBSERVER/peoplesoft03
Enter value for host_name: psfthcm-midtierlinux-3
Enter value for http_port: 9000
Enter value for https_port: 9001
old   2: ('&unique_agent_id','-1','WEBRESOURCE','&DOMAIN_NAME','02','&DOMAIN_DIR','Y','&host_name:&http_port:&https_port','1','1','N')
new   2: ('19','-1','WEBRESOURCE','peoplesoft03','02','/u01/app/oracle/product/psfthcm-midtierlinux-3/ps_cfg_home/webserv/WEBSERVER/peoplesoft03','Y','psfthcm-midtierlinux-3:9000:9001','1','1','N')
  
1 row created.

PeopleSoftでの検索エンジン検出の有効化

検索エンジンの検出はオプションで、ElasticsearchとOpenSearchの両方をサポートしています。検索エンジンがすでに統合されている場合は、初期検出に含めることができます。今後、検索エンジンを統合するには、PeopleSoft CLI refreshコマンドを使用し、監視ユーザーに検索エンジンDB権限を追加します。権限付与の詳細は、PeopleSoftモニタリング用のDB付与権限およびCLIリフレッシュ・コマンドの詳細は、PeopleSoftリフレッシュを参照してください。

grep JAVA_HOME emd.properties
JAVA_HOME=/var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/jdk1.8.0_371-b11

次の前提条件により、PeopleSoftの検索エンジン統合が有効になります。

• スタック・モニタリングでは、SSLで構成された検索エンジンのモニタリングのみがサポートされます。エンドポイントはHTTPSである必要があります。設定の詳細は、それぞれ「ElasticsearchのSSLの構成」または「OpenSearchのSSLの構成」を参照してください。

• 検索エンジンを検出する前に、JKSトラストストアを作成します。JKSは、検索エンジンから証明書を格納するモニタリング・エージェント・ホスト上で唯一サポートされているトラスト・ストア・タイプであるためです。このトラストストアの場所およびパスワードは、CLIによる検出の実行中に検出UIまたは検出JSONで必要なパラメータですが、トラスト・ストアの場所はエージェント・ホストでアクセス可能である必要があります。

  例:

  keytool -keystore truststore.jks -alias <ALIAS> -import -file <SEARCH ENGINE CERTIFICATE>

PeopleSoftのプロセス・モニター検出の有効化

• プロセス・モニターは、PeopleSoftとともに検出され、PeopleSoftアプリケーションの検出時にデフォルトで有効になります。「プロセス・モニターの検出」セクションで「いいえ」を選択すると、PeopleSoft検出にプロセス・モニターは含まれません。
• プロセス モニターの検出はオプションです。プロセス・モニターがすでに有効になっている場合は、初期検出に含めることができます。今後、プロセス・モニターを統合するには、PeopleSoft CLI refreshコマンドを使用し、プロセス・モニターDB権限をモニタリング・ユーザーに追加します。権限付与の詳細は、PeopleSoftモニタリング用のDB付与権限およびCLIリフレッシュ・コマンドの詳細は、PeopleSoftリフレッシュを参照してください。

• プロセス・モニターの検出に必要なプロパティはありません

• ユーザー・インタフェース

  • プロセス モニターの検出は、デフォルトで含まれています。オプト・アウトするには、「リソース検出」パネルの「プロセス・モニターの検出」で「いいえ」を選択します。

前提条件

• JMXモニタリングを有効にします。JMXリモートの有効化を参照してください。
  ノート
  
  Tomcatの監視ではSSLはサポートされていません。Tomcatのドキュメントに従うと、SSLはデフォルトで無効になります。

Apache Tomcat検出入力

入力パラメータの詳細は、JSON入力パラメータを参照してください

前提条件

カスタム・データベース・ユーザーの作成

Microsoft SQL Serverデータベースを監視できるようにするため、特別なデータベース・ユーザーを次の方法で作成できます。

ユーザー(monstkなど)を作成し、新しいユーザーをマスターおよびmsdbデータベースにマップします。その後、次の最小限の権限をこのユーザーに付与します。

CREATE LOGIN monstk
WITH PASSWORD = 'monstk1;123';
GO
CREATE USER monstk FOR LOGIN monstk;
GO

ユーザーをすべてのシステムおよびユーザー・データベースにマップします。

USE master;
CREATE USER monstk FOR LOGIN monstk;
GRANT VIEW ANY DATABASE TO monstk;
GRANT VIEW ANY definition TO monstk;
GRANT VIEW server STATE TO monstk;

GRANT EXECUTE ON sp_helplogins TO monstk;
GRANT EXECUTE ON sp_readErrorLog TO monstk;
GRANT EXECUTE ON dbo.xp_regread TO monstk;

GRANT CREATE FUNCTION TO [monstk];
GRANT CONTROL TO [monstk];
GRANT CREATE TABLE TO [monstk];
GRANT SELECT ON [sys].[sysaltfiles] TO [monstk];

USE msdb;
GRANT SELECT ON dbo.sysjobsteps TO monstk;
GRANT SELECT ON dbo.sysjobs TO monstk;
GRANT SELECT ON dbo.sysjobhistory TO monstk;

MS SQL Server検出入力

前提条件

WebLogicは、Managed File Transfer (MFT)を検出する前に検出する必要があります。MFTを検出する場合、検出UIで、対応するWebLogicをドロップダウン・リストから選択します。

スタック・モニタリングのデータベース・モニタリング要件

Oracleデータベースは、MFTアプリケーションを検出する前に検出する必要があります。最初にデータベースが検出されると、MFTアプリケーションの検出が完了すると、そのデータベースは自動的にMFTアプリケーションに関連付けられます。データベースが検出される前にMFTアプリケーションの検出が実行された場合、関連付けを手動で作成する必要があります。詳細は、「アプリケーション・トポロジの更新」を参照してください。

Managed File Transferアプリケーションを監視するには、MFTスキーマにアクセスするための特定の権限が必要です。スタック・モニタリングでは、MFTを検出する際のデータベース資格証明として、MFTスキーマ所有者(通常はDEV_MFT)の使用がサポートされます。MFTアプリケーションの監視に必要な権限のみを持つ監視ユーザーを作成することをお薦めします。同じデータベース・ユーザーを使用して、MFTスキーマを含むOracleデータベースとMFTアプリケーションの両方を監視できます。データベース監視ユーザーを作成する手順はMOS Note: 2857604.1にあります。

特定の権限は、次のコードで定義されています。これは、MFTスキーマ名がDEV_MFTであると想定しています。設定でスキーマ名が異なる場合は、次のコードでDEV_MFTを実際のスキーマ名に置き換えます。<user>を、スクリプトを使用して作成したデータベース・モニタリング・ユーザーに置き換えます。DEV_MFTスキーマが存在する場所に作成されたモニタリング・ユーザーに付与が適用されていることを確認します。

データベース権限:

GRANT SELECT ON DEV_MFT.MV_MFT_SOURCE_MESSAGE TO <your_monitoring_user>;
GRANT SELECT ON DEV_MFT.MV_MFT_TARGET_INFO TO <your_monitoring_user>;
GRANT SELECT ON DEV_MFT.MV_MFT_TRANSFER_COUNT_INFO TO <your_monitoring_user>;
GRANT SELECT ON DEV_MFT.MV_MFT_SOURCE_INFO TO <your_monitoring_user>;
GRANT SELECT ON DEV_MFT.MV_MFT_TRANSFER TO <your_monitoring_user>;

検出入力

コロケートされたOHS

コロケートされたOHS検出は、Weblogicドメイン検出の一部であり、その前提条件がすべて適用されます。リモート監視がサポートされています。サポートされている Linuxまたは Solarisホスト。

同一のOHSのインストールの詳細は、「Oracle HTTP Serverのインストールについて」を参照してください。

スタンドアロンOHS

サポートされるバージョン:

• バージョン11.x - メトリック収集に使用されるローカル監視のみ、LinuxまたはSolarisホスト、OPMNツール。

• バージョン12.x - ローカル・モニタリングのみ、LinuxまたはSolarisホスト、メトリック収集に使用されるWLSTツール

前提条件

• 管理エージェントは、スタンドアロンのOracle HTTP Serverと同じホストにインストールする必要があります。Kubernetesポッドの場合、スタンドアロンOHSを1つのKubernetesポッドにインストールし、管理エージェントを別のポッドにインストールできます。

• OHS構成ファイル(httpd.conf)は、管理エージェント・インストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合はoracle-cloud-agent)がアクセス可能かつ読取り可能である必要があります。

OHSバージョン11.x:

バージョン11.x OHSは、OPMNツールを使用してメトリックを収集します。

OHSバージョン12.x:

1. httpd.confファイルに対するエージェント・ユーザーの読取り権限:

   <PATH>/user_projects/domains/<domain_name>/config/fmwconfig/components/OHS/<COMP_NAME>/httpd.conf

   例:

   <PATH>/user_projects/domains/ohs_domain/config/fmwconfig/components/OHS/ohs1

   次のコマンドを実行して、読取りアクセスを提供します。

   sudo chmod 640 <PATH>/user_projects/domains/<domain_name>/config/fmwconfig/components/OHS/<COMP_NAME>/httpd.conf

2. OHS Javaキーストア・ファイルに対するエージェント・ユーザーの読取り権限:

   <ORACLE HOME DIRECTORY>/wlserver/server/lib/DemoTrust.jks (カスタム証明書を使用する場合のカスタムjksファイル)

   例:

   sudo chmod 640 <absolute path to <Oracle Home directory>/wlserver/server/lib/DemoTrust.jks

3. <ORACLE HOME DIRECTORY>/oracle_common/common/bin/wlst.shに対する読取りおよび実行権限

OHSバージョン11.x検出入力

OHSバージョン12.x検出入力

前提条件

• Management Agentは、Apache HTTP Serverと同じホストにインストールする必要があります。
• mod_status Apacheモジュール(https://httpd.apache.org/docs/2.4/mod/mod_status.html)を有効にします。指定されたホスト名およびポートの/server-statusロケーション・ディレクティブを構成します。

  例:

  http(s)://<hostname>:<port>/server-status

• ExtendedStatusディレクティブ(https://httpd.apache.org/docs/2.4/mod/core.html#extendedstatus)をオンにします。
• 該当する場合は、エージェントがインストールされているホストからHTTP/HTTPSリクエストを正常に実行できるように、構成済の/server-statusロケーション・ディレクティブへのアクセス制御を提供します。エージェントは、必要に応じてHTTPS接続によるBasic認証のみをサポートします。追加のアクセス制御の構成の詳細は、Apache Documentation、 Authentication and Authorizationを参照してください。

• Apacheバイナリ・ファイルは、管理エージェントのインストール・ユーザーがアクセスでき、実行可能である必要があります。

  • Apache *.confファイル(httpd.confファイルを含む)は、管理エージェント・インストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloudエージェントの場合はoracle-cloud-agent)がアクセスおよび読取り可能にする必要があります。
  • Apacheバイナリ・ファイル(httpd)は、管理エージェント・インストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合はoracle-cloud-agent)がアクセスして実行可能である必要があります。
  • Apache pidファイル(httpd.pid)は、管理エージェント・インストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloudエージェントの場合はoracle-cloud-agent)がアクセス可能かつ読取り可能である必要があります。

次に、専用のapache管理者ユーザー・グループを作成し、それに管理エージェント・ユーザーを追加して、管理エージェント・ユーザーに必要なすべての権限を追加する方法の例を示します。

#Create a user group for apache administration
groupadd apache_admin_grp
 
#Add management agent user to the apache admin group
#for user installed management agent
usermod -G apache_admin_grp mgmt_agent
#for oracle cloud agent plugin
usermod -G apache_admin_grp oracle-cloud-agent
 
#Change ownership for apache server root directory and binary file. Example:
chown -R root:apache_admin_grp /etc/httpd
chmod -R 770 /etc/httpd
 
chown -R root:apache_admin_grp /usr/sbin/httpd
chmod -R 770 /usr/sbin/httpd
 
#Grant access to httpd.pid file. Example:
chown -R root:apache_admin_grp /run/httpd
 
#Restart the Agent for the user group assignment to take effect.
#for user installed management agent
systemctl restart mgmt_agent
#for oracle cloud agent plugin
systemctl restart oracle-cloud-agent

Apache HTTP Server検出入力

エクスポータの設定

エクスポータは、OUDからメトリックを収集し、Prometheus形式でメトリックを公開するエンドポイントを作成します。これらのメトリックは、管理エージェントによってテレメトリ・データストアに<specified name space>にアップロードされます。

輸出業者は、各インストール・モードのインスタンスごとに設定する必要があります。たとえば、3つのディレクトリと2つのプロキシがある場合、エクスポータは5回設定する必要があります。

設定ステップの概要:

1. Pythonがインストールされていることを確認し、python-ldapもインストールします
2. OUDユーザーのランタイム・グループをmgmt_agentユーザーに追加します
3. エクスポータ・スクリプトをカスタムの場所にコピー
4. OUDエクスポータ用の一時パスワード・ファイルの作成
5. OUDインスタンスのモニタリング・ユーザーの作成
6. データベース・サイズを監視するためのOUDデータベースへのファイル・システムの付与
7. OUDエクスポータの設定
8. OSのリブート後にOUDエクスポータを起動できるようにします
9. メトリックのフローの確認

設定ステップ:

1. Pythonがインストールされていることを確認し、python-ldapもインストールします:

   • RedHat/Oracle Linux 8および9上で:

     sudo -n yum install -y libnsl python3-ldap httpd-tools

   • RedHat/Oracle Linux 7の場合:

     sudo -n yum install -y libnsl python-ldap httpd-tools

2. mgmt_agentに適切な権限があることを確認します。

   1. OUDユーザーのランタイム・グループをmgmt_agentユーザーに追加します。

      sudo usermod -G <OUD_USER_GROUP> mgmt_agent

   2. <ORACLE_HOME>ディレクトリとその親ディレクトリに実行権限があることを確認します。

      sudo chmod -R 0750 <ORACLE_HOME_PATH>

3. エクスポータ・スクリプトをカスタムの場所にコピーします:

   1. OUDエクスポータの実行元となるカスタム・ディレクトリを作成します。
   2. 新しいディレクトリの所有権を変更し、mgmt_agentユーザーへの読取りおよび実行アクセス権を、この新しいディレクトリおよびその中のすべてのコンテンツに付与します。

      sudo chown -R mgmt_agent:mgmt_agent <CUSTOM_EXPORTER_DIRECTORY_PATH>

      例:

      sudo chown -R mgmt_agent:mgmt_agent /scratch/exporter/oud_exporter

   3. 管理エージェント・ユーザーとして、manage_exporter.shスクリプトを$AGENT_INST/config/destinations/OCI/services/appmgmt/<Latest_Version>/scripts/oudからカスタム・ディレクトリにコピーします。

4. OUDエクスポータ用の一時パスワード・ファイルを作成します。

   1. ルート・ディレクトリ・ユーザーの場合(cn=Directory Managerなど):

      echo <PASSWORD> | sudo -u mgmt_agent tee
            <FULL_PATH_OF_THE_DIRECTORY_MANAGER_USER_PASSWORD_FILE>/.pw

      例:

      echo <password> | sudo -u mgmt_agent tee /scratch/exporter/oud_exporter/.pw

   2. モニタリング・ユーザーの場合:

      echo <PASSWORD> | sudo -u mgmt_agent tee <FULL_PATH_OF_THE_MONITORING_USER_PASSWORD_FILE>/.mpw

      例:

      echo <password> | sudo -u mgmt_agent tee /scratch/exporter/oud_exporter/.mpw

5. OUDインスタンスのモニタリング・ユーザーを作成します。

   1. mgmt_agentユーザーとして、次を実行します。

      ./manage_exporter.sh adduser --port <ADMINISTRATION_PORT_OF_THE_OUD_INSTANCE> --utype admin --dstype oud -j <FULL_PATH_OF_THE_DIRECTORY_MANAGER_USER_PASSWORD_FILE> --mpw <FULL_PATH_OF_THE_MONITORING_USER_PASSWORD_FILE> --javaHome <JAVA_HOME_PATH>

      例:

      ./manage_exporter.sh adduser --port 4444 --utype admin --dstype oud -j /scratch/exporter/oud_exporter/.pw --mpw /scratch/exporter/oud_exporter/.mpw --javaHome /scratch/install/jdk1.8.0_381/

   2. デフォルトでは、モニタリング・ユーザーの名前はmuserです。これは、--muser <name>で変更できます

6. データベース・サイズを監視するためにOUDデータベースにファイル・システム権限を付与します。

   1. sudo getfacl "<OUD_HOME_DIRECTORY_PATH>/OUD/db"

      例:

      sudo getfacl "/scratch/oud12c/oud_instance/OUD/db"

   2. sudo setfacl -R -m "u:mgmt_agent:rx" "<OUD_HOME_DIRECTORY_PATH>/OUD/db"

      例:

      sudo setfacl -R -m "u:mgmt_agent:rx" "/scratch/oud12c/oud_instance/OUD/db"

7. OUDエクスポータの設定:

   1. mgmt_agentユーザーとして、setupコマンドを実行します。

      ./manage_exporter.sh setup --type <PRODUCT_TYPE> --compartment <COMPARTMENT_ID> --name <RESOURCE_NAME> --instName <RESOURCE_NAME> --ldap <LDAP_PORT> --ldaps <LDAPS_PORT> --oracleHome <ORACLE_HOME_PATH> --adminPort <ADMINISTRATION_PORT_OF_THE_OUD_INSTANCE> --metricPort <METRICS_MONITORING_ENDPOINT_PORT> --javaHome <JAVA_HOME_PATH> -D <NAME_OF_THE_MONITORING USER> -j <FULL_PATH_OF_THE_DIRECTORY_MANAGER_USER_PASSWORD_FILE> 

      例:

      ./manage_exporter.sh setup --type oud --compartment ocid.compartment1.abcdef1234 --name oud_one --instName oud_one --ldap 0 --ldaps 0 --oracleHome /scratch/oud12c --adminPort 4444 --metricPort 1888 --javaHome /scratch/install/jdk1.8.0_381/ -D muser -j /scratch/exporter/oud_exporter/.pw

   2. 管理エージェントを再起動します。

      sudo systemctl restart mgmt_agent

   3. 設定中のその他のオプションについては、helpコマンドを実行してください。

      ./manage_exporter.sh help

   OUDメトリックはPrometheus形式でPromethusエンド・ポイントに収集され、管理エージェントはメトリックをテレメトリにアップロードします。

8. OSのリブート後にOUDエクスポータを起動できるようにします。これにより、mgmt_agentユーザーが管理エージェントおよびエクスポータ・サービスを再起動することもできます。

   sudo ./manage_exporter.sh enable

9. メトリックのフローを確認します。

   1. エクスポータがOUDメトリックを適切に収集していることを確認するには、エクスポータが実行されているホストでメトリック・エンドポイントをコールします。少なくとも40個のメトリックが必要です:

      1. ブラウザで、https://localhost:<METRICS_MONITORING_ENDPOINT_PORT>/metrics - node_exporter資格証明を指定する必要があります。

         例:

         https://localhost:1888/metrics

      2. 端末で:

         curl -u "<NODE_EXPORTER_USER>:<NODE_EXPORTER_PASSWORD>" -sk https://127.0.0.1:1888/metrics

   2. 管理エージェントがメトリックをTelemetryにアップロードしていることを確認するには、エクスポータが起動してから5分後に、OCIでメトリック・エクスプローラを開きます。コンパートメント、oracle_appmgmtメトリック・ネームスペースおよび任意のoudリソース・グループを選択します。メトリックを選択し、適切にレポートされていることを確認します。

exporterコマンド・オプションの設定:

OUDステータス

OUDでは、次に示すいくつかの要因に応じて4つの異なるステータスがサポートされます。

• 稼働中

  すべてのシステムおよびメトリックが正常にフローしている場合、OUDは稼働しています。

• 停止

  BindDNが欠落している場合、LDAPサーバーとの接続に問題があるか、LDAPサーバーが停止している場合、OUDは停止しています。

• メンテナンス

  ユーザーは、インスタンスまたはその他の目的でメンテナンスを実行するために、いつでもOUDをメンテナンス下に置くことができます。

• 警告

  OUDインスタンスは少なくとも1つのサービス・テストに失敗したため、調査する必要があります。

OUDステータスの管理

OUDインスタンスが「メンテナンス」または「稼働中」になるように構成するには、次を実行します:

./manage_exporter.sh modstate <STATUS>  --port <ADMINISTRATION_PORT_OF_THE_OUD_INSTANCE> --dstype oud -j <FULL_PATH_OF_THE_DIRECTORY_MANAGER_USER_PASSWORD_FILE>

OUDの現在の状態を確認するには、次を実行します。

./manage_exporter.sh showstate --port <ADMINISTRATION_PORT_OF_THE_OUD_INSTANCE> --dstype oud -j <FULL_PATH_OF_THE_DIRECTORY_MANAGER_USER_PASSWORD_FILE>

OUDのインポート

OUDは、次のいずれかのリソース・タイプとして個別にインポートおよび監視できます。

• OUDディレクトリ・サーバー
• OUDプロキシ・サーバー
• OUDレプリケーション・ゲートウェイ

次のコマンドを使用して、OUDリソース・タイプをインポートします。

oci stack-monitoring resource-task import-telemetry-resources --compartment-id <compartment id> --namespace oracle_appmgmt --source OCI_TELEMETRY_PROMETHEUS --resource-group <resource group>

各インスタンスではなく、各リソース・タイプをインポートします。たとえば、3つのディレクトリと2つのプロキシがある場合は、インポート・コマンドをタイプごとに2回実行します。

リソースがインポートされた後、新しいOUDインスタンスが追加された場合は、新しく追加されたリソース・タイプに対してインポート・コマンドを再度実行します。

前提条件

Oracle GoldenGate REST APIは、GoldenGateインスタンスをモニターする管理エージェントからアクセスできる必要があります。

httpsプロトコルのみがサポートされるため、GoldenGateインスタンスは必要な証明書で構成する必要があります。

管理エージェントは、TLS接続を検証するための証明書を含むトラストストアJKSファイルにアクセスできる必要があります。

GoldenGate検出入力

前提条件

IISを監視する管理エージェントは、IISが実行されているホストにローカルにデプロイされ、必要な前提条件が完了している必要があります。詳細は、管理エージェントをデプロイするための前提条件の実行を参照してください。

検出中にMicrosoft IISおよびローカル・エージェントが実行されています。

Microsoft IIS検出入力

前提条件

• JMXモニタリングを有効にする必要があります。JMXモニタリングを有効にするには、JMXリモートの有効化を参照してください。

Oracle JVMランタイム検出入力

NGINX検出入力