4 Monitoring Calendar Server

This chapter provides details on monitoring Oracle Communications Calendar Server.

About Monitoring Calendar Server

Calendar Server uses a managed bean (MBean) created in the application server to collect monitoring data. By using the application server's Java Management Extension (JMX) interface, you can then access this data by using a JMX-compliant client. 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 Calendar Server monitoring MBean object name to access the MBean's attributes.

Calendar Server Monitoring Attributes

This section describes the attributes of the Calendar Server monitoring MBean object name, com.sun.comms.davserver:type=monitor.

General Monitoring Attributes

Table 4-1 describes the general monitoring attributes.

Table 4-1 General Monitoring Attributes

Name Type Description

EventsCreated

Integer

The number of events created since the server was started.

FailedLogins

Integer

The number of failed login attempts since the server was started.

TasksCreated

Integer

The number of created tasks 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".

Back-End Database Schedule Queue Attributes

Table 4-2 describes the back-end database schedule queue monitoring attributes.

Table 4-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.

Back-End Database Average Response Times Attributes

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 4-3 describes the back-end database average response time monitoring attributes.

Table 4-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:

  • 0 - Database is okay

  • -1 - Database is down

  • -2 - Database failed to start

statusTime

Long

The system time at which this JMX request was issued.

LDAP Response Time Monitoring Attributes

Table 4-4 describes the LDAP response time monitoring attributes.

Table 4-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.

resptime

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.

Using a Java Management Extension Client to Access the Monitoring Data

Calendar 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 the GlassFish Server

  • port is the GlassFish Server administration port number

If you use WebLogic Server:

For remote access, Oracle recommends you to use the T3/T3S protocol support provided in the wlthint3client.jar library.

For more information, see the discussion about accessing WebLogic Server MBeans with JMX in Oracle Fusion Middleware Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.

You connect a JMX client to the WebLogic Server's MBeanServer by using a JMX Service URL that has the following syntax:

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 Managed Server port

    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:

https://docs.oracle.com/javase/8/docs/technotes/guides/jmx/

Using the responsetime Script

In addition to using monitoring data gathered by the Calendar Server monitoring MBean, you can also check the health of your hosts by using the Calendar Server supplied responsetime script. This script sends a set of basic requests to Calendar 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 Calendar Server that needs to be addressed.

To run the responsetime script, you must provide the server type (calendar), 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.

responsetime Script Syntax

Use the responsetime script to check the health of your Calendar Server hosts.

Location

CalendarServer_home/sbin

General Syntax

responsetime -t calendar -H host -p port [-s path_of_truststore]
             [-x context_root] [-L locale] [-h]

Table 4-5 describes the options.

Table 4-5 Options for responsetime Script

Option Description

-t

Specifies to monitor Calendar Server (calendar).

-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 Calendar Server. The default is / (root).

-L

Specifies the language locale to use to display messages. The format is LL_CC_VV, where:

  • LL is the language code.

  • CC is the country code.

  • VV is the variant.

-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

The responsetime script uses the WCAP protocol to fetch an event from a calendar that belongs to RT_USER. The first time the responsetime script runs, the calendar event does not yet exist. Thus, the script creates the calendar event for subsequent use. This one-time calendar event creation causes a slight increase to the response time. Afterwards, the response times should be similar except when server load differs.

For information on creating a dedicated user account for RT_USER, see "Creating a Dedicated User Account for the responsetime Script".

responsetime Script Error Codes

Table 4-6 describes the responsetime script error codes and descriptions.

Table 4-6 responsetime Script Error Codes

Error Code String Description

200

Ok

The request succeeded and the amount of time, in milliseconds, is displayed to stdout.

201

Application server is down.

The responsetime script cannot connect to the application server host.

202

Calendar server is down or server path not found.

The responsetime program had trouble sending a request to the application server host.

204

Login failure.

A problem occurred when trying to log in to the application server host.

205

Invalid user name or password.

Either the user name or the password was invalid.

206

Invalid server type.

The value of the -t option provided was invalid.

207

Response Time request failed.

A problem occurred when a request was made to the GlassFish Server.

208

Unable to find truststore file.

The truststore file was not found or could not be accessed.

209

Unable to create resource.

A problem occurred when creating the monitoring event.

210

Unable to locate or open messages resource bundle.

A problem occurred when accessing the localization resource bundle.

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.

responsetime Script Example

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 calendar -H sc11.example.com -p 8080 -x /davserver
 
bash> example_csrt.sh
1374
bash>

Creating a Dedicated User Account for the responsetime Script

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 Calendar Server config-rtuser script, which is located in the CalendarServer_home/sbin directory. The config-rtuser script both creates the user in LDAP and runs the davadmin command to create the user in the Calendar Server database.

To create a dedicated user for the responsetime script by using the config-rtuser script:

  1. Log in to the Calendar Server host as root.

  2. Change to the CalendarServer_home/sbin directory.

  3. Run the config-rtuser script:

    config-rtuser

  4. Respond to the prompts for user account and password, Directory Manager password, and the application server administrative password.

  5. When prompted to proceed, type Y.

    The script runs the ldapmodify command to create the user account.