C H A P T E R 1

System Monitoring

The Content Delivery Server provides the Application Monitoring Agent for monitoring the state of the Content Delivery Server. This agent supports Simple Network Management Protocol (SNMP) and can be integrated with your existing network monitoring system.

The Content Delivery Server components also record information in log files that you can use to review the state of the system.

1.1 Application Monitoring Agent

The Application Monitoring Agent provides information on the status of the Content Delivery Server. This agent enables your existing network monitoring system to monitor the availability of the Content Delivery Server components. You can also monitor the connections between the Content Delivery Server and external systems such as your billing system or subscriber database. The agent is activated when the Monitoring Service is started.

The Application Monitoring Agent provides a Management Information Base (MIB) that describes the statuses and alarms issued by the Content Delivery Server. This information is contained in the CDS36MibModule.mib file in the $CDS_HOME/deployment/deployment-name/conf directory. Configure your network monitoring system to use this MIB specification. See the product documentation for the network monitoring system that you are using for information on loading the MIB.

TABLE 1-1 shows the status information provided through the MIB. Your network monitoring system can query the Application Monitoring Agent for any of these statuses. A status of 1 indicates that the component is running. A status of 0 indicates that the component is down.

TABLE 1-1 Status Notifications
Status	Description
`cdsServerStatus`	Status of the Content Delivery Server core server
`eventServiceStatus`	Status of Content Delivery Server Event Service
`messagingServiceStatus`	Status of the Content Delivery Server Messaging Service
`postPaidServiceStatus`	Status of the Content Delivery Server Postpaid Service

TABLE 1-2 shows the alarms issued by the Content Delivery Server when a problem is detected. In general, an alarm indicates that a particular component is unavailable. Restart the component indicated to ensure that the Content Delivery Server continues to operate correctly.

TABLE 1-2 Alarms Generated by the Content Delivery Server
Alarm	Description
`dbConnectionDown`	Connection to the database is down.
`smscConnectionDown`	Connection to the SMSC is down.
`ppgConnectionDown`	Connection to the PPG is down.
`subscriberDirectoryConnectionDown`	Connection to the external subscriber database is down.
`downloadFailure`	Download failure occurred while attempting to download content to a subscriber.
`httpPushConnectionDown`	Connection to the HTTP-based SMSC is down.
`missingExternalContent`	Externally hosted content is no longer available from the remote location.
`remoteVendingDown`	Vending Manager is not running.
`catalogJMSDown`	Java Message Service (JMS) associated with the Catalog Manager is not running.
`vendingJMSDown`	JMS associated with the Vending Manager is not running.
`notificationProcessingFailure`	Notification of change from one component to another failed.
`catalogStarted`	Catalog Manager started.
`vendingStarted`	Vending Manager started.
`newVendingAccountRegistered`	New Vending Manager registered with the system.
`vendingNetworkIdUpdated`	Network ID for a Vending Manager changed.
`vendingAccountUnregistered`	Vending Manager dropped out of the system.

1.2 Log Files

As the Content Delivery Server executes, the components record information in the following log files, which are found in the $CDS_HOME/deployment/deployment-name/logs directory:

CDS.log.n. Contains messages generated by the Content Delivery Server components.

n is a value from 0 to the maximum number of archive files specified for the java.util.logging.FileHandler.count property in the $CDS_HOME/deployment/deployment-name/conf/logging.properties file. CDS.log.0 is the current log. An archive file is created when the Content Delivery Server is started or when the maximum number of records specified for the java.util.logging.FileHandler.limit property in the logging.properties file is reached.

cdsdb.log. Contains messages generated by the Database Encoding Check command.

Database Encoding Check is performed when the Content Delivery Server is started using the cdse startserver command.

db.log. Contains messages generated when running the cdsi db command.

Review the log files for exceptions, lines flagged as SEVERE, or other indications of problems. See the Sun Java System Content Delivery Server Error Messages for descriptions of messages that you might receive and suggested actions that you can take in response.

The Content Delivery Server uses the logging utility that is available with the Java Software Development Kit (SDK) 1.4. You can manage the logging files according to the capabilities of the utility by setting properties in the logging.properties file in the $CDS_HOME/cfg directory. This file controls the logging properties for all Content Delivery Server functions. See the output of the Javadoc trademark tool for the package containing the utility for more information.

