ホスト名前提条件

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

エージェントの前提条件

管理エージェント・ユーザーは、クラスタ内のすべてのノードで使用できる必要があります。

Oracle Databaseクラスタの各ノードには次のものが含まれている必要があります。

• ローカルにインストールされた管理エージェント

• lsnrctl、srvcrlおよび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

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

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

  chmod g+x /u01/app/oracle

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

• Oracle Linux 6の場合

  • Oracle Cloudエージェント:

    sudo /sbin/initctl stop oracle-cloud-agent

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

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

    sudo /sbin/initctl stop mgmt_agent

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

  • Oracle Linux 7の場合

    • Oracle Cloudエージェント:

      sudo systemctl stop oracle-cloud-agent

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

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

      sudo systemctl stop mgmt_agent

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

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

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

ASMの場合:

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

TCPS対応のOracle Databaseの前提条件

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

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

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

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

   PC

   export WALLET_LOCATION=<database_wallet_location>/dbwallets

   ロック

   export WALLET_LOCATION=<database_wallet_location>/jkswallets

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

   cp -r $WALLET_LOCATION <secure_readable_dir>/

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

   OCIコンピュート

   PC

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

   ロック

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

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

   PC

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

   ロック

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

ステップ3: OCIシークレットの作成

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

シークレットの例:

PC

{
    "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"
}

ロック

{
    "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: ポリシーの検証

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

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の値を指定できます。E-Business Suiteの設定では、ログイン・バージョン8と10の両方に対して値8が機能します。

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の値を指定できます。E-Business Suiteの設定では、ログイン・バージョン8と10の両方に対して値8が機能します。

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リソースの名前をStack Monitoring 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 password secret  in BASE64 encoded format>",
                 "ASMRole":"<ASM user role in base64 encoded format>"
               }
             }
           }
         ]
       }
     }
   }

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

Oracle Database

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

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

検出入力

• UI検出入力

  入力フィールド	説明
  リソース名	データベースの名前
  DNSホスト名またはSCAN名	ドメイン・ネーム・システム(DNS)またはデータベースの単一クライアント・アクセス名(SCAN)
  ポート	Oracle Cloud Infrastructure外部のデータベースがデータベース接続に使用するポート
  サービス名	接続で使用されるOracle Cloud Infrastructure外のデータベースのサービス名
  プロトコル	Oracle Databaseに使用されるプロトコル。TCPまたはTCPSプロトコルのいずれかを選択します
  <compartment_name>コンパートメントのデータベース・ユーザー・パスワード・シークレット	ドロップダウン・リストから、データベース・ユーザー・パスワードを含むシークレットを選択します。このフィールドは、「プロトコル」フィールドでTCPSが選択されている場合にのみ表示されます。次を参照してください。
  Management Agent	データベースがインストールされているホストをモニターする管理エージェント ノート 複数のホストにまたがるデータベース・システムの場合、データベース・システムのすべてのホストにデプロイされているすべての管理エージェントを選択します。
  モニタリング用のデータベース資格証明	。
  ユーザー名	Oracle Databaseモニタリング資格証明のユーザー名
  パスワード	Oracle Databaseモニタリング資格証明のパスワード
  ロール	データベース・モニタリング・ユーザーのデータベース・ロール(通常またはSYSDBA)
  ASM情報
  管理エージェント	データベースがインストールされているホストをモニターする管理エージェント。クラスタおよびリスナー・エージェントを検出するには、データベース・ホストにインストールする必要があります。
  自動ストレージ・マネージャ	有効化または無効化デフォルトでは有効になっています。
  DNSホスト名またはスキャン名	ASMインスタンスが存在するデフォルトのdnsまたはSCAN名。
  ポート	ASMで使用されるポート。デフォルトの値1521
  サービス名	ASMサービス名
  モニタリング用のASM資格証明
  ユーザー名	ASMユーザー名
  現在のコンパートメントのASMユーザー・パスワード・シークレット	OCI Vaultサービスで定義されているパスワード・シークレット
  ロール	デフォルトではSYSMANです。可能な値: SYSASM、SYSDBA、SYSOPER
  Discover In
  スタック・モニタリングとログ・分析(推奨)	検出結果はスタック・モニタリングおよびログ・アナリティクスに送信されます。 ノート ログ・アナリティクスの詳細は、クイック・スタートを参照してください。
  スタック・モニタリングのみ	検出結果はスタック・モニタリングにのみ送信されます。
  ログ・分析のみ	検出結果はログ・アナリティクスにのみ送信されます。
  ライセンス
  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

事前設定

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

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

