Hostname Prerequisites

Ensure the hostname -a command returns the correct shortname, as first alias. The shortname appears in the HOST_NAME column of the v$instances table of the database to discover. This can be done by updating the /etc/hosts file to return the correct alias as above to be the first alias.

Agent Prerequisites

The Management Agent user must be available on all the nodes in the cluster.

Each node of the Oracle Database cluster must include:

• A locally installed Management Agent

• Ensure that the mgmt_agent or oracle-cloud-agent user, based on type of agent installed, is included in the Oracle Inventory Group (typically, oinstall) taken from /etc/oraInst.loc, to be able to execute the lsnrctl, srvcrl, and crsctl commands.

  Use the following instruction to grant oinstall privileges to the mgmt_agent or oracle-cloud-agent user , based on type of agent installed:

  • Host with Oracle Cloud Agent:

    usermod -aG oinstall oracle-cloud-agent

  • Host with stand-alone agent:

    usermod -aG oinstall mgmt_agent

• The group must have execute privilege on Oracle install directory.

  Example of adding group execute permission to the directory:

  chmod g+x /u01/app/oracle

After granting the OS privileges, use the following instructions to restart the agent. Use the appropriate instructions for your agent and OS, respectively:

• For Oracle Linux 6 with

  • Oracle Cloud Agent:

    sudo /sbin/initctl stop oracle-cloud-agent

    Then start the agent using the start command.

  • Stand-alone agent:

    sudo /sbin/initctl stop mgmt_agent

    Then start the agent using the start command.

  • For Oracle Linux 7 with

    • Oracle Cloud Agent:

      sudo systemctl stop oracle-cloud-agent

      Then start the agent using the start command.

    • Stand-alone agent:

      sudo systemctl stop mgmt_agent

      Then start the agent using the start command.

Monitoring Credentials Prerequisite

Prior to discovering a database within Stack Monitoring, ensure you have access to the monitoring user. You can either use DBSNMP user that is built-in with the Oracle Database and has the privileges required to monitor the database OR create a custom user with only the necessary privileges . Steps to create a database monitoring user can be found in MOS Note: 2857604.1

For ASM:

• You need to use an ASMSNMP user profile or its privileges.
• User should have secret password for ASM. To get started with creating a secret, see Managing Secrets.

TCPS-enabled Oracle Database Prerequisite

Stack Monitoring supports both TCP and TCPS connectivity protocols for Oracle databases. TCPS protocol enables an Oracle application on a client to communicate with remote databases through TCP/IP and SSL, which provides higher security than TCP alone. This new listener can be used to talk to database via a secure channel. To discover a database with TCPS, the prerequisite would be to add a TCPS listener to the Oracle database and access to the wallet location as shown in the following four steps.

Step 1: Configuring the Oracle Database and listener to support TCPS, see Configuring Transport Layer Security Authentication.

Step 2: Import KeyStore/TrustStore into Management Agent and update its permissions.

1. Identify and export the Oracle Database wallet location according to the KeyStore type used (PKCS or JKS)..

   PKCS

   export WALLET_LOCATION=<database_wallet_location>/dbwallets

   JKS

   export WALLET_LOCATION=<database_wallet_location>/jkswallets

2. Copy the wallet to a secure, readable directory on the agent host.

   cp -r $WALLET_LOCATION <secure_readable_dir>/

3. Update the wallet permission.

   On OCI Compute

   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

   On on-premises Compute:

   PKCS

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

   JKS

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

Step 3: Create an OCI Secret.

To get started with creating a secret, see Managing Secrets.

Secret Examples:

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

Step 4: Validate Policies

In addition to the creation of a secret, the Stack Monitoring admin group must be granted the ability to read the vault where the secret is kept. Please see Create required policies for more information on granting read permission on a secret-family within a specified compartment.

If your Oracle Database is using older password versions

For databases that are configured to use password version less than 12 (SQLNET.ALLOWED_LOGON_VERSION < 12 ), such as certain E-Business Suite databases, follow these additional steps to configure the Management Agent to communicate with the database using older password versions by setting an appropriate SQLNET.ALLOWED_LOGON_VERSION value in the agent configuration.

