Return to Navigation

Understanding the WatchDog Utility

This section discusses:

WatchDog is a utility that monitors the Online Marketing server components and database access to ensure that they are operational. WatchDog can be set to send reports to specific email addresses the state of the components changes (from working to not working or vice versa). You can configure the WatchDog utility to check the following components:

  • Database (Microsoft SQL Server, Oracle, or DB2)

  • Online Marketing dialog server

  • Web server

  • Mail server

  • Scheduler

WatchDog can be set to run at any interval, and cycles through the tests for each component. (A typical interval is 30 minutes.) Before running the tests, WatchDog can attempt to communicate with each component (ping test). WatchDog generates an error when it cannot establish communication or when the component fails its tests.

WatchDog has two types of tests: a ping test to make sure that the component can be reached and tests that use commands to each component to ensure that they are running properly. WatchDog first pings each component a specified number of times. If a response is not received within the specified time-out period, WatchDog assumes that a problem exists with that component, generates an error report, and sends it to the email addresses specified in the WDG.config file. After the ping tests succeed, WatchDog runs basic tests on the various components.

To ensure that responses can be received within the time-out period, it is strongly recommended that you run WatchDog from within your corporate firewall. This action assures the fastest communication and helps prevent WatchDog from reporting communication problems due to network latency.

When WatchDog detects a problem, it sends an error report to the email addresses specified in the errorMailList parameter in the WDG.config configuration file. One or more of these email addresses can be to a pager to notify an administrator immediately about a problem. WatchDog sends a detailed email report containing a description of the problem and the current WatchDog configuration. For pagers, WatchDog formats an abbreviated message. WatchDog generates specific messages to describe problems detected within the Online Marketing components. When an error is detected outside Online Marketing, the report includes any messages generated by the component (such as the database, mail server, or web server).

In addition to notifying administrators of a problem, WatchDog can also provide you with periodic notification that it is still operational. It can send a special I am alive email to email addresses and pagers specified in the configuration file. The reason that you may want to use this feature is that WatchDog only notifies administrators when it detects a problem. If WatchDog has stopped running, you will not be notified of problems with Online Marketing. By setting WatchDog to send a periodic message, you will know when WatchDog is not working because the messages will not be sent.

The I am alive email includes the contents of the WDG.config file and the report generated from the most recent run of WatchDog, so you can view the status of each component.

You start and stop WatchDog through the Maintain Dialog Servers page in the Online Marketing Control Center.

See Maintaining Dialog Servers.

WatchDog also has a Quick Look feature that lets you check the status of WatchDog. When the WatchDog server receives a Quick Look request, it provides a short status of what WatchDog is doing at that time. If WatchDog is sleeping when the request is received, it wakes up and sends the last report, if one exists.

You can access WatchDog from a web browser or a DOS window. From a browser, specify the following URL, where host is the machine where WatchDog is running, and qkLookPort is the value set in the qkLookPort configuration parameter.

http://host:qkLookPort

From a DOS prompt, specify the following command from the directory where WatchDog is installed:

..\..\..\jvm\1.3.1\java -cp
.;.\annu13.jar;.\watchdog.jar;
..\..\..\driver\<driver_file>
WatchDog.WatchDog -qklook

WatchDog includes the following tests:

  • Database tests.

  • Web server tests.

  • Application server tests.

  • Scheduler tests.

  • Mail server tests.

  • Mail event tests.

  • Cluster tests.

Database Tests

WatchDog opens a connection to the database and runs a defined query. WatchDog does not evaluate the results of the query for correctness, only for successful completion. Only one database can be monitored.

WatchDog performs these database tests:

Field or Control

Definition
Database access

Checks whether a connection to the database can be established.
Driver

Checks whether the JDBC driver can be found and loaded.
Query

Checks whether a query can be executed.

Web Server Tests

WatchDog performs these web server tests:

Field or Control

Definition
Web Server

Checks if the web server (reverse proxy server) is accepting connections.
MCP

Checks whether the Marketing Campaign Processor (MCP) (the servlet that handles web requests for Online Marketing) is running by sending an are you there (rut) message and waiting for a response.
Database connection

Checks whether the Dialog Execution Server (DES) can connect to the database.
Online Marketing Dialog Server

Checks whether a dialog can be run properly by visiting a Landing Page and validating that the correct page is returned. WatchDog also submits the Landing Page to validate that the correct intermediate or Final Page is returned.

Application Server Tests

WatchDog performs this test:

Field or Control

Definition
Application Server

