11 Managing and Configuring EDRs, CDRs and Alarms

This chapter describes how to manage and configure Oracle Communications Services Gatekeeper Event Data Records (EDRs), Charging Data Records (CDRs), and alarms.

About EDRs, CDRs, and Alarms

You use Event Data Records (EDRs) and Charging Data Records (CDRs) to capture specific events that occur while traffic is running between applications, Services Gatekeeper, and the resource or network node the application is using. You can use EDRs and CDRs to charge your users for specific events that they consume. The consumption can be volume-based, time-based, event-based, or any other combination of EDR fields that you choose.

EDRs are the base component of both CDRs and alarms.EDRs are generated:

Automatically, using aspects at various locations in a network protocol plug-in.
Manually, anywhere in the code using EDRServiceMBean directly.

Alarms warn you of traffic processing problems.

See Alarms Handling Guide for details on the individual alarms organized by tagalarm number.

Understanding EDRs

All EDRs are passed through the EDRServiceMBean. All EDRs are dispatched to a JMS- distributed topic so external clients can receive them over JMS. EDRs are not persisted in the database.

See "EDRServiceMBean Reference" for information on using the EdrServiceMBean.

Understanding Alarms

Alarms are EDRs that are mapped to alarms using the alarm.xml configuration file: see "EDR Categories and XML Markup".

You can configure Alarms to persist. See "StoreAlarms" in EdrServiceMBean in OAM Java API Reference for details.

The Alarms Handling Guide for lists all alarms by tagalarm number, and contains information on how to solve invidivual problems.

Understanding CDRs

CDRs are EDRs that are mapped to CDRs using the wlng-edr.xml configuration file. See "EDR Categories and XML Markup" for details.

You can configure CDRs to persist. See "StoreCDRs" in EdrServiceMBean in OAM Java API Reference for details.

See "EDRServiceMBean Reference" for information on using the EdrServiceMBean.

Understanding External EDR listeners

External EDR listeners are JMS topic subscribers. See the discussion on ”Creating EDR Listeners” and Services Gatekeeper Extension Developer's Guide and "Generating SNMP MIB Files" for more information.

EDR Categories and XML Markup

In order to categorize the objects in the EDR flow as either pure EDRs, alarms or CDRs, the EDR service uses an EDR configuration file:

domain_home/config/custom/wlng-edr.xml

In the configuration file:

The <edr-config> element contains descriptors that describe pure EDRs.
The <alarm-config> element contains descriptors that describe EDRs that are considered to be alarms.
The <cdr-config> element contains descriptors that describe EDRs that are considered to be CDRs.

The default Services Gatekeeper installation comes with a set of predefined descriptors. Change and adapt the descriptors as part of an integration project.

You can edit and reload the XML configuration file using the EDR Configuration pane. See "Managing EDR/CDR/Alarm Configuration Files" for details.

Example 11-1 illustrates the structure of wlng-edr.xml. See the discussion on ”Creating EDR Listeners” and Services Gatekeeper Extension Developer's Guide and "Generating SNMP MIB Files" for more information.

Example 11-1 structure of wlng-edr.xml

<edr-config xsi:schemaLocation="http://www.bea.com/ns/wlng/30 edr-config.xsd">
<edr id="ID" description="description">
<filter>
<method>
<name>message response message</name>
<class>fully qualified class name</class>
</method>
</filter>
</edr>
.....
</edr-config>

Understanding the EDR format

The following values are always available in an EDR when it is generated in the standard way:

Class name
Method name
Direction (application-facing, network-facing), if the request is travelling from Services Gatekeeper to the network or from the network to Services Gatekeeper
Position (before, after), if the EDR was emitted before or after the method was invoked or the exception was thrown
Interface (application-facing or network-facing), if the EDR was emitted from the application-facing interface or from the network-facing interface of the plug-in
Source (method, exception), if the EDR is related to a method invocation or to an exception

In addition to these values, the EDR may also contain values relevant to the context of the request.

Figure 11-1 Application Tier and Network Tier EDR Generation

Description of ''Figure 11-1 Application Tier and Network Tier EDR Generation''

Table 11-1 describes the contents of an EDR. Individual value fields in an EDR are retrieved by name using a key in a name/value pair.

Table 11-1 Contents of an EDR