These instructions apply to the agent running on-premises:

1. Modify this file /opt/oracle/mgmt_agent/agent_inst/config/emd.properties to add the property:

   dbaas.ALLOWED_LOGON_VERSION = 8 

   Values can be 8 / 10 / 11 /12 / 12a depending on the allowed login version you require. For E-Business Suite setups, a value of 8 works for both login versions 8 and 10.

2. Restart the agent.

   sudo systemctl restart mgmt_agent

These instructions apply to the agent running on OCI Compute:

1. Modify the file /var/lib/oracle-cloud-agent/plugins/oci-managementagent/polaris/agent_inst/config/emd.properties to add this property:

   dbaas.ALLOWED_LOGON_VERSION = 8

   Values can be 8 / 10 / 11 /12 / 12a depending on the allowed login version you require. For E-Business Suite setups, a value of 8 works for both login versions 8 and 10.

2. Restart the agent.

   sudo systemctl restart oracle-cloud-agent

Oracle Database Discovery Instructions

• Discovering DB System if Oracle Database has already been discovered
• Discovery Input
  • UI Discovery Input
  • CLI Discovery Input

Discovering DB System if Oracle Database has already been discovered

1. UI Discovery for the first DB System of the cluster :

   From the Resource Discovery page, complete the fill-in-the-blank Oracle Database discovery.

   For more information regarding UI discovery inputs, see the UI Discovery Input table.

2. CLI Discovery for the remaining DB System resources:

   Note
   
   For an Oracle Database that has already been discovered, complete the following steps to discover the related DB System.
   1. Navigate to the Configuration tab within the newly create Oracle Database homepage. Copy the following fields from the General OCI Properties table into a notepad:

      Property Name	CLI Variable Name	Notes
      OCID	<Database_Resource_OCID>
      compartmentId	<Compartment_OCID>
      managementAgentId	<Additional_Agent#_OCID>	This is the OCID of the agent used during the CLI discovery.

   2. Copy the name of the Oracle Database resource from the top of the Stack Monitoring Oracle Database homepage.
   3. Obtain the Management Agent OCID of the other nodes in the cluster:

      1. Navigate to Observability & Management, go to Management Agents, and click Agents.

      2. For each additional agent in the DB System cluster, select the action menu.
      3. Select Copy OCID to clipboard.

         Agent OCID	CLI Variable Name
         1st additional node in cluster	<Additional_Agent1_OCID>
         2nd additional node in cluster (etc)	<Additional_Agent2_OCID>

   4. Update the JSON_INPUT_FILE with the values obtained, and use the following syntax to discover an Oracle DB System:

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

   For more information regarding CLI discovery inputs, see the CLI Discovery Input table.

   The following is a JSON payload examples to discover the remaining DB System resources:

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

For more information regarding refreshing your Oracle DB System, see Oracle Database System Components Refresh.

Oracle Database

Discover an Oracle Database including database system using the UI: From the Resource Discovery page, complete the fill-in-the-blank UI to discover an Oracle Database including database system and its components.

To include multiple agents when discovering a database system for multi-node RAC, complete the following steps:

Discovery Input

