Oracle NoSQL Database Server Monitoring


Applications Manager provides out-of-the-box performance metrics and helps you visualize the health and availability of an Oracle NoSQL server farm. Database administrators can login to the web client and visualize the status and Oracle NoSQL performance metrics.

Creating a new Oracle NoSQL monitor

Using the REST API to add a new Oracle NoSQL monitor: Click here

Follow the given steps to create a Oracle NoSQL server monitor:

  1. Click on New Monitor link.
  2. Select Oracle NoSQL.
  3. Enter the Display Name of the monitor
  4. Enter the IP Address or hostname of the host.
  5. Enter the JMX Port in which the JMX is running.
  6. Enter the Additional JMX Port in which the JMX is already running in any of the other machine of the same cluster.
  7. Choose the Credential Details either use below credentials or select from credential list
  8. Enter the Username and Password of the Oracle NoSQL.
  9. Enter JNDI Path ex. /jmxrmi
  10. Enter the polling interval time in minutes.
  11. Choose the Monitor Group from the combo box with which you want to associate Oracle database server Monitor (optional). You can choose multiple groups to associate your monitor.
  12. Click Add Monitor(s). This discovers Oracle database server from the network and starts monitoring them.
  • Ensure that you enable JMX for Oracle NoSQL monitoring. To create a new Oracle NoSQL monitor, you should have admin privileges.
  • In case you are unable to add the monitor even after enabling JMX, try providing the below argument:

 Setting up JMX for Oracle NoSQL monitoring

Oracle NoSQL Database allows Java Management Extensions (JMX) or Simple Network Management Protocol (SNMP) agents to be optionally available for monitoring, in addition to the native monitoring provided by the Admin CLI and the Admin Console. These agents provide interfaces on each storage node that allow management clients to poll them for information about the status, performance metrics, and operational parameters of the storage node and its managed services, including replication nodes and admin instances. Both these management agents can also be configured to push notifications about changes in the status of any of the services, and for violations of preset performance limits. The JMX interface can be enabled in either the Community Edition or the Enterprise Edition. To use SNMP, however, you must have the Enterprise Edition. The JMX service exposes MBeans for the three types of components. These MBeans are the java interfaces StorageNodeMBean, RepNodeMBean, and AdminMBean in the package oracle.kv.impl.mgmt.jmx. For more information about the status reported for each component, see the javadoc for these interfaces.

The same information that is reported via JMX can also be reported through SNMP. In this case, the information is organized according to the Management Information Base (MIB) named OracleNosqlMIB, which is included with the Enterprise Edition, in the file lib/nosql.mib.

Simple Network Management Protocol (SNMP) and Java Management Extensions (JMX)

Both the SNMP and JMX agents in NoSQL Database are read-only interfaces and allow you to poll the storage nodes for information about the storage node and about any replication nodes or admins that are hosted on the storage node. The available information includes service status (such as, RUNNING, STOPPED etc.), operational parameters, and performance metrics. SNMP and JMX traps/notifications are also delivered for particular events. Notifications are sent for every service status state change; and for violations of performance limits.

Enabling Monitoring

Monitoring can be enabled on a per-storage node basis in two different ways:

In the Bootfile

You can specify that you want to enable JMX or SNMP in the storage node's boot configuration file. Usually, these files are created by using the makebootconfig utility, which has the following options to control these features:

  • [-mgmt {snmp|jmx|none} -pollport <snmp poll port>]
  • -traphost <snmp trap/notification hostname>]
  • -trapport <snmp trap/notification port>]
Note: When you specify -mgmt snmp, you must also specify -pollport. The SNMP agent listens for connections from SNMP management clients on this port. You may also optionally specify -traphost and -trapport to indicate the destination address for notifications. This would be the hostname and port number of an SNMP management service that is configured to receive notifications at that address.

Note: When you specify -mgmt jmx, you do not have to specify -pollport. A storage node's JMX agent uses the RMI registry at the same port number as is used for all other RMI services managed by the storage node. (This port number is specified as the -port argument to makebootconfig.)