1. 管理エージェントのファイルシステム上の永続的なサブディレクトリを指定して、Stack Monitoringトラストストアおよびキーストアを保持します。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キーストアを管理エージェントのファイル・システムのスタック・モニタリング・トラストストアにインポートします。

   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およびトラストストア・タイプとしてJKSを含むWebLogicドメインの場合は、リソース検出のTrustStoreパスに<secure_readable_dir>/AgentTrust.JKSなどの完全なトラストストア・パスを使用します。

Configure MBeans on Oracle WebLogic Servers

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

1. Activate MBeans on Oracle WebLogic Servers

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

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

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

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

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

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

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

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

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

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

管理エージェントとWebLogic内のすべてのサーバー間の接続を保証します。

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

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

WebLogic検出入力

前提条件

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

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

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

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

次のタスクを実行して、フォーム・セッション・データの収集を検証し、後でフォーム・システム・リソース・メトリックで表示します。This is in addition to the steps performed in Oracle WebLogic Domain (Configure MBeans on Oracle WebLogic Servers).このステップが構成されていない場合、一部のフォーム・システム・メトリックは収集されません。

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

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

変更を保存します。

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

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

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

nslookup any_publicDomain_hostname

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

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

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

データベース権限

特定の権限は、次のコードで定義されます。EBSスキーマ名APPSを想定しています。設定でスキーマ名が異なる場合は、次のコードでAPPSを実際のスキーマ名に置き換えます。

モニタリング・ユーザーに必要な権限が付与されていることを確認し、欠落している権限を適用するには、次のEBSスクリプトを実行します。

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

<your_monitoring_user>を、スクリプトを使用して作成されたデータベース監視ユーザーに置き換えます。APPSスキーマが存在するモニタリング・ユーザーに付与が適用されていることを確認します。

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>;

SYSTEMユーザーとしてEBSスキーマを含むデータベースに接続し、次の権限を実行します。

GRANT INHERIT PRIVILEGES ON USER <your_monitoring_user> TO APPS

E-Business Discoveryの入力

Discover PeopleSoftデータベース

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

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

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

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

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

モニタリング・ユーザーに必要な権限が付与されていることを確認し、欠落している権限を適用するには、次の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付与

  GRANT SELECT ON SYSADM.PS_PTSF_SRCH_ENGN TO <your_monitoring_user>;

• Elasticsearchシノニム

  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コマンドライン・インタフェースを使用して、「アプリケーション・サーバー」(オプション1)または「Process Scheduler」(オプション2)→「ドメインの管理」(オプション1)を選択し、「ドメイン」→「構成/ログ・ファイルの編集」メニュー(オプション6)→「ドメイン構成ファイルの編集」(オプション1)を選択して、ドメイン構成ファイルを編集モードで開きます

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

JMXエージェントの有効化

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

1. PSADMINコマンドライン・インタフェースを使用して、「アプリケーション・サーバー」(オプション1)または「Process Scheduler」(オプション2)→「ドメインの管理」(オプション1)を選択し、「ドメイン」→「構成/ログ・ファイルの編集」メニュー(オプション6)→「ドメイン構成ファイルの編集」(オプション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]:

「Perf Collator」が「disabled」の場合、次のようにエントリが表示されます。

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

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

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

1. PSADMINコマンドライン・インタフェースを使用して、「アプリケーション・サーバー」(オプション1)または「Process Scheduler」(オプション2)→「ドメインの管理」(オプション1)を選択し、「ドメイン」を選択→「このドメインの構成」(オプション4)を選択します。
2. 質問にyと入力します: Do you want to continue (y/n)。このオプションはドメインを停止します

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

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

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

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

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

検出するドメインの識別

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

SELECT * FROM PSPMAGENT;

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

一覧表示されないドメインを追加するには、Adding Domains Manuallyを参照してください。

古いドメインを削除するには、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検出の有効化

Elasticsearch検出はオプションです。Elasticsearchがすでに統合されている場合は、最初の検出に含めることができます。将来、Elasticsearchを統合するには、PeopleSoft CLI refreshコマンドを使用し、Elasticsearch 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でのElasticsearch統合が可能になります:

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

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

  例:

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

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

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

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

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

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

前提条件

• 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検出入力

前提条件

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

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

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

管理対象ファイル転送アプリケーションを監視するには、MFTスキーマにアクセスするための特定の権限が必要です。スタック・モニタリングでは、MFTスキーマ所有者(通常はDEV_MFT)を、MFTの検出時のデータベース資格証明として使用できます。MFTアプリケーションの監視に必要な権限のみを持つ監視ユーザーを作成することをお薦めします。同じデータベース・ユーザーを使用して、MFTスキーマを含むOracleデータベースとMFTアプリケーションの両方を監視できます。データベース監視ユーザーを作成するステップは、MOSノート: 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ドメイン検出の一部であり、その前提条件がすべて適用されます。

コロケーションされたOHSのインストールの詳細は、Oracle HTTP Serverのインストールについてを参照してください。