• UI Discovery Input

  Input field	Description
  Resource Name	Name of the database
  DNS hostname or SCAN Name	Domain Name System (DNS), or Single Client Access Name (SCAN) for the database
  Port	Port used by the database outside of Oracle Cloud Infrastructure for database connections
  Service Name	Service name for the database outside of Oracle Cloud Infrastructure that will be used by the connection
  Protocol	Protocol used for the Oracle Database. Select either TCP or TCPS protocol
  Database user password secret in <compartment_name> compartment	Select the secret that contains the database user password from the drop-down list. This field is only displayed if TCPS is selected in the Protocol field. See below.
  Management Agents	Management Agents monitoring the host on which the database is installed Note For database systems that span multiple hosts, select all Management Agents deployed on all hosts of the database system.
  Database Credentials for Monitoring	.
  Username	Username of the Oracle Database monitoring credentials
  Password	Password of the Oracle Database monitoring credentials
  Role	Database role of the database monitoring user (Normal or SYSDBA)
  ASM Information
  Management Agent	Management Agent monitoring the host on which the database is installed. For discovering cluster and listener agent should be installed on the database host.
  Automatic Storage Manager	Enable or Disable. Enabled by default.
  DNS hostname or Scan name	The default dns or SCAN name where the ASM instance lives.
  Port	The port used by ASM. Default value: 1521
  Service Name	The ASM service name
  ASM Credentials for Monitoring
  Username	ASM user name
  ASM user password secret in the current compartment	Password secret as defined in OCI Vault service
  Role	SYSMAN by default. Possible values: SYSASM, SYSDBA, SYSOPER
  Discover In
  Stack Monitoring and Logging Analytics (recommended)	Discovery results will be sent to Stack Monitoring and Logging Analytics. Note For information on Logging Analytics, see Quick Start.
  Stack Monitoring only	Discovery results will be sent to Stack Monitoring only.
  Logging Analytics only	Discovery results will be sent to Logging Analytics only.
  License
  Enterprise Edition	The resource will be assigned an Enterprise Edition license.
  Standard Edition	The resource will be assigned an Standard Edition license.
  Tags (under Show advanced options)	Freeform and Defined Tags can be applied to Stack Monitoring resources during discovery. To use Defined Tags first create the Tag namespaces, refer to . Refer to Tags and Tag Namespace Concepts for details on creating and managing the Tag namespaces for Defined Tags. When discovering a resource, any tag assigned will be applied to all the discovered resources. For more information regarding Tag prerequisites and Tag propagation, see Managing Tags.
  Tag Namespace	Select "None" to add a free-form tag. Select a namespace to add a defined tag in the namespace. If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
  Tag Key	Specify the name you use to refer to the tag.
  Tag Value	Specify the tag value. For more details on Tag Key and Tag Value, refer Overview of Tagging.

• CLI Discovery Input

  CLI Input Variable	Description
  <Additional_Agent1_OCID>	1st additional node in cluster
  <Additional_Agent2_OCID> (etc)	2nd additional node in cluster (continue for each additional node in the cluster)
  Agent_OCID	Agent of the initial discovery OCID
  Compartment_OCID	The compartment OCID where the Oracle Database System will be monitored

Prerequisites

If you have enabled the Oracle WebLogic Server with SSL, export the certificate from its keystore and import it in the Management Agent KeyStore. For more information about configuring SSL in WebLogic Server, see Configuring SSL.

Import TrustStore to the Management Agent

1. Designate a persistent subdirectory on the management agent's filesystem to hold the Stack Monitoring truststores and keystores. Export the certificate from the WLS instance JMX SSL keystore to the Stack Monitoring Truststore. For example, on a UNIX host:

   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. Import the WLS instance JMX SSL keystore to the Stack Monitoring Truststore on the management agent's filesystem.:

   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. Copy Stack Monitoring Truststore file and update its permissions.

   Identify Management Agent readable secure location on the agent host.

   cp <path_to_truststore_file/AgentTrust.jks <secure_readable_dir>/

   On OCI Compute:

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

   On on-premises Compute:

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

4. Use the full Truststore path, e.g. <secure_readable_dir>/AgentTrust.jks in the "TrustStore Path" of Resource Discovery if WebLogic Domain with T3S and "JKS" as the "Truststore Type".

Configure MBeans on Oracle WebLogic Servers

To collect the JVM performance metrics from platform MBeans, the MBeans must be made accessible through the runtime MBeanServer. Activate MBeans by logging in to your Oracle WebLogic Server and verify the activation by running the WLST script:

1. Activate MBeans on Oracle WebLogic Servers

   Activate MBeans by accessing each Oracle WebLogic Server by logging into it or from the WebLogic console as follows:

   • Log in to your Oracle WebLogic Server:

     Follow the user actions in the WebLogic Scripting Tool session demostration at Activating Platform MBeans on WebLogic Server 9.x to 10.3.2 versions in Enterprise Manager Cloud Control Middleware Management Guide.

   • Access your WebLogic console:

     Navigate to Domain > Configuration > General page > Advanced options. Select the Platform MBean Server Used check box.

   If MBeans are not registered after you’ve followed the above steps, then start the Oracle WebLogic Servers with the following system property:

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

