| Oracle® Web Conferencing Administrator's Guide Release 2 (2.0.4.3) Part Number B10877-03 |
|
|
View PDF |
| Oracle® Web Conferencing Administrator's Guide Release 2 (2.0.4.3) Part Number B10877-03 |
|
|
View PDF |
This chapter describes how you can monitor Real-Time Collaboration components to provide quality of service for conferences and uninterrupted availability for conference service. This chapter discusses:
How the system monitors all Real-Time Collaboration processes and restarts them if they are down.
How you monitor whether an instance in a system is capable of providing the direct services.
How you monitor performance statistics for tuning the Real-Time Collaboration system
How you monitor current conferences, including events for each conference.
How to verify key configuration setup.
Interfaces that allow Real-Time Collaboration services to be monitored by any monitoring system.
The Real-Time Collaboration Process Monitor (imt-pm) is a Java-based process that runs as a daemon, managing all Real-Time Collaboration processes in an instance. The Real-Time Collaboration Process Monitor opens an HTTP listening point to accept requests to start and stop processes. Specifically, it does the following:
Periodically pings all 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) without manual intervention.
The Oracle Process Management and Notification system monitors imt-pm and serves as a watchdog for it. The Oracle Process Management and Notification system automatically restarts imt-pm if it detects it to be inactive. If imt-pm goes down, there is no impact on the processes that were being monitored by imt-pm. imt-pm can recover its state without affecting the processes that it was monitoring before it went down.
imtctl> start
When you invoke the start command with no arguments from imtctl, Oracle Process Management and Notification, and imt-pm (if necessary) automatically start, which then starts all the processes it needs to manage.
Other start commands require that imt-pm already be running.
imtctl >stop
The stop command with no arguments (stopall behavior) shuts down imt-pm and all of the processes it is managing.
With Oracle Real-Time Collaboration, you can check service availability on an instance. Sometimes, it might not be enough for the processes to be up. It is also important that the instance be able to provide the conference services.
Using imtctl, determine service availability by invoking:
imtctl> runtests -testlist mtgtest,voiceconvtest,docconvtest
This command checks if the instance on which the command is executed is providing the following services:
Conference service—A conference test mimics the behavior of an end-user going through the same flow of Oracle Web Conferencing Application as the user, and starting an instant conference. It makes sure that the conference starts successfully on one of the available collaboration servers in an instance. It then joins another client in the same conference, and makes sure that the new client also gets the conference state consistent with the host of the conference. It finally ends the test conference. This test thus makes sure that conference service is available in a particular Real-Time Collaboration instance. If this test fails, make sure that one or more mxs, and one or more collaboration servers are up in this instance (using imtctl> getState).
Voice conversion service—This test verifies that voice streaming service is available by mimicking the behavior of a collaboration server for connecting to an available voice conversion server, and making sure that T1 line is up, there are available voice channels, and the server is able to stream audio. If this test fails, then either no voice conversion server has been setup to service this instance, or the ones configured are not available.
Document conversion service—This test verifies document conversion service availability by mimicking document conversion flow. It uploads a test document, and then tries converting that document using the document conversion servers available to the instance. If this test fails, then either no document conversion server has been setup to service this instance, or the ones configured are not available.
Real-Time Collaboration also publishes interfaces for service availability monitoring that can be integrated into any monitoring infrastructure. See "Real-Time Collaboration Interfaces" for more information.
The service availability tests can be invoked periodically by a monitoring infrastructure, and the results of the tests can be plugged into an alert management system.
For more details about runtests see Chapter 10, "Testing and Monitoring the System".
With Oracle Real-Time Collaboration, you can get monitoring data for the key components in the system. The monitoring data includes the following.
For each imt-collab on an instance, you can obtain the following data:
number of active conferences
number of active users
total memory
used memory
total conferences since the time the process was started
Use getMonitorStats on the instance to get these statistics, or use the -i option to direct the command towards a different instance.
For the Voice Conversion Server on that instance, you can obtain the following data:
total number of channels
currently used channels
bad channels
T1 line status
Use getMonitorStats on the instance to get these statistics, or use the -i option to direct the command toward a different instance.
Oracle Real-Time Collaboration publishes interfaces for getting this data in XML. This can then be invoked periodically by a monitoring infrastructure for historical analysis. Use getMonitorStats with the publish option.
imtctl> getMonitorStats -publish true
For details about getMonitorStats, see "Testing and Monitoring the System".
The Oracle Web Conferencing Application provides Web pages to monitor the conferences that are currently running on the system. The Monitor tab in the Web Conferencing Application provides access to this functionality.
|
Note: 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 under the Monitor tab 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. It also provides a Conference Details link, so you can see detailed information about each conference that is currently running.
In the Conference Details pages, you can find information about the attendees participating in that conference, including details about each attendee. Conference level details like current collaboration mode, voice start time, and so on can also be found in these pages. You can also see the conference logs for this conference from this page.
The Instances Status Page is available from the System tab in the Web Conferencing Application Web pages.
|
Note: Only users with the businessadmin role can use the Monitor tab. See "Setting User Roles" for details about setting user roles. |
The Instances report lets you further monitor the activity of instances and components running within the Web Conferencing system. You can click to expand or contract hierarchical lists of instances and their components. The report also shows the results of tests on instances, the progress of active conferences, the properties set for the system, all sites created for the system, and details about currently-running Web Application sessions.
The following tests confirm that some important post-installation steps, like e-mail configuration, which are required for the proper functioning of the Real-Time Collaboration system have been successfully completed, and serve as a verification tool for the administrator. These tests need to be run only once after an installation, and need not be run periodically. See "Testing and Monitoring the System" for details about running the tests.
E-mail Configuration Test
This test checks whether the post-installation step required for Oracle Web Conferencing e-mail invitations to work has been performed by the administrator. For e-mail invitations to work, enterprise SMTP host and port should be specified through Oracle Web Conferencing properties. The test makes sure that these properties are set and the SMTP server is accessible from the Oracle Real-Time Collaboration mid-tier.
Proxy Configuration Test
This test checks whether the post-installation step required for Oracle Web Conferencing cobrowsing to work has been performed by the administrator. This test needs to succeed only if the mid-tier needs an enterprise server to access internet. This test makes sure that the properties required for proxy configuration are set, and that the proxy server is accessible from the Oracle Real-Time Collaboration mid-tier.
MX Configuration Test
To support internet users where clients need to connect from behind their corporate proxies, mod_imeeting needs to be enabled and some properties need to be set in the Real-Time Collaboration system. This test makes sure that the required properties are set, and that mod_imeeting has been enabled to handle HTTP/HTTPS requests to connect to Mx.
Repository (Database) Access Test
Because all Real-Time Collaboration services depend on the database as the single-point of information and backbone, a test is provided to verify access to the Real-Time Collaboration Repository. This test makes sure that database is available (that is, it is accessible and responding to queries).
The Configuration status report is available from the System tab in the Web Conferencing Application Web pages.
|
Note: Only users with the businessadmin role can use the Monitor tab. See "Setting User Roles" for details about setting user roles. |
The Configuration report shows the current settings for all services for this Web Conferencing system. It displays the host name, type of service, deployment information (whether the host is in the intranet, Internet, or the 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.
This section discusses Real-Time Collaboration monitoring interfaces that can be plugged into any monitoring infrastructure. There are two types of interfaces:
Servlet interface—for monitoring service availability
imtctl interfaces—for getting monitoring data about key Real-Time Collaboration components.
Oracle Web Conferencing includes a suite of functionality tests that are designed to verify the availability of major Web Conferencing functionalities. The tests cover Real-Time Collaboration Repository connectivity, Voice Conversion Server availability, Document Conversion Server availability, application availability, and the ability to launch an instant conference.
The ImtTestServlet lets these tests be run by any monitoring infrastructure. ImtTestServlet acts as an adapter that makes all 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. Its results are designed for automated analysis. ImtTestServlet is the most flexible choice for low-effort integration of existing monitoring systems with the Real-Time Collaboration functionality tests.
As an HTTP servlet, ImtTestServlet gets all of its input information from HTTP requests sent by the client. The servlet accepts parameters either through the URL query string or via a POST body. Either way, the same parameters are supported. Input parameters control which tests are run and the information that is returned in the case of success or failure.
Table 7-1 Inputs to the ImtTestServlet
| Name of Test | Options | Default | Comments |
|---|---|---|---|
| alltests | true, false | false | Run all tests supported by the servlet (other test selection parameters are ignored). |
| mtgtest | true, false | false | Run the end-to-end conference test to verify that conference functionality is available. |
| voiceconvtest | true, false | false | Run the Voice Conversion Server test to verify that voice support is available for conferences. |
| docconvtest | true, false | false | Run the Document Conversion Server test to verify that document conversion is available. |
| dbtest | true, false | false | Run the Real-Time Collaboration Repository test to verify that it is 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 | Message included in the response body when any of the selected tests fail. (Note: the response body may include additional text, as well.) |
| successmsg | Any string | "Test(s) successful." | Message included in the response body when all of the selected tests succeed. (Note: the response body may include additional text, as well.) |
The ImtTestServlet provides its results via an HTTP response. Results either report that all of the selected tests succeeded or that some test failed. If multiple tests are selected via 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. It is anticipated that these two mechanisms will be sufficient to allow integration products to detect whether the test succeeded or failed.
Because the test servlet reports only aggregate results when running multiple tests, Oracle Corporation advises that the servlet be called multiple times independently when fine-grained failure detection is desired (one request for each test to be run). However, you might choose to have a single indicator of system health, in which case, running all of the tests in a single request is an optimal configuration.
The following examples are designed to illustrate some of the input parameter combinations that might be useful. The examples are templated to account for variable host names, ports, and application root contexts.
http://<host>:<port>/<root-context>/servlet/ImtTestServlet
This confirms that the test servlet has been properly installed. It does not run any tests.
http://<host>:<port>/<root-context>/servlet/ImtTestServlet?alltests=true
This runs all of the tests returning the standard error (500) and success (200) codes.
http://<host>:<port>/<root-context>/servlet/ImtTestServlet?mtgtest=true&errorcode=404
This runs only the end-to-end conference test and returns 404 if the test fails.
http://<host>:<port>/<root-context>/servlet/ImtTestServlet?mtgtest=true&voiceconvtest=true&errormsg=mtgorvoicefailed
This runs the conference and voice tests and reports a custom message on failure, in addition to a standard 500 response code.
The ImtTestServlet is currently limited in the following way. Because the servlet runs in an OC4J_imeeting, the inaccessibility of the OC4J_imeeting will prevent granular detection of failures in other Real-Time Collaboration components, such as the Web Conferencing Servers and Document Conversion Servers. However, this limitation is minor, because OC4J_imeeting is the gatekeeper for all Web Conferencing services. Inaccessibility of OC4J_imeeting is equivalent to inaccessibility of all Web Conferencing services from a client's perspective.
