This chapter provides details on monitoring Oracle Communications Contacts Server.
Contacts Server uses a managed bean (MBean) created in an application server to collect monitoring data. By using the application server's Java Management Extension (JMX) interface and a JMX-compliant client, you can access the monitoring data. The JMX client connects to the platform's MBeanServer by using a JMX Service URL. Once a client connects to the MBeanServer, it uses the Contacts Server monitoring MBean object name to access the MBean's attributes.
This section describes the attributes of the Contacts Server monitoring MBean object name, com.sun.comms.davserver:type=monitor.
Table 5-1 describes the general monitoring attributes.
Table 5-1 General Monitoring Attributes
Name | Type | Description |
---|---|---|
ContactsCreated |
Integer |
The number of contacts and groups created since the server was started. |
FailedLogins |
Integer |
The number of failed login attempts since the server was started. |
BackendMonitorScheduleQData |
CompositeData[] |
The calendar schedule queue length per back-end database. For more information, see "Back-End Database Schedule Queue Attributes". |
BackendMonitorARTData |
CompositeData[] |
The average response time per back-end database. For more information, see "Back-End Database Average Response Times Attributes". |
BackendRTData |
TabularType Map<K,V> TabularData (BackendRTData) |
A dynamic collection of response time data of LDAP connections, provided in a Map interface, that is, Map<String backendID, BackendRTData rtData>. Both the UG lookup and LDAP authentication connections are monitored. For more information, see "LDAP Response Time Monitoring Attributes". |
Table 5-2 describes the back-end database schedule queue monitoring attributes.
Table 5-2 Back-End Database Schedule Queue Monitoring Attributes
Name | Type | Description |
---|---|---|
backendID |
String |
Name ID of this back-end database as defined on this front-end host. |
message |
String |
Optional exception or informational message from this back-end database. |
activeCount |
Long |
The count of resources on the schedule queue that are scheduled for immediate processing. A value of -1 means no data is available. |
retryCount |
Long |
The count of resources on the schedule queue that initially failed and are waiting for a later retry. The default retry time period is 1 hour. The maximum retry default is 24. |
The average response time for a back-end database is passively calculated during normal work load and reported in milliseconds. The sample duration period is approximately 60 seconds. Numerical fields may have a value of -1 if no data can be returned from that back-end database. However, if there is no activity, then the last good value is retained if possible. The data is measured by taking samples of real client requests. Thus, if no clients are active or are not making requests, there is no data to be measured.
Table 5-3 describes the back-end database average response time monitoring attributes.
Table 5-3 Back-End Database Average Response Times Monitoring Attributes
Name | Type | Description |
---|---|---|
backendID |
String |
Name ID of this back-end database as defined on this front-end host. |
message |
String |
Optional exception or informational message from this back-end database. |
ART |
Long |
The average response time for a random sampling of simple database requests in milliseconds over approximately a previous 60 seconds time frame. A value of -1 means no data. |
NSamples |
Long |
The number of samples taken in this average. |
startTime |
Long |
The system time in milliseconds of the first sample. |
endTime |
Long |
The system time in milliseconds of the last sample. |
status |
Long |
The back-end database status as known by this front-end host. The possible values are:
|
statusTime |
Long |
The system time at which this JMX request was issued. |
Table 5-4 describes the LDAP response time monitoring attributes.
Table 5-4 LDAP Response Times Monitoring Attributes
Name | Type | Description |
---|---|---|
backendID |
String |
Key. Name ID of this LDAP host, in format, BackendType-HostName, for example, LDAPUg-01.example.com. |
RT |
Long |
The response time of simple back-end requests in milliseconds. |
message |
String |
Optional information about the connection, for example, "Exception occurred during LDAP healthCheck()." |
timestamp |
Long |
The system timestamp that was issued by this request. |
Contacts Server itself does not provide a client to access the monitoring data. Instead, you can use any Java Management Extension (JMX) client.
To access the monitoring data, a JMX client needs the following information:
Application server host name or IP address
Application server port number (GlassFish Administration port or WebLogic Managed Server port)
Application server administrative user name and password
MBean ObjectName, which is com.sun.comms.davserver:type=monitor
Attribute names
If you use GlassFish Server:
You connect a JMX client to the GlassFish Server's MBeanServer by using a JMX Service URL of the following form:
service:jmx:rmi:///jndi/rmi://host:port/jmxrmi
where:
host is the name or IP address of GlassFish Server
port is the GlassFish Server administration port number
If you use WebLogic Server:
Oracle recommends that you use the T3/T3S protocol support provided in the wlthint3client.jar library for a remote access.
See Accessing WebLogic Server MBeans with JMX section in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server
.
You can connect a JMX client to the WebLogic Server's MBeanServer by using a JMX Service URL of the following form:
service:jmx:t3s://host:port/jndi/weblogic.management.mbeanservers.runtime
where:
host is the name or IP address of the WebLogic Server
port is the WebLogic Server administration port number
Note:
Ensure to provide SSL Port when using t3s protocol in the URL.More information on JMX and JMX clients is available on the Java documentation web site at:
In addition to using monitoring data gathered by the Contacts Server monitoring MBean, you can also check the health of your hosts by using the Contacts Server supplied responsetime script. This script sends a set of basic requests to Contacts Server and measures the amount of time needed to process those requests. When the responsetime script shows a spike or a large increase in response time, this indicates a potential issue with Contacts Server that needs to be addressed.
To run the responsetime script, you must provide the server type (contacts), the application server host name and port, and an LDAP user account to run the script. When the script finishes, it displays the number of milliseconds needed to run the series of requests to stdout. When the script encounters no problems, it returns an exit status of 0. If the script encounters a problem, it returns an exit status of 1 to stderr. See "responsetime Script Error Codes" for a list of error codes and descriptions.
Use the responsetime script to check the health of your Contacts Server hosts.
responsetime -t contacts -H host -p port [-s path_of_truststore] [-x context_root] [-L locale] [-h]
Table 5-5 describes the options.
Table 5-5 Options for responsetime Script
Option | Description |
---|---|
-t |
Specifies to monitor Contacts Server (contacts). |
-H |
Specifies the application server host name. |
-p |
Specifies the application server administrative port. |
-s |
Specifies the path to the truststore file, if a secure connection is used. |
-x |
Specifies the context root for Contacts Server. The default is / (root). |
-L |
Specifies the language locale to use to display messages. The format is LL_CC_VV, where:
|
-h |
Displays usage help. |
The responsetime script requires that you stream the following user name and password, each on a separate line, to the script by using stdin:
RT_USER=user
RT_PWD=password
For information on creating a dedicated user account for RT_USER, see "Creating a Dedicated User Account for the responsetime Script".
Table 5-6 describes the responsetime script error codes and descriptions.
Table 5-6 responsetime Script Error Codes
Error Code | String | Description |
---|---|---|
211 |
Invalid option: |
An invalid option was entered on the command line. |
212 |
The "{0}" option is required. |
A required option was not entered on the command line. The "{0}" string is replaced in the message with the name of the missing option. |
500 |
Ok |
The request succeeded and the amount of time, in milliseconds, is displayed to stdout. |
501 |
Application server is down. |
The responsetime script cannot connect to the application server host. |
502 |
Contacts Server is down or server path not found. |
The responsetime program had trouble sending a request to the application server host. |
504 |
Login failure. |
A problem occurred when trying to log in to the application server host. |
505 |
Invalid user name or password. |
Either the user name or the password was invalid. |
510 |
Unable to locate or open messages resource bundle. |
A problem occurred when accessing the localization resource bundle. |
The following example shows how to invoke the responsetime script and run it by using csrtuser as RT_USER.
#!/bin/sh
#
echo "RT_USER=csrtuser\nRT_PWD=password" | sbin/responsetime -t contacts -H sc11.example.com -p 8080 -x /nabserver
bash> example_csrt.sh
1374
bash>
The responsetime script requires a user account in LDAP to be specified in the RT_USER variable. You should create a dedicated user account for the responsetime script to use. Create this user by using the Contacts Server config-rtuser script, which is located in the ContactsServer_home/sbin directory. The config-rtuser script both creates the user in LDAP and runs the davadmin command to create the user in the Contacts Server database.
To create a dedicated user for the responsetime script by using the config-rtuser script:
Log in to the Contacts Server host as root.
Change to the ContactsServer_home/sbin directory.
Run the config-rtuser script:
config-rtuser
Respond to the prompts for user account and password, Directory Manager password, and application server administrative password.
When prompted to proceed, type Y.
The script runs the ldapmodify command to create the user account.