2. Verify the Activation of MBeans

   To verify if MBeans is successfully activated, run the WLST script that’s available at Using the Platform MBean Server in Fusion Middleware Developing Custom Management Utilities With JMX for Oracle WebLogic Server. The WLST script demonstrates how to use the Platform MXBeans to monitor the resources of a running Oracle WebLogic Server domain.

   Ensure that MBeans are registered under java.lang.

Ensure connectivity between management agent and all servers in WebLogic

During the discovery the Stack Monitoring Agent communicates with AdminServer for discovering the domain topology. Post discovery monitoring is done by communicating with managed servers directly. For this to happen, verify the following:

• Management Agent is able to communicate with all managed servers in the domain.
• The host and ports of the managed servers are accessible to the agent.
• If filters are configured to block incoming traffic on managed servers, adjust the filters for the agent to communicate with the managed servers.

WebLogic Discovery Input

Prerequisites

1. Configure MBeans on Oracle WebLogic Servers
2. Verify Collection of Forms Sessions Data
3. Set Up DNS in an Oracle E-Business Suite Environment
4. Add the Database used by the E-Business Suite application.

   If you haven't already done so, add the database that will be used for the E-Business Suite application. Refer to Oracle Database (Discovery)

5. E-Business Suite Database Monitoring Requirements for Stack Monitoring

Verify Collection of Forms Sessions Data

Verify the collection of forms sessions data to view it later in the Forms System resource metrics by performing the following task. This is in addition to the steps performed in Oracle WebLogic Domain (Configure MBeans on Oracle WebLogic Servers). If this step is not configured, some of the Forms System metrics will not be collected.

When you log in to Oracle E-Business Suite, the system creates a user session in the database identified by a unique session ID (SID) by using the APPS schema credential. Each database session is associated with an Oracle E-Business Suite application user. This enables linking the database session with the application user for troubleshooting purposes. Using a Forms session, you can determine how the Oracle E-Business Suite user opened a database session.

1. Log in to your Oracle E-Business Suite.
2. From the user interface, navigate to System Administrator, click Profile, and then System.
3. Ensure that the value of Sign-On: Audit Level is set to FORM. Set this at the site level.
4. Ensure that the value of AuditTrail: Activate is set to YES.

Save the changes.

Set Up DNS in an Oracle E-Business Suite Environment

The Oracle E-Business Suite hosts must be able to detect one another on the network. For example, in the UNIX environment, the DNS servers are configured in the file /etc/resolv.conf on each host.

To verify that the DNS servers are configured correctly, run the command:

nslookup any_publicDomain_hostname

E-Business Suite Database Monitoring Requirements for Stack Monitoring

The Oracle database used to monitor the E-Business Suite (EBS) database should be discovered before discovering the EBS application. If the database is discovered first, it will be automatically associated with the EBS application once the EBS application discovery completes. If the EBS application discovery is performed before the database has been discovered, the association will need to be created manually. See Updating Application Topology for more information.

Monitoring E-Business Suite requires specific privileges to access the EBS schema. The setup differs depending on type of database (Non-Container DB versus Container DB and Pluggable DB) used as your EBS datastore. Stack Monitoring supports the use of the EBS schema owner, typically APPS, as the database credentials when discovering EBS. It is preferred to create a monitoring user with only the privileges necessary to monitor an EBS application. You can use the same database user to monitor both the Oracle database containing the EBS schema and the EBS application. Steps to create a database monitoring user can be found in MOS Note: 2857604.1.

Database Grants

The specific privileges are defined in the code below. It assumes the EBS schema name of APPS. If the schema name is different in your setup, then replace APPS with the actual schema name in the following code.

To verify the monitoring user has the necessary grants, and apply any missing grants, execute the following EBS Scripts.

To understand the specific grants to be applied, or to manually apply the apply the grants, see the list of commands below to be executed.

Replace <your_monitoring_user> with the database monitoring user created using the script. Ensure the grants are applied to the monitoring user where the APPS schema resides.

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