Checks whether the Application Server is running and can communicate with PeopleSoft Pure Internet Architecture. It does this by sending a request to the Dialog Execution Server servlet, which makes a Jolt call to PeopleSoft Pure Internet Architecture.

Mail Server Tests

WatchDog performs these Mail Server tests:

Field or Control

Definition
TCP layer

Checks whether a connection to at least one mail server can be established.
SMTP protocol layer

Checks whether a Simple Mail Transfer Protocol (SMTP) dialog can be established with at least one mail server.

Mail Event Tests

WatchDog performs these mail event tests:

Field or Control

Definition
Bulk Mailers

Connects to each Bulk Mailer via Remote Method Invocation (RMI) to get current system status. If WatchDog cannot connect via RMI, then the Bulk Mailer is assumed to be not running and the test fails.
Mail job

Checks the status of all mail jobs by querying the database.
Mail sending rate

Checks the sending rate of the mail jobs in the database.

Server Group Tests

WatchDog performs the following server group tests:

Field or Control

Definition
Scheduler

Checks whether the Scheduler is up and running by accessing its status in the database.

WatchDog sleeps between running each of the tests. The resulting report is saved and compared with the previous run for differences. If differences exist, the report is emailed so the administrator can be informed of changes in the system performance—for example, if a formerly working system has stopped responding or if a system that was not running has started again. Because of this, only pass or failure information is reported, and not statistical information (which would likely change with each run and result in too many reports).

Cluster Tests

If you are running in a clustered environment, WatchDog checks the status of each system as it is stored in the database.

Example WatchDog Report

The WatchDog report delivered by email looks similar to this:

WEB SERVER :
Running:  OK.
Executing Servlets:  OK.
DES:  OK.
Database connection:  OK.
Campaign Check:  OK.
Cluster: IS NOT WORKING.

For WatchDog to test the Online Marketing Dialog Server (DES), you must first create and launch a simple test dialog. The test dialog needs only three components (two web documents and an external audience), but the values used in the two web documents must also be set in several WatchDog parameters.

Before running WatchDog, you should create the test dialog, launch the dialog, and set the appropriate WatchDog parameters to the values used in the dialog.

When you run WatchDog, the DES test attempts to access the web pages and find the values specified in the parameters. The following example describes the simplest dialog you can create and the values you can use to perform the DES test. If you decide to use a value different from the sample, be sure to also use that value in the appropriate WatchDog parameter. This is because WatchDog uses the values in these parameters to perform a query against this test dialog.

Test Dialog

The test dialog you create must contain two web pages and an external audience. Each web page must contain a string that must also be used in the test parameters. The following list describes the contents of the test dialog:

  • Two web documents (a Landing Page and a Final Page).

    • The Landing Page must include three profile fields (first name, last name, and email), a paragraph item containing a string (landing_page_string), and a Submit button to display the Final Page.

    • The Final Page must contain a paragraph item containing a string (final_page_string).

  • One external audience.

Test Parameters

WatchDog uses four parameters to query the test dialog. For WatchDog to interpret the results of the query correctly, set the DES test parameters in the WDG.config file to match the values used in the web documents. Set these four parameters:

Field or Control

Definition
demoCampaignMagicNumber

Set to the magic number in the generated URL for the test dialog. The magic number is the end of the URL, beginning with “p= ...” or “q= ...”. The format is demoCampaignMagicNumber=p=<number>

or

demoCampaignMagicNumber=q=<number> (be sure to include both equal signs or errors can occur).

expectedResponseAfterGet

Set to a string on the Landing Page (landing_page_string). WatchDog searches for this string to verify that the Landing Page can be reached.
queryToSubmit

Set to the values for all the fields on the Landing Page the johnDrake number for that page and ”dialogFlowId" for that Dialog. A URL is constructed using the value and submitted, which simulates clicking the Submit button on the Landing Page.

In this query, you can specify any value for the fields.

Note: You can find the johnDrake and dialogFlowId number by viewing the HTML source of the Landing Page from the browser. It is located immediately before the </FORM> tag, indicated by johnDrake=nnnnn and dialogFlowId=nnnnn....
expectedResponseAfterPost

Set to a string on the Final Page (final_page_string). WatchDog searches for this string to verify that the Final Page can be reached.

The following examples show the test parameters: 

	demoCampaignMagicNumber=URL generated for your test dialog

	expectedResponseAfterGet=landing_page_string

	expectedResponseAfterPost=final_page_string

	queryToSubmit=First+Name=John (any_first_name)
		&Last+Name=Doe (any_last_name)
		&Email=john@watchtest.com (anyname@anydomain.com)
		&johnDrake=specific_number_found_on_your_web_page