By Changing Storage Node Parameters

You can still enable JMX or SNMP after a store is deployed, by changing the storage node parameters "mgmtClass", "mgmtPollPort", "mgmtTrapHost", and "mgmtTrapPort". Similar to configuring via makebootconfig, the "mgmtPollPort", "mgmtClass", "mgmtTrapHost", and "mgmtTrapPort" are used only for SNMP; and the parameter "mgmtPollPort" must be set when enabling SNMP.

The value of the "mgmtClass" parameter may be one of the following class names:

  • To enable JMX:
  • To enable SNMP:
  • To enable neither JMX nor SNMP:

For example, you could issue the following command in the Admin CLI to enable SNMP on a storage node:

plan change-parameters -service sn1 -wait -params \
mgmtClass=oracle.kv.impl.mgmt.snmp.SnmpAgent \
mgmtPollPort=5002 mgmtTrapHost=

Note: Only a single implementation of the management agent may be enabled at a particular time. If you enable SNMP on a storage node where JMX is already enabled; the JMX agent shuts down, and the SNMP agent takes its place.

 Displaying the NoSQL DB MBeans

To view the NoSQL Database JMX Mbeans in a monitoring tool such as JConsole, connect using the hostname and registry port for each Storage Node that you would like to view. This is the port that is named by the "-port" argument to the java -jar kvstore.jar makebootconfig command. It is also used in the deploy-sn plan during configuration. The documentation examples use 5000 as the registry port.

For example, you would specify localhost:5000 to the JConsole Remote Process connection box in the New Connection tab.

Monitored Parameters

  • To create a new Oracle NoSQL monitor, you should have admin privileges. 
  • Jconsole can also be used to access the Mbeans

Oracle NoSQL Monitoring Metrics:

Admin Attributes

Attribute Name Description
Admin ID Number of an Admin instance.
HttpPort The port number used by the Admin Console web application.
LogFileCount Number of log files that are kept.
LogFileLimit The maximum size of log files.
Whether this Admin is the master among Admin instances.
PollPeriodMillis The polling period for collecting metrics.
ServiceStatus The reported service status of the Admin.

Storage Attributes

Attribute Name Description
Capacity The number of Replication Nodes that can be hosted on this Storage Node.
AdminHttpPort The http port used by the Admin Console web application.
HostName The name of the network interface used for communication between Replication Nodes
HAPortRange The range of port numbers available for assigning to Replication Nodes that are hosted on this Storage Node.
HostingAdmin True if this Storage Node hosts an Admin instance
MemoryMB The amount of memory known to be available on this Storage Node, in megabytes.
MountPoints A list of file system mount points on which Replication Nodes can be deployed
NumCPUs The number of CPUs known to be available on this Storage Node.
RegistryPort The port number of the Storage Node's RMI registry.
RootDirPath The pathname of the store's root directory
SnId The StorageNodeId number of this Storage Node.
StoreName The configured name of the store to which this Storage Node belongs.

Replicated Node Table Attribute

Attribute Name Description
CacheSize The size of the BDB-JE cache, in MBytes.
CollectEnvStats If true, then the underlying BDB-JE subsystem will dump statistics into a local .stat file.
CommitLag Average commit lag(in milliseconds) for a given replication node's update operations during a given time interval.
RepNodeId The RepNodeId, in its String form
CommitLagThreshold Average commit lag (in milliseconds) for a given replication node during a given time interval exceeds the value returned by this method, a notification event will be sent to any parties that have registered interest.
CumulativeEnd The timestamp at the end of a cumulative measurement period.
CumulativeLatAvg The average latency for single operations since service startup.
CumulativeLatMax The highest latency measured for single operations since service startup.
CumulativeStart The timestamp at the beginning of a cumulative measurement period
CumulativeThroughput Single operations per second since service startup.
CumulativeTotalOps The total number of single operations since service startup.
HeapMB The size of the Java heap for this Replication Node, in MB.
IntervalLatAvg Average Latency of Operations in the given Interval