Connect to the database that contains the EBS schema as SYSTEM user and execute the following grant:

GRANT INHERIT PRIVILEGES ON USER <your_monitoring_user> TO APPS

E-Business Discovery Input

Discover PeopleSoft Database

The Oracle Database containing the PeopleSoft (PSFT) schema should be discovered before discovering the PeopleSoft application. If the database is discovered first, the database will be automatically associated with PeopleSoft application once PeopleSoft resource discovery completes

If PeopleSoft application discovery is performed before the database has been discovered, the association will need to be created manually. See Updating Application Topology for more information.

To Discover the Oracle Database, see Oracle Database.

DB Grant Privileges for PeopleSoft Monitoring

Monitoring PeopleSoft (PSFT) requires specific privileges to access the PSFT database schema. The setup differs depending on type of database (Non-Container DB versus Container DB and Pluggable DB) used as your PSFT datastore. Stack Monitoring supports the use of the PSFT schema owner, typically SYSADM, as the database credentials when discovering PSFT. It is preferred to create a monitoring user with only the privileges necessary to monitor a PSFT application. You can use the same database user to monitor both the Oracle database containing the PeopleSoft schema and the PeopleSoft application. Steps to create a database monitoring user can be found in MOS Note: 2857604.1.

To verify the monitoring user has the necessary grants, and apply any missing grants, execute the following PeopleSoft Scripts.

To understand the specific grants to be applied, or to manually apply the apply the grants, see the list of commands below to be executed.

Database Privileges

• PeopleSoft Application Grants

  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 Application Synonyms

  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 Grants

  GRANT SELECT ON SYSADM.PS_PTSF_SRCH_ENGN TO <your_monitoring_user>;

• Elasticsearch Synonyms

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

• Process Monitor Grants

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

• Process Monitor Synonyms

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

Enable PeopleSoft Performance Monitor for Pure Internet Architecture (PIA)

1. Navigate to PeopleTools, go to Web Profile, click Web Profile Configuration, and search for the profile in use, for example, PROD.
2. If not checked already, check the Enable PPM Agent check box.
3. Restart all PIA domains.

Prerequisites for Application Server and Process Scheduler Domains

Enable the PeopleSoft Performance Monitor Agent

1. Using PSADMIN command-line interface, select Application Server (Option 1) or Process Scheduler (Option 2) > Administer a domain (Option 1) > select domain > Edit configuration/log files menu(option 6) > Edit domain configuration file (Option 1) , this will open up the domain configuration files in edit mode

2. under the PSTOOLS section, check the value for EnablePPM Agent. To Enable PPM Agents, set the value to 1, and save the file.

Enable JMX Agents

This prerequisite enables Stack Monitoring to collect availability and performance data for a PeopleSoft application.

1. Using PSADMIN command-line interface, select Application Server (Option 1) or Process Scheduler (Option 2) > Administer a domain (Option 1) > select domain > Edit configuration/log files menu(option 6) > Edit domain configuration file (Option 1) , this will open up the domain configuration files in edit mode

2. Locate settings for PSTOOLS section and set below values

   1. Ensure that the Remote Administration Port you intend to use is not being utilized by any other process on the host.

   2. UserID

      • UserId should be in text format.

      • The same UserId and password should be used for all application server domains and process scheduler domains.

   3. Use the PSCipher utility to encrypt the password.
   4. Restart the Application server and Process Scheduler domains after configuring the Performance Collator property change below.

3. • For PSFT version 8.59 and earlier only Remote Administration Port needs to be set. RMI port value will be set automatically based on the Remote Administration Port value incremented by 1. For example, if the Remote Administration Port is 10100, then port 10101 will be used for PHC's RMI server. When you plan the port usage, this needs to be taken into account. Since 10101 is picked automatically in the above example, if that port is not free PSFT automatically picks any other random free port. Please ensure to review the domain configuration file after the configuration has been successfully saved and use these ports to connect in discovery.

     Example:

     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>

   • For PSFT version 8.60 onwards, RMI port is controlled by one additional parameter in the config file. Ensure the value is set explicitly. Restart the Application server and Process Scheduler domains after configuring the Performance Collator property.

     Example:

     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>

   Note
   
   Please ensure that the above saved setting shows correctly in the configuration file after the changes are saved.

