| Oracle® Real-Time Collaboration Administrator's Guide 10g Release 1 (10.1.2) Part Number B25460-03 |
|
|
View PDF |
| Oracle® Real-Time Collaboration Administrator's Guide 10g Release 1 (10.1.2) Part Number B25460-03 |
|
|
View PDF |
This chapter describes how you can monitor Oracle Real-Time Collaboration components to provide quality of service for conferences and instant messages and uninterrupted availability for conference and messaging services. This chapter contains the following sections:
The Oracle Real-Time Collaboration Process Manager (rtcpm) is a Java-based process that runs as a daemon, managing all Oracle Real-Time Collaboration processes in an instance. The Process Manager opens an HTTP listening point to accept requests to start and stop processes. Specifically, it does the following:
Periodically pings all Oracle Real-Time Collaboration processes in an instance, to check if the process is active.
Automatically restarts inactive processes (processes that do not respond to the ping).
The Process Manager monitors the following Oracle Real-Time Collaboration component processes:
Oracle Web Conferencing Server (confsvr)
Client Connection Manager (connmgr)
Oracle Presence Server (imrtr)
Multiplexer (mx)
Redirector (rdtr)
Voice Proxy Server (voiceproxy)
The Process Manager is integrated with the Oracle Process Management and Notification system (OPMN) when you install Oracle Real-Time Collaboration. The OPMN system monitors the Process Manager and automatically restarts rtcpm if it appears to be inactive. The Process Manager can recover its state without affecting the processes that it was monitoring before it went down.
When you enter the rtcctl start command, Oracle Process Management and Notification and rtcpm (if necessary) automatically start. Then rtcpm starts all the other Oracle Real-Time Collaboration processes it needs to manage.
If you use rtcctl start with another option (for example, to start a specific component or instance) the Process Manager process must already be running.
The rtcctl stop command with no arguments shuts down rtcpm and all of the processes it is managing.
The Oracle Presence Server provides the services required for instant messaging, chat conferences, and publishing presence of Oracle Messenger users. You may have installed Oracle Real-Time Collaboration core components on more than one instance, and therefore have more than one presence server process available, but only one of those processes can be running at any given time. Each server process has a special high-availability monitoring process associated with it, which is started when the server process is started. The monitoring process will attempt to restart the presence server process if it goes down; if the monitoring process is not able to restart the server process, the monitoring process for the next available presence server will make its server the active process.
Each presence server process has its own high-availability process. When you stop the server process (using rtcctl stop -cname rtc-imrtr), the high-availability process will stop as well. As with all Oracle Real-Time Collaboration processes, you can view logs for the high-availability process in the log file directory, at $ORACLE_HOME/imeeting/logs/imHaProcess.
Although processes to support services such as Web Conferencing may be running, you also must ensure that the processes can actually support those services on a particular instance. Use the rtcctl runTests command to run tests to determine the availability of Oracle Real-Time Collaboration services.
Oracle Real-Time Collaboration also publishes interfaces for service availability monitoring that can be integrated into any monitoring infrastructure. See "Oracle Real-Time Collaboration Monitoring Interfaces" for more information.
For details about the syntax of rtcctl runTests, see "Testing and Monitoring the System".
The following sections cover these service tests:
Web Client Service Availability (apptest option)
Database Connectivity (dbtest option)
Document Conversion Service Availability (docconvtest option)
Oracle Messenger Service Availability (imtest option)
Web Conferencing Service Availability (mtgtest option)
Voice Conversion Service Availability (voiceconvtest option)
See "Running Configuration Tests" for details about using the additional runTests command options that let you check system configuration.
The apptest option tests whether the Applications tier can access the Oracle Real-Time Collaboration Web Client pages through HTTP.
If this test fails, check that the Oracle HTTP Server and OC4J_imeeting processes are running. If they are not running, stop and restart them as follows:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
The dbtest option tests the connectivity between Oracle Real-Time Collaboration and the database.
If this test fails, use sqlplus to log in to the database from the Applications tier. If that connection is successful, then stop and restart the OC4J_imeeting process:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
The docconvtest option tests the availability of the Document Conversion service by uploading a test document and trying to convert that document using the Document Conversion Server available to the instance.
If this test fails, it may be that no Document Conversion Server has been installed. If you have installed a server and have also created clusters, make sure that the server has the same InstanceLocation value as the instances it serves. Use the getProperty command as described on to see the InstanceLocation value. See "Configuring Clusters" for details about how to set the value.
If you have set up a Document Conversion Server for this instance, use rtcctl getState on the Oracle Real-Time Collaboration Applications tier to make sure the Applications tier processes are up and running. If they are, stop and restart the Document Conversion Server:
%ORACLE_HOME%\imeeting\bin\rtcctl rtcctl> stop -ct docconv rtcctl> start -ct docconv rtcctl> getState
If the test still fails, stop and restart the OC4J_imeeting process:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
The imtest option tests that Oracle Messenger services are available by mimicking the flow of two users sending and receiving messages.
If users are able to sign in to the Oracle Messenger, and the rtcctl getState command shows that all Oracle Messenger components are running, but the imtest shows as failed in the Status report under the System tab, you should check the connectivity to the database from the Oracle Presence server. Make sure that the tnsnames.ora file on the Applications tier is correctly configured to let you to run sqlplus from $ORACLE_HOME to the database containing the RTC schema.
If, after several hundred users were online with Oracle Messenger, the Oracle Real-Time Collaboration server was restarted and the imtest fails, wait and restart the imtest again. Oracle Messenger is configured to auto-reconnect when a server disconnects. All users who were online and who have opted to save their login information will auto-reconnect after one to six minutes, so there is considerable load on the server-side for authenticating and logging in all the users. The imtest is not expected to succeed reliably during that time. However, approximately six minutes after restarting the Oracle Presence server, the imtest should pass consistently.
The mtgtest option tests the Web Conferencing Server by mimicking the flow of a user going through the Web Client to start an instant conference. It makes sure that the conference starts successfully on one of the available conference servers in an instance. It then joins another client to the same conference, and makes sure that the new client gets a conference state consistent with what the host client receives. Then it ends the test conference.
If this test fails, do the following:
Use rtcctl getState to make sure that one or more multiplexer (mx) and one or more conferencing server (confsvr) processes are up in this instance. If they are not, skip to Step 4. If they are, go on to Step 2.
Go to the login page for your Oracle Real-Time Collaboration Web Client, for example, http://yourcompany.com/imtapp/app/prelogin.uix. What you do next depends on the error message you see in the browser:
If you see a DNS server error, stop and restart the Oracle HTTP Server:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server
If you see a 500 Internal Server error, stop and restart both the Oracle HTTP Server and the OC4J_imeeting processes:
$ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=HTTP_Server $ORACLE_HOME/opmn/bin/opmnctl stopproc ias-component=OC4J process-type=OC4J_imeeting $ORACLE_HOME/opmn/bin/opmnctl startproc ias-component=OC4J process-type=OC4J_imeeting
If you see the login page, log in.
If you cannot log in, then there is a Single Server Sign-On problem.
If you can log in, go on to Step 3.
On the Oracle Real-Time Collaboration home page, try to start an instant conference.
If you see the message, Cannot find suitable collaboration server, stop and restart OC4J_imeeting as described in Step 2.
If the mtgtest test still fails, enter the following on the Oracle Real-Time Collaboration Applications tier:
$ORACLE_HOME/imeeting/bin/rtcctl getMonitorStats
If no results are shown, stop and restart the Web Conferencing Applications tier:
$ORACLE_HOME/imeeting/bin/rtcctl rtcctl> stop rtcctl> start rtcctl> getState
The voiceconvtest option tests the Voice Conversion service for streaming voice data, by attempting to connect to an available Voice Conversion Server, making sure the T1 line is up, that voice channels are available, and that the server is able to stream audio.
If this test fails, it may be that no Voice Conversion Server has been installed. If you have installed a server and have also created clusters, make sure that the server has the same InstanceLocation value as the instances it serves. Use the rtcctl getProperty command to see the InstanceLocation value. See "Configuring Clusters" for details about how to set the value.
If the test fails, do the following on the Applications tier where the Voice Conversion Server instance is running (a Windows machine):
%ORACLE_HOME%\imeeting\bin\rtcctl rtcctl> stop -ct voiceconv rtcctl> start -ct voiceconv rtcctl> getState
If the test still fails, stop and restart the Web Conferencing Applications tier:
$ORACLE_HOME/imeeting/bin/rtcctl rtcctl> stop rtcctl> start rtcctl> getState
The Status report available from the System tab includes the results of service availability tests run periodically on the system. The tests include those for the Web Conferencing services, Document and Voice Conversion services, and Oracle Messenger services. You can click to expand or contract hierarchical lists of instances and their components.
The report also shows information about active conferences and chat sessions, the properties set for the system, and details about currently running Web Client sessions.
Only users with the businessadmin role can use the System tab. See "Setting User Roles" for details about setting user roles.
You can set up a monitoring infrastructure to periodically ping the Oracle Real-Time Collaboration core components. For example, assuming the URL for the instance is my.company.com, you can set a cron job (on UNIX or Linux) to ping the following URLs. You can then plug the output in to an alert management system. You can test for any of the services that the runTests command can test, as well as run any of the configuration tests. The syntax of the URL is:
http://my.company.com/imtapp/RtcServiceTests?test_name=true
The testname can be any of the following:
apptest web client service test
dbtest database connectivity test
docconvtest document conversion service test
emailtest e-mail configuration test
imtest Oracle Messenger system test
mtgtest conference service test
voiceconvtest voice conversion service test
You can use the rtcctl getMonitorStats command to view monitoring data for some of the key components in the system.
For each Web Conferencing Server on an instance, you can list the number of active conferences and users, the total available and used memory, and the total number of conferences since this process was started.
For each Voice Conversion Server on an instance, you can list the total number of voice streaming channels, currently used channels, bad channels, and the status of the T1 line.
For the running Presence Server on an instance, you can list its status.
The -publish true option outputs XML data. If you have your own monitoring infrastructure, you can run this process periodically to gather XML data that your monitoring system can use for historical analysis.
For details about getMonitorStats syntax, see "Testing and Monitoring the System".
The Monitor tab on the Oracle Real-Time Collaboration Web Client pages lets you interactively monitor the conferences that are currently running on the system. Only users with the businessmonitor or businessadmin role can use the Monitor tab. See "Setting User Roles" for details about setting user roles.
The Current Conference Status page lists all the conferences that are currently running on the system. For each conference, it provides the conference ID, conference title, host name, conference type, site, start time, total attendees, and current status of the conferences. If many conferences are running on this server, you can choose to display conferences by ID, conference title, host name, or the site from which this conference was started.
Clicking on the Conference Details link lets you choose to view basic details about the conference (start date and time, host name, and so forth).
You can click Diagnostics on the Details page to view all events that occur for this conference as it runs. You can use this page to monitor important conferences, so that you can take action if problems occur.
Archived log file lists every event as it takes place during this conference, including actions such as entering or exiting the conference, or changing the properties of the conference (for example, the host assigns presenter status to a participant). Completed log files are also available from Logs under the System tab, and from the report for this finished conference under the Reports tab (see "Web Conference Reports" for details).
Instance diagnostics lists details about the Oracle Real-Time Collaboration server processes as they run. You can use this information to manage current processes and to end processes directly from this page, if desired. This report is also available from the report for this finished conference under the Reports tab.
Clicking the Attendees tab on the Details page displays the list of attendees that are participating in this conference. Click Attendee Details next to the attendee's name to view details about how long the attendee has been in the conference, whether they are attending anonymously, whether they have had to reconnect to the conference, and whether they are using streaming voice. You can also see the operating system and screen resolution of the computer the attendee used to connect to the conference, and the connection type used to connect the client.
You can use the runTests command to confirm that the Oracle Real-Time Collaboration system has been configured properly. These tests need to be run only once after an installation, and need not be run periodically. The following sections describe each test and the option you use to run it.
See "Testing and Monitoring the System" for details about the syntax of the runTests command and its options.
The following section covers this configuration test:
E-Mail Configuration Test (emailtest option)
See "Monitoring Service Availability" for details about using the additional runTests command options that let you test the availability of different Oracle Real-Time Collaboration services.
To let meeting hosts to send e-mail invitations from a scheduled conference, an administrator must set the enterprise SMTP host and port through Oracle Web Conferencing properties. The emailtest option makes sure that these properties are set and that the SMTP server is accessible from the Oracle Real-Time Collaboration Applications tier.
If the test fails, follow the steps in "Setting Up Oracle Real-Time Collaboration E-mail and Administration".
The Configuration status report available from the System tab shows the current settings for all hosts for this Oracle Real-Time Collaboration system. It displays the host name, type of service, deployment information (whether the host is in the intranet, Internet, or DMZ), instance location if any, operating system, and hardware information (platform, CPU, and total memory). The report also has an Edit button to let you interactively edit some of the properties for each server listed, and a Delete button to let you delete the service.
Only users with the business administrator role can use the System tab. See "Setting User Roles" for details about setting user roles.
This section discusses Oracle Real-Time Collaboration monitoring interfaces that can be plugged in to any monitoring infrastructure. There are two types of interfaces:
rtcctl interfaces for getting monitoring data about key Oracle Real-Time Collaboration components
Servlet interfaces for monitoring service availability
You use the rtcctl getMonitorStats -publish true command to gather component statistics in XML format for output to a monitoring infrastructure. See "Monitoring Components" for more details about the statistics gathered.
By default, you can use rtctest.jsp to run the servlet as an authenticated user who has administrator privileges. If you want to run the servlet without requiring authentication, you must set the RtcTestServlet property to true, and use http://host:port/imtapp/RtcServiceTests.
If enabled, RtcServiceTests lets the service tests of the runTests command be run by any monitoring infrastructure. RtcServiceTests acts as an API that makes all Oracle Real-Time Collaboration tests available as a Web application to HTTP-based Web application monitoring. The servlet is accessible to standard HTTP-based monitoring clients, and its results are designed for automated analysis.
You can display the output of your monitoring infrastructure under the Availability sub-tab of the Reports tab, by pointing that page to a web-based report you generate. See "Configuring the Availability Report" for details.
Both rtctest.jsp and RtcServiceTests use the inputs listed in Table 5-1, and produce the same output.
To run the servlet as an authenticated user, such as an administrator with businessadmin privileges, you use rtctest.jsp, as follows:
http://host:port/imtapp/app/rtctest.jsp?alltests=true
If you want to run the servlet without requiring authentication, you must set the RtcTestServlet property to true, and use RtcServiceTests, as follows:
http://host:port/imtapp/app/RtcServiceTests?alltests=true
For security reasons, access to RtcServiceTests is disabled by default. If you enable access to it, it is recommended that you use Oracle HTTP server access control or some other mechanism to limit access to RtcServiceTests.
Description: Sets whether RtcServiceTests can be run.
Default Value: false
Valid Value: false, true
Scope: system
Example: To enable access to RtcServiceTests without requiring authentication, set the property to true:
rtcctl> setProperty -pname RtcTestServlet -pvalue true -system true
The servlet gets all input information from HTTP requests sent by the client. The servlet accepts parameters either through a URL query string or within a POST body.
Input parameters control which tests are run and the information that is returned in the case of success or failure. Table 5-1 lists all the input parameters.
Table 5-1 Servlet Inputs
| Name of Test | Options | Default | Function |
|---|---|---|---|
|
alltests |
true, false |
false |
Runs all tests supported by the servlet (other test selection parameters are ignored). |
|
mtgtest |
true, false |
false |
Runs the end-to-end conference test to verify that conference functionality is available. |
|
voiceconvtest |
true, false |
false |
Runs the Voice Conversion Server test to verify that voice support is available for conferences. |
|
docconvtest |
true, false |
false |
Runs the Document Conversion Server test to verify that document conversion is available. |
|
dbtest |
true, false |
false |
Runs the Oracle Real-Time Collaboration Repository test to verify that it is available. |
|
imtest |
true, false |
false |
Runs the end-to-end Oracle Messenger test to verify that messaging services are available. |
|
errorcode |
any valid HTTP response code |
500 |
Sets the HTTP response code sent when any of the selected tests fail. |
|
successcode |
any valid HTTP response code |
200 |
Sets the HTTP response code sent when all of the selected tests succeed. |
|
errormsg |
Any string |
null |
Includes a message in the response body when any of the selected tests fail. (Note: the response body may include additional text.) |
|
successmsg |
Any string |
"Test(s) successful." |
Includes a message in the response body when all of the selected tests succeed. (Note: the response body may include additional text.) |
The servlet provides results in an HTTP response. Results either report that all of the selected tests succeeded or that some test failed. If multiple tests are selected with input parameters, the result provides no details about which particular tests failed. Furthermore, no messages associated with the failure are returned.
The result of the test or tests is reflected in both the HTTP response code and, optionally, in a static string returned in the response body.
Because the test reports only aggregate results when running multiple tests, if you need fine-grained detail in your results, run multiple tests, each calling one of the individual service availability tests. If you just want a single indicator of the system's health, run a single test using the alltests option.
Following are some examples of output from the test servlet.
http://host:port/imtapp/app/rtctest.jsp
Confirms that the test servlet has been properly installed, but does not run any tests.
http://host:port/imtapp/RtcServiceTests
Confirms that the test servlet has been properly installed, but does not run any tests. You must set the RtcTestServlet property to true to use RtcServiceTests since it is disabled by default.
http://host:port/imtapp/RtcServiceTests?alltests=true
Runs all of the tests returning the standard error (500) and success (200) codes.
http://host:port/imtapp/RtcServiceTests?mtgtest=true&errorcode=404
Runs only the end-to-end conference test and returns 404 if the test fails.
http://host:port/imtapp/RtcServiceTests?mtgtest=true&voiceconvtest=true&errormsg=mtgorvoicefailed
Runs the conference and voice tests and reports a custom message on failure, in addition to a standard 500 response code.
The servlet is currently limited in the following way. Because the servlet runs in an OC4J_imeeting process, the inaccessibility of the OC4J_imeeting will prevent granular detection of failures in other Oracle Real-Time Collaboration components, such as the Web Conferencing or Document Conversion Servers. However, this limitation is minor, because OC4J_imeeting is the gatekeeper for all Oracle Real-Time Collaboration services. Inaccessibility of OC4J_imeeting is equivalent to inaccessibility of all Oracle Real-Time Collaboration services from a client's perspective.
During the shutdown phase of Oracle Application Server Containers for J2EE (OC4J), the OC4J container may send a response code of 200 and a body of size 444 without actually invoking the test servlet or any tests. The message returned is probably a generic message about the servlet not being loaded. Because the standard test success code is 200, a monitoring application may incorrectly interpret this result as test success.
It is unlikely that the OC4J behavior can be changed. Instead, monitoring applications must do either of the following:
Search the actual response body to be sure that the tests actually ran. Searching for "<test-failure-count>0" is a positive confirmation that the tests ran and that none failed.
Customize the monitoring application to expect a response code other than 200 for test success using the "successcode" query string parameter. For example, the unassigned HTTP success code 299 could be used to indicate actual test success. The monitoring application should then be configured to treat anything other than 299 as a test failure. For example:
http://host:port/imtapp/RtcServiceTests?alltests=true&successcode=299
If the monitoring application cannot be customized to recognize an alternate response code for success or to search for a particular pattern in the response body, then the results of the monitoring application must be treated as unreliable during OC4J shutdown. Tests failures during a shutdown are expected because the OC4J will be temporarily unavailable, but test successes around the time of shutdown are equally unreliable under these conditions.
