A Monitoring Prerequisites and Credentials
This appendix contains additional prerequisite and monitoring credential information for specific entities.
Host
| Prerequisites |
|---|
|
The operating system user used to install the Cloud Agent is also used as the host monitoring credential. Your hosts are automatically added as entities when a Cloud Agent is installed. However, hosts are not automatically monitored. To enable monitoring for host entities, see Download and Customize Oracle Infrastructure Monitoring JSONs. |
Docker Engine / Docker Container
| Docker Engine/Docker Container Configuration |
|---|
|
You can configure a Docker Engine for monitoring in three ways: Non-Secure Mode: This mode doesn’t need any credentials information. When the Docker Engine is configured in the non-secure mode (http), you simply need the Base URL to connect to the Docker Engine. For example, a Base URL could be: To check if your Docker Engine is configured in non-secure mode, view the You will need to provide the Docker Engine Base URL in the entity definition JSON file. Secure Mode: To check if your Docker Engine is configured in Secure Mode, view the /etc/sysconfig/docker file. If configured for:
If your Docker Engine is configured in Secure Mode, then you configure the monitoring credentials based on the type of communication defined.
For more information about how to create Docker certificates, see https://docs.docker.com/engine/security/https/. Cloud Agent Configuration If the cloud agent communicates with Oracle Management Cloud through a proxy (OMC_PROXYHOST & OMC_PROXYPORT parameters were set on the cloud agent when it was installed), Docker Engine / Docker Container discovery will fail. You’ll need to perform additional configuration steps depending on the following situations: For a New Agent Installation If the agent requires proxy to communicate with Oracle Management Cloud, then use the gateway and set the proxy parameters (OMC_PROXYHOST & OMC_PROXYPORT) during gateway installation, and then set up the cloud agent (without proxy parameters) to point to the gateway. For an Existing Agent If the existing cloud agent has been set up to use the proxy to communicate with Oracle Management Cloud, to discover Docker Engine / Docker Container, execute the following commands on the cloud agent before performing entity discovery. |
XEN Virtual Platform / XEN Virtual Server
| XEN Virtual Platform / XEN Virtual Server Prerequisites |
|---|
|
To enable monitoring for XEN Virtual Platform / XEN Virtual Server, you need the root user (or) a user with SUDO privileges defined. |
Oracle Database
| Prerequisites |
|---|
|
Setting Up Monitoring Credentials for Oracle Database Before you can begin monitoring DB systems, you must have the necessary privileges. A SQL script ( Enabling TCPS Connections Database Side (Single Instance)
Listener Changes Running SI on TCPS (Single Instance)
TCPS Credentials In order to establish secure communication with the Oracle Database, you must add TCPS Database Credential Properties to the credential JSON file in order to add the Oracle Database entity.
Agent Properties
Once set, bounce the Agent.
Note: Make sure that the above wallet is accessible at the agent location. |
Oracle Automatic Storage Management (ASM)
| Credentials |
|---|
|
Monitoring of ASM is supported through credential-based monitoring. For simplicity, use the default |
Note:
For monitoring ASM, the agent should be version 1.47 or above.Oracle NoSQL
| Credentials |
|---|
|
Monitoring of Oracle NoSQL is supported only through credential-less JMX (no credentials JSON file is needed). |
MySQL Database
| Prerequisites |
|---|
|
To enable monitoring for a My SQL Database, you can create a special database user, for example,
moncs as follows:
|
Microsoft SQL Server
| Prerequisites |
|---|
|
To enable monitoring for a Microsoft SQL Server Database, you can create a special database user as follows. Create a user (for example,
moncs) and map the new user to the master and msdb databases. Then, give this user the following minimum privileges.
Note: Beginning with Oracle Management Cloud 1.31, sqladmin-related privileges are no longer required.Then, map the user
For connecting to SQL server database with SSL encryption, do the following:
|
MongoDB Database
| Prerequisites |
|---|
|
To enable monitoring for a MongoDB Database, you can create a special database user, for example,
|
Oracle WebLogic Server (includes WebLogic Domain and WebLogic Cluster)
| Prerequisites |
|---|
|
To enable monitoring of a Oracle WebLogic Server (WLS), use a WebLogic user with at least the Monitor role. The user can also have Operator or Administrator roles, which include the Monitor role. If you have enabled the Oracle WebLogic Server with SSL, you must export the certificate from its keystore and import it in the Cloud Agent keystore. Perform the following steps:
|
Oracle Service Bus
| Prerequisites |
|---|
|
Important: Before you can monitor Oracle Service Bus (OSB) entities in Oracle Management Cloud, you must first enable monitoring from the Oracle Service Bus Administration console.  Description of the illustration enable_mon.png For information, see What are Operational Settings for a Service?. Once monitoring has been enabled from the Oracle Service Bus Administration console, you can add OSB entities to Oracle Management Cloud. When specifying an OSB entity, you use credentials of a user with at least the Monitor role. The user can also have either the Operator or Admin role. |
Tomcat
| Prerequisites and Credentials |
|---|
|
Tomcat is monitored using JMX. You must configure Tomcat for JMX remote monitoring even if you are using a local agent. Tomcat can be monitored with or without authentication. If a JMX credential is created, then it’s assumed you’re monitoring this entity with credentials. To create a JMX credential for monitoring:
If you have enabled the Tomcat JMX with SSL, you must export the certificate from its keystore and import it in the Cloud Agent keystore. Perform the following steps:
|
Oracle Traffic Director (OTD)
| Prerequisites |
|---|
|
OTD 11 Use an OTD Administrator user. In addition, to enable collection of metrics, you must configure and start an SNMP subagent. To start the SNMP subagent, use OTD Admin Console, or use the following command:
For more information on configuring and starting an SNMP subagent, see the Oracle Traffic Director documentation. OTD 12 Use a WebLogic Server user with the Monitor role. The user can also have Operator or Admin roles, which include the Monitor role. |
Apache HTTP Server
| Apache HTTP Server Prerequisites |
|---|
|
In this release, only Apache HTTP Server 2.4.x and 2.2 for Linux are supported. To enable the collection of configuration metrics, note the following:
In order to monitor an Apache HTTP Server you must first:
For more information, see https://httpd.apache.org/docs/2.4/mod/mod_status.html and http://httpd.apache.org/docs/current/mod/core.html#location. For HTTPS/Secure communication between Apache HTTP Server and the cloud agent during metrics collection, you must provide an SSL certificate. To make the certificate available with the cloud agent:
For data retrieval of memory-related metrics (supported on Unix platforms and when an entity is locally monitored), the PID file (httpd.pid) file needs to be accessed. If Apache is running as root or some user other than the agent process owner, access to the PID file will fail. Hence, to allow access to As a privileged user, run the following commands:
where |
Oracle HTTP Server (OHS)
| Prerequisites |
|---|
|
OHS 12 : Node Manager credentials are required. Also, the following prerequisites must be met:
|
Arista Ethernet Switch
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string (which was entered during the Arista Switch configuration) along with IP address of agent that will be used for Arista Switch monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus the authentication method (SHA or MD5) and authorization password if authorization is used. In addition, you must supply the privilege method (only DES is supported) and privilege password if privilege is used. Everything needs to be manually configured up front in the Arista Switch. Read-only access is all that’s required for Arista Switch monitoring. |
Cisco Ethernet (Catalyst) Switch
| Prerequisites |
|---|
|
To enable monitoring of the Cisco Ethernet (Catalyst) Switch, you will need to provide the SNMPv1/v2 or SNMPv3 credentials in the JSON credential file. Read-only access is sufficient for Cisco Catalyst Switch monitoring. For more information on how to configure an SNMP user for a Cisco Catalyst Switch, see http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/12-2_55_se/configuration/guide/scg_2960/swsnmp.html#78160 |
Cisco Nexus Ethernet Switch
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string (which was entered during Cisco Nexus Ethernet Switch configuration) along with IP address of agent that will be used for Cisco Nexus Ethernet Switch monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus the authentication method (SHA or MD5) and authentication password if authentication is used,. In addition, the privilege method (only DES supported) and privilege password must be supplied if privilege is used. Everything needs to be manually configured up front in the Cisco Nexus Ethernet Switch. Read only access is enough for the Cisco Nexus Ethernet Switch monitoring. |
Oracle Power Distribution Unit (PDU)
| Prerequisites |
|---|
|
To enable monitoring, HTTP and SNMPv1/v2c/v3 are needed. The NMS and trap tables in PDU administration interface must be set for a proper SNMP monitoring. for more information, see the PDU vendor documentation. |
Juniper Ethernet Switch
| Prerequisites |
|---|
|
To enable monitoring, HTTP and SNMPv1/v2c/v3 are needed. If SNMPv1/v2 is used, you must provide SNMP community string that has been used earlier in Juniper Switch configuration along with IP address of agent which will be used for Juniper Switch monitoring. If SNMPv3 is used, in addition to SNMPv3 user, you must provide the auth method (SHA or MD5) and auth-password if auth is used, and priv method (only DES supported) and priv-password if priv used. You must configure everything manually in Juniper Switch. Read only access is sufficient for Juniper Switch monitoring. |
Oracle Infiniband Switch
| Prerequisites |
|---|
|
To enable monitoring, HTTP and SNMPv1/v2c/v3 are needed. If SNMPv1/v2 is used, you must provide SNMP community string that has been used earlier in IB Switch configuration along with IP address of agent which will be used for IB Switch monitoring. If SNMPv3 is used, in addition to SNMPv3 user, you must provide the auth method (SHA or MD5) and auth-password if auth used, and plus priv method (only DES supported) and priv-password if priv used. You must configure everything manually in IB Switch. Read only access is sufficient for IB Switch monitoring. |
Brocade Fibre Channel Switch
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string (entered during Brocade Fibre Channel Switch configuration), along with the IP address of the agent that will be used for Brocade Fibre Channel Switch monitoring. If SNMPv3 is used, you must provide the SNMPv3 the user, plus the authentication method (SHA or MD5) and authorization password (if authorization is used), plus privilege method (only DES is supported) and privilege password if a privilege method is used. All of this needs to be manually configured up front in the Brocade Fibre Channel Switch. Read-only access is enough for Brocade Fibre Channel Switch monitoring. |
SCOM (System Center Operations Manager)
| Prerequisites |
|---|
|
Credentials must follow the same criteria as any program which tries to obtain data from SCOM using the SCOM SDK. See How to Connect an Operations Manager SDK Client to the System Center Data Access Service. The OMC Cloud Agent uses the omc_scom.exe client to connect to the SCOM SDK. The Cloud agent does not bundle required SCOM SDK libraries (due to the license type of libraries). You must manually copy the SCOM SDK libraries to the machine where the agent is running.
|
Juniper SRX Firewall
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must supply the SNMP community string (which was entered during Juniper SRX Firewall configuration) along with IP address of agent that will be used to monitor the Juniper SRX Firewall. If SNMPv3 is used, you must supply the SNMPv3 user, plus the authentication method (SHA or MD5) and authentication password, if authentication is used. In addition, privilege method (only DES supported) and privilege password will be required, if privileges are used. Everything must be manually configured up front in the Juniper SRX Firewall. Read-only access is sufficient for Juniper SRX Firewall monitoring. |
Fujitsu Server
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during XSCF configuration along with IP address of the agent that will be used to monitor the Fujitsu Server. If SNMPv3 is used, you must provide the SNMPv3 user, plus authorization method (SHA or MD5) and authorization password if authorization used. You must also provide the privilege method (only DES supported) and privilege password if privilages are used. All of this must be manually configured upfront in the Fujitsu server service processor.. Read-only access is adequate for the monitoring. For more information on how to configure SNMP users in Fujitsu M10 servers, see http://www.fujitsu.com/downloads/SPARCS/manuals/en/c120-e684-11en.pdf |
Intel/SPARC Computers
| Credentials |
|---|
|
Only the username and password are required to use SSH to log in to the ILOM service processor. |
VMware vCenter
| Prerequisites |
|---|
|
In order for the Cloud Agent to be able to collect all the metrics for the Oracle Management Cloud VMware entities, you should:
Credentials: username/password required to access VMware vCenter (use Administrator role). Example: Certificates: You need to explicitly add the vCenter certificate to the Agent's JKS: Example: How to extract certificate from vCenter:
Discovery properties: How to retrieve VMware vCenter Server Instance UUID to be passed in at discovery time through the entity property omc_virtual_mgmt_system_id using VMware PowerCLI: Example:
|
Docker Swarm
| Prerequisites and Credentials |
|---|
|
Cloud Agent Configuration If the cloud agent communicates with Oracle Management Cloud through a proxy (OMC_PROXYHOST & OMC_PROXYPORT parameters were set on the cloud agent when it was installed), Docker Swarm discovery will fail. You’ll need to perform additional configuration steps depending on the following situations: For a New Agent Installation If the agent requires proxy to communicate with Oracle Management Cloud, then use the gateway and set the proxy parameters (OMC_PROXYHOST & OMC_PROXYPORT) during gateway installation, and then set up the cloud agent (without proxy parameters) to point to the gateway. For an Existing Agent If the existing cloud agent has been set up to use the proxy to communicate with Oracle Management Cloud, to discover Docker Swarm, execute the following commands on the cloud agent before performing entity discovery. Credentials There are three methods you can use to authenticate and connect to the Docker Swarm via Rest APIs 1) Non-secure 2) Secure (https): 1–way SSL mode 3) Secure (https): 2–way SSL mode |
Apache SOLR
| Prerequisites |
|---|
|
Two modes are supported: standalone & solrcloud Monitoring is done over REST APIs exposed by Apache SOLR Monitoring credentials require read access to following URIs:
Credentials
|
Hadoop Cluster
| Prerequisites |
|---|
|
By default, Hadoop runs in non-secure mode in which no actual authentication is required. By configuring Hadoop to run in secure mode, each user and service needs to be authenticated by Kerberos in order to use Hadoop services. To perform Kerberos authentication, the Cloud Agent requires the following:
The Cloud Agent can use only one krb5.conf at a time. If a single Agent needs to perform Kerberos authentication with more than one domain, these details should be defined in a single krb5.conf file. |
Arbor TMS/CP
| Prerequisites |
|---|
|
SNMP v1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during Arbor appliance configuration along with IP address of Cloud Agent which will be used for appliance monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus authentication method (SHA or MD5) and password if authorization is used, plus the privilege method (only DES is supported) and privilege password if privilege is used. All of this needs to be manually configured beforehand in the appliance.. Read-only access is adequate for Arbor appliance monitoring. |
Juniper Netscreen Firewall
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during firewall configuration along with IP address of the Cloud Agent which will be used for Juniper firewall monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus authentication method (SHA or MD5) and password if authorization is used, plus the privilege method (only DES is supported) and privilege password if privilege is used. All of this needs to be manually configured beforehand in the firewall.. Read-only access is adequate for Juniper firewall monitoring. |
Juniper MX Router
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during router configuration along with the IP address of the Cloud Agent which will be used for router monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus authentication method (SHA or MD5) and password if authorization is used, plus the privilege method (only DES is supported) and privilege password if privilege is used. All of this needs to be manually configured beforehand in the router. Read-only access is adequate for MX router monitoring. |
F5 BIG-IP LTM
| Credentials |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during F5 BIG-IP LTM configuration along with IP address of Cloud Agent which will be used for the LTM monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus authentication method (SHA or MD5) and password if authorization is used, plus the privilege method (only DES is supported) and privilege password if privilege is used. All of this needs to be manually configured beforehand in the LTM. Read-only access is adequate for LTM monitoring. |
F5 BIG-IP DNS
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials are needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during F5 BIG-IP DNS configuration along with IP address of the Cloud Agent which will be used for the DNS monitoring. If SNMPv3 is used, you must provide the SNMPv3 user, plus authentication method (SHA or MD5) and password if authorization is used, plus the privilege method (only DES is supported) and privilege password if privilege is used. All of this needs to be manually configured beforehand in the DNS. Read-only access is adequate for DNS monitoring. |
ES2 Ethernet Switch
| Prerequisites |
|---|
|
SNMPv1/v2 or SNMPv3 credentials needed for monitoring. If SNMPv1/v2 is used, you must provide the SNMP community string that was entered during ES2 configuration along with IP address of the Cloud Agent which will be used for appliance monitoring. If SNMPv3 used, you must provide the SNMPv3 user, plus authentication method (SHA or MD5) password if authentication is used, plus the privilege method (only DES is supported) and privilege password if privilege is used. All of this needs to be manually configured beforehand in the appliance. Read-only access is adequate for the ES2 monitoring. |
Oracle Flash Storage
| Prerequisites and Credentials |
|---|
|
Oracle Flash Storage exposes monitoring data through the REST API. Oracle Flash Storage credentials (username and password) are required to monitor Oracle Flash Storage. |
Apache Cassandra DB
| Prerequisites |
|---|
|
The default settings for Cassandra make JMX accessible only from the local host. If you want to enable remote JMX connections, change the
LOCAL_JMX setting in cassandra-env.sh and enable authentication and/or SSL. To do this, perform the following procedure:
|
Oracle VM Server for SPARC (LDoms)
| Prerequisites |
|---|
|
Coherence
| Prerequisites |
|---|
|
Supports both credential and non-credential monitoring. When using a secured JMX connection, a credential input file needs to be passed. For information on configuring a Coherence cluster, see Configure a Coherence Cluster. |
Oracle Unified Directory(OUD)
| Prerequisites |
|---|
|
i) OUD Gateway ii) OUD Replication iii) OUD Proxy LDAP username and LDAP passwords are used to connect to the OUD LDAP server. OUD Credentials: Directory Server Username and Password: The username and password that will be used by the agent to bind to the server instance. Ensure the password is in the appropriate field. The following credential JSON sample illustrates how the properties should be entered. |
Oracle Access Manager (OAM)
| Prerequisites and Monitoring Credentials |
|---|
|
The same credentials are used to discover the WebLogic Domain. Note: Refresh of IDM targets is now supported. To refresh any IDM domain run where the content of idm_domain.json is:
|
Oracle Internet Directory (OID)
| Prerequisites |
|---|
|
Same credentials used to discover the WebLogic Domain. Note: Refresh of IDM targets is now supported. To refresh any IDM domain run where the content of idm_domain.json is:
|
Microsoft Internet Information Services (IIS)
| Prerequisites |
|---|
|
Local Monitoring: Credentials are not required. The agent user is used for monitoring. Remote Monitoring via WMI: Credentials are required. The credentials to be provided include the username and password used to log into the remote Windows host. Before you can monitor Microsoft IIS entities, you must ensure the following prerequisites have been met:
|
Oracle Identity Manager (OIM)
| Prerequisites |
|---|
|
Same credentials used to discover the WebLogic Domain. Note: Refresh of IDM targets is now supported. To refresh any IDM domain run where the content of idm_domain.json is:
|
Oracle Clusterware (CRS)
| Prerequisite for Remote Monitoring |
|---|
|
: SSH must be set up between the machine where the Cloud agent is installed and the machine where CRS is installed, The Cloud agent connects to the remote machine where CRS is installed via SSH authentication. |
JBOSS
| Prerequisites |
|---|
|
Before discovering a JBOSS server or domain, you must first add the JBOSS client jar file to the Cloud agent as a plug-in. The JBOSS client jar file contains the required JMX protocols that allow the agent to collect JBOSS metrics. The JBOSS client jar is distributed as part of the JBOSS installation. When you download the JBOSS zip file, the client jar file will be bundled with it. |
| Step | Action |
|---|---|
| Step 1: Locate the JBOSS client jar file. |
From the JBOSS home directory, you will find the client jar file at the following location:
In this directory, you’ll see the jboss-client.jar file. This is the file you need to copy over to the Cloud agent location. |
| Step 2: Copy the JBOSS client jar file to the Cloud agent installation. | Copy the jboss-client.jar file to a secure location that is accessible by the Cloud agent. Typically, this is located on the same host where the agent is installed. |
| Step 3: Add the jboss-client.jar to the Cloud agent installation as a plug-in. |
From the Cloud agent home directory, navigate to the agent state directory:
Create a classpath file. This file tells the agent where to find the Example: If you’re adding the GFM plug-in (plug-in ID is oracle.em.sgfm), the file name would be oracle.em.sgfm.classpath.lst . Edit the classpath file and add the absolute path to the jboss-client.jar file at the end of the file.
Bounce the agent. Any modifications made to the classpath file will not take effect until the agent is restarted. Once the agent has been bounced, you are ready to discover the JBOSS entity (server or domain). |
| Step 4: Discover the JBOSS server/domain. |
About JBOSS Monitoring Credentials Depending on whether you choose JBOSS Server or JBOSS Domain entity type, the required monitoring credentials will differ: JBOSS Server
JBOSS Domain
|
Kubernetes Cluster
In order to monitor Kubernetes, you need to set access permissions.
Cloud Agent Configuration
If the cloud agent communicates with Oracle Management Cloud through a proxy (OMC_PROXYHOST & OMC_PROXYPORT parameters were set on the cloud agent when it was installed), Kubernetes discovery will fail. You’ll need to perform additional configuration steps depending on the following situations:
For a New Agent Installation
If the agent requires proxy to communicate with Oracle Management Cloud, then use the gateway and set the proxy parameters (OMC_PROXYHOST & OMC_PROXYPORT) during gateway installation, and then set up the cloud agent (without proxy parameters) to point to the gateway.
For an Existing Agent
If the existing cloud agent has been set up to use the proxy to communicate with Oracle Management Cloud, to discover Kubernetes, execute the following commands on the cloud agent before performing entity discovery.
omcli setproperty agent -allow_new -name _configureProxyPerClient -value true
omcli stop agent
omcli start agentMaster's Server Certificate
To connect to the Kubernetes API server, you need to add the Master's Server Certificate to the agent trust store.
Downloading the Certificate (Command Line)
# echo -n | openssl s_client -connect <master host>:<master port> | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > <certificate name>.crt
# Example for Kubernetes Master URL https://myhost.myco.com:6443/ execute the following
$ echo -n | openssl s_client -connect myhost.myco.com:6443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > "slcak155.crt"Adding to the Agent Trust Store
For secure Kubernetes installations (https), it is mandatory to add the certificate of the Kubernetes master to the agent's trust store. This can be done either using OMCLI or during the discovery process. If you add the certificate to the agent trust store using omcli secure, then you don't need to fill out the certificate-related fields (Certificate,CertAlias,CertPassword) in the JSON or the UI when adding the target. Alternatively, you can add the certificate to the agent trust store during the discovery process (either through the UI or using omcli add_entity).
- Using OMCLI
# omcli secure add_trust_cert_to_jks -password welcome -trust_certs_loc <path to the certificate> -alias <alias of the certificate> $ omcli secure add_trust_cert_to_jks -password welcome trust_certs_loc /agentdir/cloud_agent/agent_inst/bin/slcak155.crt -alias kube-server - During Discovery
From the UI (Token Credentials, Basic Credentials, Keystore Credentials)
From the Command Line
When runningomcli add_entity, the path to the certificate, its alias, and the agent's trust store password can be specified as part of the credential JSON, as shown in the following JSON example (Token-based authentication).{ "credentials": [ { "id": "KubeCredsRef", "name": "TokenCredentialSet", "credType": "TokenCredential", "properties": [ { "name": "Token", "value": "CLEAR[<Token>]" }, { "name": "Certificate", "value": "FILE[<Absolute path of Kubernetes certificate file>]" }, { "name": "CertAlias", "value": "CLEAR[<Kubernetes certificate alias>]" }, { "name": "CertPassword", "value": "CLEAR[<Agent trust store password>]" } ] } ] }
Token Based Authentication
Creating a Service Account
You can reuse a service account already present in the Kubernetes installation or create a new one.
# kubectl create serviceaccount <service account name>
$ kubectl create serviceaccount omc-monitoring$ kubectl get serviceaccounts
NAME SECRETS AGE
default 1 14d
omc-monitoring 1 1hEvery service account when created will have a secret associated with it.
$ kubectl get secrets
NAME TYPE DATA AGE
default-token-ggjlh kubernetes.io/service-account-token 3 14d
omc-monitoring-token-96jpc kubernetes.io/service-account-token 3 1h
# We are interested in the name that starts with our serviceaccount name. Here for example the token for omc-monitoring serviceaccount is omc-monitoring-token-96jpcThe token value can be extracted by describing the secret.
# kubectl describe secrets <secret name>
$ kubectl describe secrets omc-monitoring-token-96jpc
Name: omc-monitoring-token-96jpc
Namespace: default
Labels: <none>
Annotations: kubernetes.io/service-account.name=omc-monitoring
kubernetes.io/service-account.uid=be1ff6c9-ed72-11e8-b9e7-0800275fc834
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1025 bytes
namespace: 7 bytes
token: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9...(extracted token)
Access Permissions
Before the token of the service account is used for monitoring we need the "get, list and watch" privileges for following resources:
| Kubernetes Version | Resources |
|---|---|
| 1.8 |
pods,nodes,namespaces,services,jobs,services/proxy,deployments.apps,replicasets.apps,daemonsets.apps,statefulsets.apps,replicationcontrollers |
|
1.7 |
pods,nodes,namespaces,services,jobs,services/proxy,deployments.apps,replicasets.extensions,daemonsets.extensions,statefulsets.apps,replicationcontrollers |
| 1.9 to 1.11 |
pods,nodes,namespaces,services,jobs,services/proxy,deployments.apps,replicasets.apps,daemonsets.apps,statefulsets.apps,replicationcontrollers,nodes/proxy |
| 1.5 and 1.6 | pods,nodes,namespaces,services,jobs,services/proxy,deployments.extensions,replicasets.extensions,daemonsets.extensions,statefulsets.apps,replicationcontrollers |
For adding the permissions to a service account, first create a cluster role
# kubectl create clusterrole <cluster_role_name> --verb=get,list,watch --resource=<Resources>
$ kubectl create clusterrole omc-monitoring-role --verb=get,list,watch --resource=pods,nodes,namespaces,services,jobs,services/proxy,deployments.apps,replicasets.apps,daemonsets.apps,statefulsets.apps,replicationcontrollers,nodes/proxy# kubectl create clusterrolebinding <cluster_role_binding_name> --clusterrole=<cluster_role_name> --serviceaccount=default:<service_account_name>
$ kubectl create clusterrolebinding omc-monitoring-binding --clusterrole=omc-monitoring-role --serviceaccount=default:omc-monitoringNote:
If you want access to all the resources you can use this clusterrole cluster-admin,which has all privileges and can create binding for the created serviceaccount using below command.
# kubectl create clusterrolebinding <cluster_role_binding_name> --clusterrole=cluster-admin --serviceaccount=default:<service_account_name>
$ kubectl create clusterrolebinding all-access-binding --clusterrole=cluster-admin --serviceaccount=default:all-access-accountBasic Authentication
Creating Authorization Policy
<password>,<username>,<groupname>In a new file "abac-authz-policy.jsonl "(under directory /etc/kubernetes/pki on the master node ). For above user, you need to specify what API's the user needs access to and with what privileges, as shown below.
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "pods", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "nodes", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "services", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "namespaces", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "deployments", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "daemonsets", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "replicasets", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "jobs", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "replicationcontrollers", "apiGroup": "*", "readonly": true}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "statefulsets", "apiGroup": "*", "readonly": true}}Note:
If you need to provide access to all resources for this user, just add the following command in the JSON file.
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user":"<username>", "namespace": "*", "resource": "*", "apiGroup": "*", "readonly":true}}Modifying the API Server Manifest
Add details of above two files in /etc/kubernetes/manifets/kube-apiserver.yaml on the master node as follows.
- --authorization-mode=Node,RBAC,ABAC (EDIT THIS ENTRY)
- --basic-auth-file=/etc/kubernetes/pki/basic_auth.csv (NEW ENTRY)
- --authorization-policy-file=/etc/kubernetes/pki/abac-authz-policy.jsonl (NEW ENTRY)
Note:
1) Make sure that while adding the above lines, use spaces for indentation (do not use tabs). 2) Also, if you are trying to change the policy file, you need to copy them in a new file and refer the new file name as above, since APIserver will not be able to identify if there is any change in the existing policy JSON file.To reflect the changes, restart the kubelet using the following command:
# Run the following command as root user
$ systemctl restart kubeletClient Certificate Authentication
Add following lines to /etc/kubernetes/manifets/kube-apiserver.yam
- --client-ca-file=/srv/kubernetes/ca.crt
- --tls-cert-file=/srv/kubernetes/server.crt
- --tls-private-key-file=/srv/kubernetes/server.key
Information on how to generate these certificates can be found at the following website:
https://kubernetes.io/docs/concepts/cluster-administration/certificates/
To create the JKS from certificates, run the following:
cat server.crt server.key > keyCert.pem
openssl pkcs12 -export -in keyCert.pem -out clientKeystore.pkcs12 -name clientKeystore -noiter -nomaciter
keytool -importkeystore -srckeystore clientKeystore.pkcs12 -srcstoretype pkcs12 -srcalias clientKeystore -destkeystore clientKeystore.jks -deststoretype jks -deststorepass <password> -destalias clientKeystoreDiscovery
Kubernetes can be discovered from either the Oracle Management Cloud console or from OMCLI.
OMCLI
Following table shows the content of the sample JSON files used to discover Kubernetes using OMCLI. See Add Entities Using JSON Files.
| Without credentials - insecure | With credentials - secure |
|---|---|
|
|
Note:
An additional property omc_heapster_url can be specified in the JSON's "properties" object (shown below) in order to fetch metrics from heapster. If this property is not provided then the metrics will be fetched from summary API.
{
.....
"properties" : {
....
"omc_heapster_url" : {
"displayName" : "Heapster URL",
"value" : "<base url of heapster>"
}
}
}| Property | UI Name | Description |
|---|---|---|
| omc_kubernetes_master_url | Kubernetes Master URL | Base URL of the API Server on the Kubernetes Master Node. The URL is of the form http(s)://<hostname>:<port> |
| host_name | Hostname | Hostname of the Kubernetes master node |
| omc_heapster_url | Heapster URL |
Base URL of Heapster. This needs to be specified if the performance metrics are to be collected from Heapster. If heapster is running inside Kubernetes as a cluster service the Base URL is of the form http(s)://<host>:<port>/api/v1/namespaces/kube-system/services/heapster/proxy Here the host & port are same as in omc_kubernetes_master_url |
| Basic Credentials | Token Credentials | Keystore Credentials |
|---|---|---|
|
|
|
Basic Credentials
| Property | UI Name | Description |
|---|---|---|
| Alias | Username | Username of the user going to discover Kubernetes |
| Password | Password | Password of the user |
| Certificate | Keystore Certificate | Certificate of Kubernetes API Server on Master Node. Users need to specify the text inside the certificate file if added from UI. In omcli, users need to create a Java Keystore, add certificate to that and specify the file path. |
| CertAlias | Certificate Alias | Alias for the Certificate. This should be unique alphanumeric string |
| CertPassword | Trust Store Password | Password of agent's Trust Store. This password is "welcome" |
| Property | UI Name | Description |
|---|---|---|
| Token | Token | Token of the user going to discover Kubernetes |
| Certificate | Keystore Certificate | Refer Basic Credentials |
| CertAlias | Certificate Alias | Refer Basic Credentials |
| CertPassword | Trust Store Password | Refer Basic Credentials |
| Property | UI Name | Description |
|---|---|---|
| StoreLocation | Store Location | Location of Client keystore. This Java Keystore file (JKS) should contain client's certificate. |
| StoreType | Store Type | Store type. This value is always set to "JKS" |
| StorePassword | Store Password | Password of the JKS file |
| Certificate | Keystore Certificate | Refer Basic Credentials |
| CertAlias | Certificate Alias | Refer Basic Credentials |
| CertPassword | Trust Store Password | Refer Basic Credentials |
Oracle GoldenGate
| Prerequisites |
|---|
|
Oracle GoldenGate enables the continuous, real-time capture, routing, transformation, and delivery of transactional data across heterogeneous (Oracle, DB2, MySQL, SQL Server, Teradata) environments. The following prerequisites apply when discovering and monitoring Oracle GoldenGate environments. Enable Monitoring The first prerequisite is to enable monitoring in GoldenGate. Follow the steps below for your specific GoldenGate version and architecture. Classic Architecture If you are using GoldenGate Classic Architecture, you will need to add a parameter in the GLOBALS file to enable monitoring. You must be running GoldenGate version 12.3.0.1.181120 at a minimum. This is a cumulative patch set for GoldenGate released in Jan 9, 2019.
Microservices Architecture If you are using GoldenGate Microservices Architecture, then as part of the setup of GoldenGate using the GoldenGate Configuration Assistant, you should enable Monitoring. Once monitoring has been enabled, the Performance Metric Server will be started. This is an indication that monitoring has been enabled for GoldenGate. OCI GoldenGate If you are using OCI GoldenGate, no prerequisites are required. Monitoring is enabled by default. Import Certification for GoldenGate Secure Installations If the Oracle GoldenGate setup is secure (HTTPS), the GoldenGate certificate needs to be imported into the agent manually prior to discovery. To do this, perform the following:
|
Oracle VM Manager
| Prerequisites |
|---|
|
The cloud agent must be deployed on the Oracle VM Manager host. Credentials: The username and password are required to access the Oracle VM Manager console. Example: Certificates: You need to explicitly add the Oracle VM Manager Weblogic certificate to the Agent's JKS. How to extract certificate from Oracle VM Manager: To export the Oracle VM Manager WebLogic certificate, log in as the root user and enter the following command: To import the Oracle VM Manager Weblogic certificate to the Agent Keystore, log in as an Oracle cloud agent user and enter the following command: |
Oracle JVM Runtime
| Prerequisites |
|---|
|
Monitoring Oracle JVM Runtime can be performed in the following modes:
SSL configuration: You will need to import your truststore certificate into the cloud agent truststore using omcli as shown in the following example: |
Microsoft Azure
| Prerequisites |
|---|
|
Before monitoring Microsoft Azure with Infrastructure Monitoring, you first need to create a Wep app/API application registration for your Oracle Management Cloud account in Azure.
|
Apache Kafka
| Prerequisites |
|---|
|
Import Zookeeper Jar
Import Kafka Client Jar
JMX Configuration Enable JMX on Kafka Brokers with no authentication Add the following lines to
Start the Kafka server. Note: For a multibroker setup, provide a unique JMX port and unique broker ID for each. The listen port should be different if brokers are started on the same node. If there are duplicate broker IDs, the connection will fail with an error "Address already in use". |