Enable the Performance Collator Property

You can check the current value of Perf Collator in domain template files psprcsrv.ubx (Process scheduler) and psappsrv.ubx (Application Server) located under $PS_CFG_HOME

If the Perf Collator is enabled , you will see entry as below.

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

If the Perf Collator is disabled , You would see entry as below.

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

If the Performance Collator is already enabled, and changes were implemented to EnablePPM Agent or JMX values: Restart all domains.

If the Performance Collator is not already enabled proceed with the following steps:

1. Using PSADMIN command-line interface, select Application Server (Option 1) or Process Scheduler (Option 2) > Administer a domain (Option 1) > select domain > Configure this domain (Option 4)
2. Enter y for the question: Do you want to continue (y/n). This option will shutdown the domain

3. Check value of Perf Collator property.

4. If the value set to Yes, Collator is already enabled, no action is required. Then select Load config as shown (Option 14 for Application Server or Option 7 for Process Scheduler)

5. If the value set to No, enter 10 for Application server or Option 3 for Process scheduler to toggle the value to Yes

6. After confirming Perf Collator set to Yes, select Load config as shown (Option 14 for Application scheduler or Option 7 for Process scheduler )

7. Finally select Boot this domain Option 1 to start the domain

Identify Domains to be Discovered

Stack Monitoring leverages the information stored within the Oracle Database to identify domains to be discovered or refreshed. To validate the list of current domains, execute the following query.

SELECT * FROM PSPMAGENT;

Any domains returned by the query that no longer exist should be removed prior to discovering/refreshing the PeopleSoft Application.

To add a domain that is not listed, see Adding domains manually.

To remove the stale domains execute the following SQL as SYSADM or equivalent user. Repeat steps until all Stale domains removed.

• Backup the PSPMAGENT table prior to making changes. Ensure to replace <DATE> with the current timestamp.

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

• Verify the backup table created has same content as parent table.

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

If the count of rows from PSPMAGENT match PSPMAGENT_BKP_<DATE>, proceed with the removal of stale domains.

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

Adding domains manually

Finally, check whether all valid domains are visible from the PSPMAGENT table. If any valid domains are not showing up for any reason, follow the instructions below:

Create a backup:

1. As system administrator or equivalent user take a backup of the table prior to making changes. Ensure to replace <DATE> with the current time stamp:

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

2. Verify the backup table created has same content as parent table. The rows count from PSPMAGENT should match the rows count from PSPMAGENT_BKP_<DATE>:

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

Add a Process Scheduler Domain

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

Example:

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.

Add an Application Server Domain

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

Example:

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')

Add a PIA Server

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

Example:

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.

Enable Elasticsearch discovery in PeopleSoft

Elasticsearch discovery is optional. If Elasticsearch is already integrated then you can include it in the initial discovery. To integrate Elasticsearch in the future, use the PeopleSoft CLI refresh command, and add the Elasticsearch DB grants to the monitoring user. For more information regarding grants, see DB Grant Privileges for PeopleSoft Monitoring, and for more information regarding CLI refresh commands, see PeopleSoft Refresh.

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

These prerequisites enable Elasticsearch Integration in PeopleSoft:

• Stack Monitoring only supports monitoring Elasticsearch configured with SSL. Its endpoint must be HTTPS. For more information on the setup of Elasticsearch, see Configuring SSL for Elasticsearch

• Before discovering Elasticsearch, create a JKS truststore, as JKS is the only supported type of trust stores, on the monitoring agent host to store the certificate from Elasticsearch. This truststore's location and password are required parameters in the discovery UI or in the discovery JSON while performing discovery via CLI, while the trust store location has to be accessible on the agent host.

  Example:

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

Enable Process Monitor discovery for PeopleSoft