The messages that are written to the log are determined by the level of logging that is set. The following levels are valid in order from most restrictive to least restrictive.

ALL. All messages are logged.

SEVERE. Only messages indicating severe problems are logged.

WARNING. Warnings are logged.

INFO. Informational messages are logged.

CONFIG. Static configuration messages are logged.

FINE. Tracing information is logged.

FINER. Fairly detailed tracing information is logged.

FINEST. Highly detailed tracing information is logged.

OFF. No messages are logged.

The log includes messages at the specified level and messages at higher levels. For example, if the level is set to WARNING, the log contains messages marked as SEVERE and WARNING. The Content Delivery Server uses only SEVERE, WARNING, INFO, and FINE for its messages.

The logging utility supports several handlers. The Content Delivery Server uses only the file handler and the console handler. The following table describes the properties to set.

TABLE 1-3 Logging Properties
Property	Description
`.level`	Specifies the default level of information for handlers that are not specifically set.
`java.util.logging.FileHandler.level`	Specifies the level of information written to the file.
`java.util.logging.ConsoleHandler.level`	Specifies the level of information written to the console.

1.3 Interaction with External Systems

The Content Delivery Server interacts with your existing billing system and subscriber database. The Content Delivery Server also interacts with its own Oracle database. This section describes the work flow between components.

For information on integrating the Content Delivery Server with external systems, see the Sun Java System Content Delivery Server Integration Guide.

1.3.1 Billing System Workflow

The Content Delivery Server supports both prepaid and postpaid billing models. For prepaid billing models, the billing system is contacted for authorization before a subscriber is permitted to purchase and download content. For postpaid billing models, the billing system receives purchase information after the transaction occurs.

For prepaid billing implementations, the Content Delivery Server contacts the billing system before each of the following transactions. The billing system can decide whether to allow or reject the transaction. For postpaid billing implementations, after each of the following transactions, the Content Delivery Server generates an event that contains the information for the billing system to process according to its own schedule.

A subscriber views details. For prepaid billing, the billing system has the option of returning a customized price for the content selected.

A subscriber purchases content.

A subscriber downloads content.

A subscriber purchases a subscription.

A subscriber cancels a subscription.

A refund is issued to a subscriber.

The device confirms a successful download.

The device reports an error.

1.3.2 Subscriber Database Workflow

If the Content Delivery Server is configured to work with an external subscriber database, the information kept in the Vending Manager for each subscriber who accesses the Subscriber Portal is limited to the subscriber's login ID, mobile phone number, device information, and Subscriber Plan. The Vending Manager also keeps information on the subscriber's download history. For profile information such as the subscriber's name and address, the Content Delivery Server contacts the external subscriber database.

If the external database allows the Content Delivery Server to change the subscriber records, the Vending Manager administrator can edit the profile information through the Accounts Management feature of the Vending Manager administration console. If the external database does not allow the Content Delivery Server to make changes, the Vending Manager administrator can only view the profile information for subscribers.

Subscriber profiles are reflected in the Content Delivery Server only after a subscriber accesses the Subscriber Portal. At that time, a Subscriber Account is created in the Vending Manager. The Vending Manager Administrator can view a list of all Subscriber Accounts without interaction with the subscriber database. When the administrator opens a Subscriber Account, the Content Delivery Server contacts the subscriber database and retrieves the profile information.

The Content Delivery Server also contacts the external subscriber database to perform the following tasks:

Verify authorization when the subscriber logs in to the Subscriber Portal.

Update the account when the subscriber changes the password.

Send a reminder to subscribers who have forgotten their password.

Access a subscriber's MSISDN or email address for campaigns.

1.3.3 Content Delivery Server Database Workflow

The Content Delivery Server uses JDBC trademark API Type 4 drivers to communicate with the database. With the exception of error logs and system configuration properties, all Content Delivery Server data is maintained in the database.

The database is accessed each time information needs to be presented to a user through the Subscriber Portal or the Developer Portal, or to an administrator through the Catalog Manager or Vending Manager administration consoles. To minimize access to the database, you can specify that the database information be cached by setting the cache.enabled property in the $CDS_HOME/deployment/deployment-name/conf/cache.config file.

The Content Delivery Server has built-in fault tolerance so it continues to run even if the database fails and can manage stale connections to the database. An error message is issued and logged for each failed transaction and the Content Delivery Server continues processing. Database access must be restored to process the transactions that occur.