スタンドアロンOHS

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

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

• バージョン12.x - ローカル監視のみ、Linuxホスト、メトリック収集に使用されるWLSTツール

前提条件:

• 管理エージェントは、スタンドアロンOracle HTTP Serverと同じホストにインストールされている必要があります。

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

OHSバージョン11.x:

バージョン11.x OHSは、OPMNツールを使用してメトリックを収集します。OPMNツールは、管理エージェントのインストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合はoracle-cloud-agent)によってアクセスおよび読取り可能である必要があります。

OHSバージョン12.x:

バージョン12.x OHSは、WLSTツールを使用してメトリックを収集します。WLSTツールは、管理エージェントのインストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合はoracle-cloud-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)をONにします。
• 該当する場合は、構成された/server-status locationディレクティブに対するアクセス制御を指定して、エージェントがインストールされているホストからHTTP/HTTPSリクエストが正常に実行できるようにします。エージェントは、必要に応じてHTTPS接続を使用したBasic認証のみをサポートします。追加のアクセス制御の構成の詳細は、Apacheのドキュメント、認証および認可を参照してください。

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

  • Apacheの*.confファイル(httpd.confファイルを含む)は、管理エージェントのインストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合はoracle-cloud-agent)からアクセスおよび読取りできる必要があります。
  • Apacheバイナリ・ファイル(httpd)は、管理エージェントのインストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合はoracle-cloud-agent)によってアクセスおよび実行可能である必要があります。
  • Apacheのpidファイル(httpd.pid)は、管理エージェントのインストール・ユーザー(スタンドアロン・エージェントの場合はmgmt_agent、Oracle Cloud Agentの場合は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でモニタリング・ユーザーを設定します。
  • 最小限の権限を持つモニタリング・ユーザーを作成し、cn=monitorのDN (識別名)に対してldap検索操作を実行して、すべてのOUDリソースのメトリックを収集します。作成したモニタリング・ユーザーで、次に示すようにエクスポータを設定します。
    Note
    
    The use of OUD's admin user (RootDN) is not supported to setup the exporter.

エクスポータの設定

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

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

1. エクスポータ構成用の新しいディレクトリを作成します。
   1. 管理エージェント・ユーザーに、この場所に対する読取りおよび実行権限があることを確認してください。
2. $AGENT_INST/config/destinations/OCI/services/appmgmt/<Latest_Version>/scripts/oud内のすべてのスクリプトを新しいディレクトリにコピーします。
   1. エクスポータが構成されると、エクスポータ構成ファイルがこの場所に作成されます。
   2. このディレクトリが常に削除されていないことを確認します。

3. 次のコマンドを使用してエクスポータを設定します。

   ./manage_exporter.sh setup --type <type> --compartment <compartment id> --resName <resource name> --oracleHome <oracle home path> --auser <auser> --adir <adir> --adminPort <administration port> --metricPort <metrics port> --javaHome <JAVA_HOME path> --pnum <pnum> -D <monitoring user>

   ノート
   
   

   エクスポータ設定を実行するユーザーは、OUDのOracleホームの下のldapsearchで実行権限を持っている必要があります。

   オプション	説明
   タイプ	構成されているOUDのタイプ: OUD、proxyまたはreplgw。
   コンパートメント	コンパートメントID
   resName	OUDインスタンスのリソース名。この値は一意である必要があり、各メトリックのディメンションとしてアップロードされます。
   oracleHome	OUDアプリケーションのOracle Home。
   ユーザー	管理エージェント・ユーザー: mgmt_agent またはoracle-cloud-agent。
   ワラジムシ	管理エージェント・インスタンスのインストール・ディレクトリ。例: /opt/oracle/mgmt_agent/agent_inst
   adminPort	OUDインスタンスの管理ポート。
   metricPort	Prometheus形式でメトリックを公開するために使用される新しいポート。このポートはセットアップの前に使用可能にする必要があります。
   javaHome	Javaホーム・パス。
   pnum	作成する新規インスタンスのOUD識別子。これは、インスタンスごとに一意の正の整数である必要があります。
   D	"cn="接頭辞なしでユーザーをモニタリングしています。

   前述のコマンドの後、エクスポータはデフォルトで2分間隔で実行するように構成されます。

4. 設定を実行すると、モニタリング・ユーザーのパスワードを2回入力するよう求められます。
5. 設定が正常に実行されたことを確認するには、https://localhost:<metricPort>/metricsのメトリック・エンドポイントにアクセスします。このエンドポイントにアクセスするには、ユーザーは常にエクスポータであり、パスワードはユーザー・パスワードの監視です。

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

• 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つのプロキシがある場合、インポート・コマンドをタイプごとに1回2回実行します。

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

前提条件

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

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

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

GoldenGate検出入力