• Process Monitor is discovered alongside PeopleSoft, and is enabled by default when discovering a PeopleSoft Application. Selecting No under the Discover Process Monitor section will not include Process Monitor in the PeopleSoft discovery.
• Process Monitor discovery is optional. If Process Monitor is enabled already then you can include it in the initial discovery. To integrate Process Monitor in the future, use the PeopleSoft CLI refresh command, and add the Process Monitor DB grants to the monitoring user. For more information regarding grants, see DB Grant Privileges for PeopleSoft Monitoring, and for more information regarding CLI refresh commands, see PeopleSoft Refresh.

• There are no properties required for Process Monitor discovery

• User-Interface

  • Process Monitor discovery is included by default. To opt out, select No under Discover Process Monitor in the Resource discovery panel.

Prerequisites

• Enable JMX monitoring. See Enabling JMX Remote.
  Note
  
  Tomcat monitoring does not support SSL. SSL will be disabled by default when following Tomcat documentation.

Apache Tomcat Discovery Input

For more information regarding input parameters, see JSON Input Parameters

Prerequisites

Create a Custom Database User

To enable monitoring for a Microsoft SQL Server Database, you can create a special database user as follows.

Create a user (for example, monstk) and map the new user to the master and msdb databases. Then, give this user the following minimum privileges.

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

Map the user to all system and user databases:

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 Discovery Input

Prerequisites

WebLogic needs to be discovered prior to discovering Managed File Transfer (MFT). When discovering MFT, on the discovery UI, select the corresponding WebLogic from the drop down list.

Database Monitoring Requirements for Stack Monitoring

The Oracle database should be discovered before discovering the MFT application. If the database is discovered first, it will be automatically associated with the MFT application once the MFT application discovery completes. If the MFT application discovery is performed before the database has been discovered, the association will need to be created manually. See Updating Application Topology for more information.

Monitoring a Managed File Transfer application requires specific privileges to access the MFT schema. Stack Monitoring supports the use of the MFT schema owner, typically DEV_MFT, as the database credentials when discovering MFT. It is preferred to create a monitoring user with only the privileges necessary to monitor a MFT application. You can use the same database user to monitor both the Oracle database containing the MFT schema and the MFT application. Steps to create a database monitoring user can be found in MOS Note: 2857604.1.

The specific privileges are defined in the code below. It assumes the MFT schema name of DEV_MFT. If the schema name is different in your setup, then replace DEV_MFT with the actual schema name in the following code. Replace <user> with the database monitoring user created using the script. Ensure the grants are applied to the monitoring user created where the DEV_MFT schema resides.

Database permissions:

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

Discovery Input

Collocated OHS

Collocated OHS Discovery is part of Weblogic Domain Discovery and all of its prerequisites apply.

For more information about installing collocated OHS, see About the Oracle HTTP Server Installation.

Standalone OHS

Supported versions:

• version 11.x - local monitoring only, Linux host, OPMN tool used for metric collection.

• version 12.x - local monitoring only, Linux host, WLST tool used for metric collection

Prerequisites:

• The Management Agent should be installed on the same host as the standalone Oracle HTTP Server.

• The OHS configuration file (httpd.conf) should be accessible and readable by the Management Agent install user (mgmt_agent for standalone agent and oracle-cloud-agent for Oracle Cloud Agent).

OHS version 11.x:

Version 11.x OHS collects metrics using the OPMN tool. The OPMN tool should be accessible and readable by the Management Agent install user (mgmt_agent for standalone agent and oracle-cloud-agent for Oracle Cloud Agent).

OHS version 12.x:

Version 12.x OHS collects metrics using the WLST tool. The WLST tool should be accessible and readable by the Management Agent install user (mgmt_agent for standalone agent and oracle-cloud-agent for Oracle Cloud Agent).

OHS version 11.x Discovery Input

OHS version 12.x Discovery Input

Prerequisites

