17 Configuring Converged Application Server SNMP

This chapter describes how to configure and manage SNMP services with Oracle Communications Converged Application Server.

Overview of Converged Application Server SNMP

Converged Application Server includes a dedicated SNMP MIB to monitor activity on engine tier and SIP data tier server instances. The Converged Application Server MIB is available on both Managed Servers and the Administration Server of a domain. However, Converged Application Server engine and SIP data tier traps are generated only by the Managed Server instances that make up each tier. If your Administration Server is not a target for the sipserver custom resource, it will generate only WebLogic Server SNMP traps (for example, when a server in a cluster fails). Administrators should monitor both WebLogic Server and Converged Application Server traps to evaluate the behavior of the entire domain.

Note:

Converged Application Server MIB objects are read-only. You cannot modify a Converged Application Server configuration using SNMP.

Browsing the MIB

The Converged Application Server MIB file is installed in WLSS_HOME/server/lib/WLSS-MIB.asn1. Use an available SNMP management tool or MIB browser to view the contents of this file. See also "Trap Descriptions" for a description of common SNMP traps.

Configuring SNMP

To enable SNMP monitoring for the entire Converged Application Server domain, follow these steps:

  1. Login to the Administration Console for the Converged Application Server domain.

  2. If your domain is running in Production mode, click Lock & Edit.

  3. In the left pane, select the Diagnostics > SNMP node.

  4. In the Server SNMP Agents table, click the New button to create a new agent.

    Note:

    Ensure that you create a new Server SNMP agent, rather than a Domain-Scoped agent.
  5. Enter a unique name for the new SNMP agent (for example, "engine1snmp") and click OK.

  6. Select the newly-created SNMP agent from the Server SNMP Agents table.

  7. Select Configuration, then select the General tab:

    Note:

    You can also set this parameter to true by selecting the Symmetric Response Routing option. To do this, select Configuration, then select the General tab of the SipServer Administration console extension.
    1. Select the Enabled check box to enable the agent.

    2. Enter an unused port number in the SNMP UDP Port field.

      Note:

      If you run multiple Managed Server instances on the same machine, each server instance must use a dedicated SNMP agent with a unique SNMP port number.
    3. Click Save.

  8. Repeat the above steps to generate a unique SNMP agent for each server in your deployment (SIP data tier server, engine tier server, and Administration Server).

  9. If your domain is running in Production mode, click Activate Changes.

Understanding and Responding to SNMP Traps

The following sections describe the Converged Application Server SNMP traps in more detail. Recovery procedures for responding to individual traps are also included where applicable.

Trap Descriptions

This section describes the Converged Application Server SNMP traps.

overloadControlActivated, overloadControlDeactivated

Converged Application Server engines use a configurable throttling mechanism that helps you control the number of new SIP requests that are processed. After a configured overload condition is observed, Converged Application Server destroys new SIP requests by responding with "503 Service Unavailable" to the caller. The servers continues to destroy new requests until the overload condition is resolved according to a configured threshold control value. This alarm is generated when the throttling mechanism is activated. The throttling behavior should eventually return the server to a non-overloaded state, and further action may be unnecessary.

Recovery Procedure: Follow this recovery procedure:

  1. Check other servers to see if they are nearly overloaded.

  2. Check to see if the load balancer is correctly balancing load across the application servers, or if it is overloading one or more servers. If additional servers are nearly overloaded, Notify Tier 4 support immediately.

  3. If the issue is limited to one server, notify Tier 4 support within one hour.

Additional Overload Information: If you set the queue length as an incoming call overload control, you can monitor the length of the queue using the Administration Console. If you specify a session rate control, you cannot monitor the session rate using the Administration Console. (The Administration Console only displays the current number of SIP sessions, not the rate of new sessions generated.)

serverStopped

This trap indicates that the WebLogic Server instance is now down. If this trap is received spontaneously and not as a result of a controlled shutdown, follow the steps below.

Recovery Procedure: Follow this recovery procedure:

  1. Use the following command to identify the hung process:

    ps –ef | grep java
    

    There should be only one PID for each WebLogic Server instance running on the machine.

  2. After identifying the affected PID, use the following command to kill the process:

    kill -3 [pid]
    
  3. This command generates the actual thread dump. If the process is not immediately killed, repeat the command several times, spaced 5-10 seconds apart, to help diagnose potential deadlock problems, until the process is killed.

  4. Attempt to restart Converged Application Server immediately.

  5. Make a backup copy of all SIP logs on the affected server to aid in troubleshooting. The location of the logs varies based on the server configuration.

  6. Copy each log to assist Tier 4 support with troubleshooting the problem.

    Note:

    Converged Application Server logs are truncated according to your system configuration. Make backup logs immediately to avoid losing critical troubleshooting information.
  7. Notify Tier 4 support and include the log files with the trouble ticket.

  8. Monitor the server closely over next 24 hours. If the source of the problem cannot be identified in the log files, there may be a hardware or network issue that will reappear over time.

Additional Shutdown Information: The Administration Console generates SNMP messages for managed WebLogic Server instances only until the ServerShutDown message is received. Afterwards, no additional messages are generated.

sipAppDeployed

Converged Application Server engine tier nodes generate this alarm when a SIP Servlet is deployed to the container.

Recovery Procedure: This trap is generated during normal deployment operations and does not indicate an exception.

sipAppUndeployed

Converged Application Server engines generate this alarm when a SIP application shuts down, or if a SIP application is undeployed. This generally occurs when Converged Application Server is shutdown while active requests still exist.

Recovery Procedure: During normal shutdown procedures this alarm should be filtered out and should not reach operations. If the alarm occurs during the course of normal operations, it indicates that someone has shutdown the application or server unexpectedly, or there is a problem with the application. Notify Tier 4 support immediately.

sipAppFailedToDeploy

Converged Application Server engines generate this trap when an application deploys successfully as a Web Application but fails to deploy as a SIP application.

Recovery Procedure: The typical failure is caused by an invalid sip.xml configuration file and should occur only during software installation or upgrade procedures. When it occurs, undeploy the application, validate the sip.xml file, and retry the deployment.

Note:

This alarm should never occur during normal operations. If it does, contact Tier 4 support immediately.