String value of name (key) in name/ value pair	Description
EdrId	Defined in wlng-edr.xml
ServiceName	The name or type of the service
ServerName	Name of server where the EDR was generated
Timestamp	The time at which the EDR was triggered Milliseconds since midnight, January 1, 1970 UTC
ContainerTransactionId	WebLogic Server transaction ID (if available)
Class	Name of the class that logged the EDR
Method	Name of the method that logged the EDR
Direction	Direction of the request
Source	The type of source that logged the EDR
Position	Position of the EDR relative to the method that logged the EDR
State	Where the EDR was dispatched
Interface	Interface where the EDR is logged
Exception	Name of the exception that triggered the EDR
SessionId	Session ID
ServiceProviderId	Service provider account ID
ApplicationId	Application account ID
AppInstanceId	Application account identifier
TransactionId	Transaction Id. Correlates completed traffic among all three EDR states
Facade	Facade (REST or SOAP)
OrigAddress	The originating address with scheme included. For example: tel:1212771234
DestAddress	The destination address, or addresses, with scheme included
<custom>	Any additional context-specific information
PluginID	The unique ID of the plug-in instance
URL	The URL of the current web service
WebAppName	Name of the current web application
HttpMethod	HTTP method, such as "POST", or "GET"
SubscriberID	Subscriber (user) identifier (using route address)

Using EDRtoAnalytics

EdrToAnalytics provides you with a statistical picture of the number of EDRs between the EDR processor and the data store writer.

You have these options for using these statistics:

Connect the WebLogic JMS Monitor to a Services Gatekeeper NT server and view these statistics. You can inspect the total messages published by EdrService. The number of current message indicates how many message are buffered by JMS service before they are delivered to users. If this number gets very large or continuously increases then you know you have a problem.
View the EdrService statistics from the Services Gatekeeper Administration Console. This metric shows you the total number of EDRs published by EdrService and a snapshot of the number of EDRs being queued between the EDR publisher and the JMS server.
View the EdrToAnalytics statistics in the Services Gatekeeper Administration console. This metric shows you the total accumulation of EDR received by each EdrListener, and the snapshot of the usage of queue between EdrProcessor and data store writer.

Reference: Attributes and Operations for EdrToAnalytics

Managed object: EdrToAnalytics

MBean: oracle.ocsg.edr.analytic.management.EdrAnalyticMBean

Operation: listEdrListnerStatistics

Scope: Cluster

Retrieves the number of EDR messages received and written to the database by the EdrToAnalytics MBean.

Signature:

listEdrListenerStatistics()

Using EDRService

The following sections explain how to use EDRService.

Configuring EDRService

To configure the behavior of the EDRService, in the EdrServiceMBean:

Specify PublishToJMS"
Specify StoreAlarms.
Specify StoreCDRs.

See "EDRServiceMBean Reference" for information on using the EdrServiceMBean.

Managing EDRService

The following section describes how to manage the EDRService.

Defining batch attributes

To configure the maximum number of EDRs sent in a batch to a JMS EDR listener and the maximum time to wait before the EDRs in the buffer are sent to listeners:

Specify BatchTimeout.
Specify BatchSize.

See "EDRServiceMBean Reference" for information on using the EdrServiceMBean.

EDRServiceMBean Reference

Set field values and use methods from the Administration Console by selecting Container, then Services followed by EdrService. Alternately, use a Java application. For information on the methods and fields of the supported MBeans, see the ”All Classes” section of Services Gatekeeper OAM Java API Reference.

Managing EDR/CDR/Alarm Configuration Files

Administrators use the Services Gatekeeper EDR Configuration pane of the Services Gatekeeper Administration Console to load new EDR, CDR, and alarm configuration files.

Open the pane the Domain Structure in the Administration Console. Select OCSG, then Server Name, and then EDR Configuration.

Note:

You must click Lock and Edit first.

Table 11-2 describes the inputs for the entry fields in the configuration pane.

Table 11-2 Services Gatekeeper EDR Configuration pane

Entry field	Input
EDR descriptor	The EDR configuration file. See "EDR Categories and XML Markup".
CDR descriptor	The CDR configuration file. See "EDR Categories and XML Markup".
Alarm descriptor	The alarms configuration file. See "EDR Categories and XML Markup".