• The Management Agent should be installed on the same host as Apache HTTP Server.
• Enable mod_status Apache module (https://httpd.apache.org/docs/2.4/mod/mod_status.html). Configure /server-status location directive for the specified Hostname and Port.

  Example:

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

• Turn ON the ExtendedStatus directive (https://httpd.apache.org/docs/2.4/mod/core.html#extendedstatus).
• If applicable, provide access control to the configured /server-status location directive so that HTTP/HTTPS requests can be successfully made from the host on which the Agent is installed. The Agent only supports Basic Authentication with an HTTPS connection if required. For more information regarding configuring additional access control, see Apache Documentation, Authentication and Authorization.

• The Apache binary files should be accessible and executable by the Management Agent install user:

  • The Apache *.conf file(s) , including httpd.conf file, should be accessible and readable by the Management Agent install user (mgmt_agent for standalone agent and oracle-cloud-agent for Oracle Cloud Agent).
  • The Apache binary file (httpd) should be accessible and executable by the Management Agent install user (mgmt_agent for standalone agent and oracle-cloud-agent for Oracle Cloud Agent).
  • The Apache pid file (httpd.pid) should be accessible and readable by the Management Agent install user (mgmt_agent for standalone agent and oracle-cloud-agent for Oracle Cloud Agent)..

Here is an example of how to add all the required permissions for the management agent user by creating a dedicated apache administrator user group and adding the management agent user to it:

#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 Discovery Input

Prerequisites

• Deploy Management Agent with Stack Monitoring plugin.
• Set up monitoring user in OUD:
  • Create monitoring user with minimal privileges to perform ldap search operations to the DN (Distinguished Name) of cn=monitor to collect metrics for all OUD resources. Set up the exporter as mentioned below with the monitoring user you created.
    Note
    
    The use of OUD's admin user (RootDN) is not supported to setup the exporter.

Setup Exporter

The exporter will collect metrics from OUD and create an endpoint to expose the metrics in Prometheus format. These metrics will then be uploaded by the Management Agent.

The exporter needs to be setup for each instance of each installation mode. For example, if there are 3 directories and 2 proxies, the exporter will have to be setup 5 times.

1. Create a new directory for the exporter configuration.
   1. Make sure the Management Agent user has read and execute permission to this location.
2. Copy all the scripts in$AGENT_INST/config/destinations/OCI/services/appmgmt/<Latest_Version>/scripts/oud into the new directory.
   1. Once the exporter is configured, exporter config files will be created in this location.
   2. Ensure that this directory is not deleted at any time.

3. Setup the exporter with the following command:

   ./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>

   Note
   
   

   The user that executes the exporter setup must have execution privileges in ldapsearch under OUD's Oracle home.

   Option	Description
   type	Type of OUD that is being configured: oud, proxy or replgw.
   compartment	Compartment Id.
   resName	Resource Name of the OUD instance. This value must be unique and will be uploaded as a dimension for each metric.
   oracleHome	Oracle Home of the OUD application.
   auser	Management agent user: mgmt_agent or oracle-cloud-agent.
   adir	Management agent instance installation directory. i.e. /opt/oracle/mgmt_agent/agent_inst
   adminPort	Administration port of the OUD instance.
   metricPort	New port to be used to expose metrics in Prometheus format. This port must be available prior setup.
   javaHome	Java Home path.
   pnum	OUD identifier for the new instance to be created. This must be a positive integer unique per instance.
   D	Monitoring user without "cn=" prefix.

   After the above command, the exporter will be configured to run at a 2 minute interval by default.

4. When running the setup you will be asked to enter the monitoring user password twice.
5. To validate the setup was done successfully, access the metrics endpoint in https://localhost:<metricPort>/metrics. To access this endpoint, the user is always exporter and the password is the monitoring user password.

Import OUD

OUD can be independently imported and monitored as one of the following resource types:

• OUD Directory Server
• OUD Proxy Server
• OUD Replication Gateway

Import OUD resource types with the following command:

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

Import each resource type, not each instance. For example, if there are 3 directories and 2 proxies, run the import command 2 times, once for each type.

After the resources are imported, if a new OUD instance is added, execute the import command again for the newly added resource type.

Prerequisites

Oracle GoldenGate REST APIs must be accessible from the Management Agent which will monitor the GoldenGate instance.

Only https protocol is supported, so the GoldenGate instance must be configured with required certificates.

Management Agent must have access to the Truststore JKS file which contains the certificate to validate TLS connection.

GoldenGate Discovery Input