CentraSite can receive run-time events and Key Performance Indicator (KPI) metrics. A run-time event is an event that occurs while services are actively deployed on the target. Examples of run-time events include:
Successful or unsuccessful SOAP requests/responses.
Policy violation events, which are generated upon violation of service’s run-time policy.
Service monitoring events, which are generated by the service-monitoring actions in the run-time policy.
KPI metrics are used to monitor the run-time execution of virtual services. Metrics include the maximum response time, average response time, fault count, availability of virtual services, and more. If you include run-time monitoring actions in your run-time policies, the actions will monitor the KPI metrics for virtual services, and can send alerts to various destinations when user-specified performance conditions for a service are violated.
CentraSite provides predefined event types for use with any supported policy-enforcement point (PEP), such as webMethods Mediator. In addition, you can create custom event types.
The run-time event data are collected by the PEP and published to CentraSite via SNMP. The PEP publishes data for all run-time events for all instances of the PEP target.
You can view the run-time events and metrics on the CentraSite Control user interface. You can view them for all targets, for a particular target, or for a particular virtual service.
The following topics are discussed:
The types of run-time events that Mediator can publish are as follows:
Event Type | Description |
---|---|
Lifecycle | A Lifecycle event occurs each time Mediator is started or shut down. |
Error | An Error event occurs each time an invocation of a virtual service results in an error. |
Policy Violation | A Policy Violation event occurs each time an invocation of a virtual service violates a run-time policy that was set for the virtual service. |
Transaction | A Transaction event occurs each time a virtual service is invoked (successfully or unsuccessfully). |
Monitoring | Mediator publishes key performance indicator (KPI) metrics, such as the average response time, fault count, and availability of all virtual services (described below). |
For the Monitoring event type, Mediator can publish the following types of KPI metrics:
Metric | Reports on... |
---|---|
Availability | The percentage of time that a virtual service was available during the current interval. A value of 100 indicates that the service was always available. Only the time when the service is unavailable counts against this metric. If invocations fail due to policy violations, this parameter could still be as high as 100. |
Average Response Time | The average amount of time it took the service to complete all invocations in the current interval. This is measured from the moment Mediator receives the request until the moment it returns the response to the caller. |
Fault Count | The number of failed invocations in the current interval. |
Maximum Response Time | The maximum amount of time it took the service to complete an invocation in the current interval. |
Minimum Response Time | The minimum amount of time it took the service to complete an invocation in the current interval. |
Successful Request Count | The number of successful service invocations in the current interval. |
Total Request Count | The total number of requests for each service running in Mediator in the current interval. |
Note:
By default, Average Response Time, Minimum Response Time and Maximum
Response Time do not include metrics for failed invocations. You can include
metrics for failed invocations by setting the
pg.PgMetricsFormatter.includeFaults parameter to true. For more information,
see the section Advanced Settings in the document
Administering webMethods Mediator.
Mediator can publish all run-time events to an SNMP server. Mediator sends events as SNMP traps either to CentraSite's SNMP server or to a third-party SNMP server.
CentraSite's SNMP server uses SNMPv3 user-security model.
Mediator delivers the webMethodsESB.MIB file to define the SNMP traps that it can produce. For the procedure to configure Mediator to send SNMP traps to the CentraSite SNMP server, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator. For more information about the webMethodsESB.MIB file, see the section Run-Time Targets.
A third-party SNMP server can use either the SNMPv1 community-based security model or the SNMPv3 user-based security model.
To use a third party SNMP server, you must import or set up the MIB on all SNMP servers receiving SNMP traps from Mediator. For the procedure to configure Mediator to send SNMP traps to a third-party SNMP server, see the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
In addition to publishing all run-time events to an SNMP server, you can configure Mediator to:
Send monitoring alerts to various destinations when user-specified performance conditions are violated.
Log the payloads of all transactions to various destinations.
To do this, you include the following run-time actions in the policies of your virtual services. When you configure the run-time actions, you will specify the destinations for sending the alerts or logging the transactions.
To Send Monitoring Alerts... | Destination for Sending Alerts |
---|---|
Use any of the following monitoring actions:
|
|
To Log the Transaction Payloads | Destinations for Logging the Transactions |
---|---|
Use the "Log Invocations" action. |
|
The destinations for sending alerts and logging transactions are described below.
To specify an email destination, you must:
Select the "Email" option as a destination when you configure the run-time actions listed above.
Set the "Email Configuration" parameters in Integration Server Administrator (go to
) as described in the section SMTP Destinations for Alerts and Transaction Logging in the document Administering webMethods Mediator.To specify the Integration Server's local log as a destination, you must:
Select the "Local Log" option as a destination when you configure the run-time actions listed above. When configuring the actions, you must also specify the severity of the messages to be logged (the logging level).
Set the Integration Server Administrator's logging level for Mediator to match the logging levels specified for the run-time actions (go to
). For example, if a "Log Invocation" action is set to the logging level of Error, you must also set Integration Server Administrator's logging level for Mediator to Error. If the action's logging level is set to a low level (Warning-level or Informationlevel), but Integration Server Administrator's logging level for Mediator is set to a higher level (Error-level), then only the higher-level messages are written to the log file.Entries posted to the local log are identified by a product code of MED.
You can select the Integration Server Audit Log as a destination for the "Log Invocation" action only. If you expect a high volume of invocations in your system, it is recommended that you select the Audit Log destination. For more information, see the webMethods Audit Logging Guide.
Mediator tracks performance metrics by intervals. The interval is a period of time you set in Mediator, during which metrics are collected for reporting to CentraSite. You set the interval in the Publish Interval field on the
page in the Integration Server Administrator. For details, see the section Configuring Communication with CentraSite in the document Administering webMethods Mediator.Mediator only tracks metrics for the current interval. At the end of the interval, Mediator aggregates the metrics and reports them to CentraSite. Once the metrics are reported, Mediator resets its counters for the new interval. Mediator does not calculate and aggregate metrics across intervals. If Mediator is shut down or the virtual service is undeployed before the current interval expires, the performance data is discarded.
Note:
To avoid the need for Mediator to store metrics during periods of
inactivity, Mediator stores only first and last zero value metrics that occurs
during an interval, and discards the remaining consecutive zero value metrics.
Doing this drastically reduces the storage space consumed by the metrics, and
speeds the queries you perform in the dashboard. Skipping the in-between zero
metrics will not affect in the performance graphs shown in the
dashboard.
For more information about the metrics tracking interval, see the section Key Performance Indicator Metrics and Run-Time Event Notifications in the document Administering webMethods Mediator.
Prerequisites:
Ensure that Mediator is configured for publishing events to an SNMP server, as described in the section SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
If you use a target type other than Mediator or webMethods Insight, be sure to configure CentraSite to publish events by providing your own MIB file in your target type's definition file, as described in the section Run-Time Targets. (CentraSite provides a MIB file for Mediator and Insight.)
Optionally change CentraSite's default settings for logging run-time events, as described in the section Logging. By default, CentraSite logs all predefined event types, but you may disable any type.
CentraSite provides an Event Receiver, which is a data collector that collects the run-time event data. The Event Receiver listens for run-time events from the target instances via the SNMP (Application-Layer) protocol, and contains the logic to parse and store event data in the Event Receiver's data store. You must configure the Event Receiver's properties file as described below.
This section includes the following topics:
The Event Receiver contains the following components.
CentraSite's SNMPv3 Trap Listener, which supports SNMP4J. This Listener starts automatically when CentraSite starts.
The queue from the SNMP Listener to the Event Processor. This queue decouples the SNMP Listener threads from the Event Processor to improve throughput. The following modes are supported.
FileSystem: Incoming Traps will be stored temporarily in the file system
InMemory: Incoming Traps will be stored temporarily in memory
NoQueue: Incoming Traps will not be stored in any intermediate queue; the SNMP Listener threads will be processed.
To select the mode, set the
eventsQueueImpl
property as described in
Setting the Events Queue
Implementation Property.
The Event Processor (SOALinkSNMPEventsListener) transforms incoming SNMPv3 Traps into an XML file (Events.xml) that complies with the schema in the RuntimeEvents Collection component. The Event Processor transforms an SNMPv3 Trap to the Events.xml file as follows:
Determines the Event Type (and Target Type) to which the Trap belongs, and gets the corresponding UUIDs. This involves searching all Event Type-to-Trap mappings in all the defined target types, using the Trap’s OID. Since this is an expensive search, the Event Type-to-Trap mapping is cached to improve performance.
Parses the Trap attributes and obtains: the Service (UUID); the Target (Name); the TimeStamp and the SessionId. The Processor then searches the registry/repository and obtains the corresponding UUID for the Target Name. This mapping is also cached to improve performance.
Collects the remaining attributes from the Trap.
Constructs the Events.xml file using the Event Type UUID, Target Type UUID, Service UUID, Target UUID, TimeStamp, SessionId and other collected attributes.
The Batch Condition is a set of OR conditions used by the Event Processor. The Event Processor supports two modes of event storage into CentraSite: BatchMode and NoBatchMode. BatchMode is available only for FileSystem and InMemory queues. When BatchMode is enabled, the Event Processor continues to accumulate Events.xml documents until one of the conditions is evaluated as true. Then it inserts all the documents as a single batch into CentraSite.
To specify BatchMode or NoBatchMode, set the batch-related properties as described in Setting the Properties for FileSystem or InMemory.
The run-time events are stored in the RuntimeEvents Collection as non-registry objects. For information about how events are stored, see Event Type Modeling.
The Event Receiver is bundled in the installation as a Web-Application named SOALinkSNMPEventsListener supporting the JavaEE standard. The configuration file for the Event Receiver is located here:
<CentraSite_directory>/cast/cswebapps/SOALinkSNMPEventsListener/WEB-INF/web.xml
The web.xml configuration file contains all the Event Receiver configuration properties. You must set these properties as described below, and then restart CentraSite.
In the Event Receiver's configuration file, set the following properties related to the RuntimeEvents Collection database .
Database Property | Description |
---|---|
com.softwareag.centrasite.soalink.events.dbUrl | The URL of the RuntimeEvents Collection database. All run-time events will be persisted to this database. |
com.softwareag.centrasite.soalink.events.dbUserId | The user name that the Events Listener will use
for authentication before persisting event data to the RuntimeEvents Collection
database. The default value of this property is the predefined user EventsUser.
Optionally, you can change the value EventsUser to any login user who has the following privileges:
If you want to change the value to a login user, enter that login
user's name in the form
Important: |
com.softwareag.centrasite.soalink.events.dbNonActivityTimeOut | The non-activity timeout in seconds for the RuntimeEvents Collection database (default 2592000 seconds (i.e., 30 days)). |
In the Event Receiver's configuration file, set the following properties related to a SNMPv3 Transport.
SNMPv3 Transport Property | Description |
---|---|
com.softwareag.centrasite.soalink.events.snmp.transport | Wire transport protocol that will be used by the SNMP Listener. Supported values are: TCP and UDP. |
com.softwareag.centrasite.soalink.events.snmp.host | The CentraSite host name or IP address to which the SNMP listener will bind. |
com.softwareag.centrasite.soalink.events.snmp.port | The port to which the SNMP listener will bind. The default is
8181.
If Microsoft Internet Information Services (IIS) is installed (or will be installed) on the same machine hosting IS/Mediator, then you may want to change the default SNMP port of 8181 to something else, to avoid any potential runtime conflicts when sending SNMP packets. |
com.softwareag.centrasite.soalink.events.snmp.maxInboundMessageSizeInBytes | Maximum inbound message size in bytes (an integer). Traps that exceed this size limit will be rejected. Default value is 256Kb. |
com.softwareag.centrasite.soalink.events.snmp.dispatcherPoolSize | The SNMP Listener's Worker-Thread pool size (default is 10). This determines the throughput of the Listener. |
In the Event Receiver's configuration file, set the following properties related to SNMPv3 USM.
SNMPv3 USM Property | Description |
---|---|
com.softwareag.centrasite.soalink.events.snmp.engineId | EngineId to be used by the SNMP Listener. If the parameter is left blank, the SNMP Listener will auto-generate the engineId. |
com.softwareag.centrasite.soalink.events.snmp.securityName | The SecurityName to be used by the SNMP Listener. |
com.softwareag.centrasite.soalink.events.snmp.securityLevel | The Maximum SecurityLevel to be supported by SNMP Listener. Supported values in order are: NOAUTH_NOPRIV, AUTH_NOPRIV and AUTH_PRIV. For example, AUTH_PRIV provides the highest level of security but also supports the other two levels. Similarly AUTH_NOPRIV supports NOAUTH_NOPRIV. |
com.softwareag.centrasite.soalink.events.snmp.authProtocol | AuthorizationProtocol to be used by the SNMP Listener for decoding the incoming trap. Supported values are: MD5 and SHA. |
com.softwareag.centrasite.soalink.events.snmp.authPassPhraseKey | The PassPhrase key to be used by the AuthorizationProtocol. The passphrase key length should be >= 8. The key is stored in this file; the passphrase value is stored securely in passman. |
com.softwareag.centrasite.soalink.events.snmp.privProtocol | The PrivacyProtocol to be used by the SNMP Listener for decoding the incoming trap. Supported values are: DES, AES128, AES, AES192, AES256, 3DES and DESEDE. |
com.softwareag.centrasite.soalink.events.snmp.privPassPhraseKey | The PassPhrase key to be used by the PrivacyProtocol. The passphrase length should be >= 8. The key is stored in this file; the passphrase value is stored securely in passman. |
In the Event Receiver's configuration file, set the following property related to the implementation of the events queue.
Events Queue Property | Description |
---|---|
com.softwareag.centrasite.soalink.events.eventsQueueImpl | Supported values are:
Additional, related properties are described in Setting the Properties for FileSystem or InMemory. |
When the eventsQueueImpl property is set to either FileSystem or InMemory, you should also set the following properties.
Property for FileSystem or InMemory | Description |
---|---|
com.softwareag.centrasite.soalink.events.enableBatchInsertion | Enable or disable batch insertion of events into the database. Supported values are true and false. If true, events will be batched as per the "batching rules" properties below, and the batch will be stored to the database. If false, events will be stored to the database one by one. |
com.softwareag.centrasite.soalink.events.maxNumOfEventsPerBatch | Maximum number of events in a batch. Should be an integer value. A value <= 0 disables this rule. This rule is evaluated only on arrival of a new Trap. |
com.softwareag.centrasite.soalink.events.maxSizeOfBatch | Maximum size (in bytes) of a batch. Default value is 512KB. Should be an integer value. A value <= 0 disables this rule. This rule is evaluated only on arrival of a new Trap. |
com.softwareag.centrasite.soalink.events.maxTimeIntervalBetweenBatches | Maximum time interval (in milliseconds) between two subsequent batch storages. Should be an integer value. A value <= 0 disables this rule. Unlike the other two rules, this rule is evaluated periodically. Hence this rule prevents any trap stuck in the batch for ever if inflow of traps stops; in short this acts as a batch-timeout. A very low value for this rule reduces batch efficiency and introduces unnecessary looping. |
com.softwareag.centrasite.soalink.events.fileSystemQueueDir | (Only applies when the eventsQueueImpl
property is set to FileSystem.) The directory that should be used as FileSystem
Queue. Incoming traps will be stored in this directory temporarily and hence
should have write permission. The path can be absolute or relative. It is
advisable to provide the absolute path. Relative paths will be considered
relative to one of the following, based on availability in the same order:
|
Event types are modeled as registry objects. The String, Date, Integer and Boolean event attributes are stored in the registry/repository as slots. The File-Type attributes (representing payloads/binary-data) are stored as HasExternalLink associations.
For example, consider the predefined event type Transaction. If you go to the Target Type details page, you will see the Transaction event type attributes (which are obtained from the webMethodsESB.mib file) as follows:
Attribute Name | Object ID | Type |
---|---|---|
Service | 1.3.6.1.4.1.1783.201.1.1.1 | String |
Target | 1.3.6.1.4.1.1783.201.1.1.2 | String |
Timestamp | 1.3.6.1.4.1.1783.201.1.1.3 | Date |
Consumer | 1.3.6.1.4.1.1783.201.1.1.4 | String |
RequestStatus | 1.3.6.1.4.1.1783.201.1.1.5 | String |
ResponsePayload | 1.3.6.1.4.1.1783.201.1.1.6 | File |
RequestPayload | 1.3.6.1.4.1.1783.201.1.1.7 | File |
ProviderRoundTripTime | 1.3.6.1.4.1.1783.201.1.1.8 | Integer |
TotalRoundTripTime | 1.3.6.1.4.1.1783.201.1.1.9 | Integer |
SessionID | 1.3.6.1.4.1.1783.201.1.1.16 | String |
ConsumerIP | 1.3.6.1.4.1.1783.201.1.1.17 | String |
All of these attributes (except the File-Type attributes RequestPayload and ResponsePayload) are stored as registry object slots, as follows:
Slot Key | Slot Type | Slot Value (Attribute) |
---|---|---|
uddi_16d34470-9a92-11dd-9b43-e319c2a6593c | xs:string | Service |
uddi_f18b5a40-9a91-11dd-b95e-b4758b17b88b | xs:string | Target |
uddi_c798d3c0-9a91-11dd-889e-b999c87ba6b7 | xs:datetime | TimeStamp |
uddi_a7476ff0-a108-11dd-9c38-d8fd010529cc | xs:string | Consumer |
uddi_a7476ff0-a108-11dd-9c38-eac6d60fc855 | xs:string | RequestStatus |
uddi_a7476ff0-a108-11dd-9c38-f3f84c6111f0 | xs:integer | ProviderRoundTripTime |
uddi_a7476ff0-a108-11dd-9c38-d02170b3aae3 | xs:integer | TotalRoundTripTime |
uddi_21b67010-9a92-11dd-926a-991c4c180c79 | xs:string | SessionID |
uddi_a7476ff0-a108-11dd-9c38-d34f346cb3d5 | xs:string | ConsumerIP |
The File-Type attributes ResponsePayload and RequestPayload are stored as HasExternalLink associations, as follows:
Association Key | Association Name (Attribute) |
---|---|
uddi:a747704b-a108-11dd-9c38-fde9d932116a | ResponsePayload |
uddi:a745265b-a108-11dd-9c38-bf43eee17363 | RequestPayload |
A target type (represented as a concept) is associated with an event type (represented as a registry object) by a "Target Type to Event Type Association" object, which defines the "UUID to MIB OID" mapping.
The following table shows the contents of a sample object that associates the target type webMethods Mediator with the event type Transaction. The table's columns are described below.
Attribute: The Attribute column is not part of the object; it is included here simply for your reference.
Slot Key: Contains the UUID, which is obtained from the event type registry object.
Slot Type: Contains the slot type, which is obtained from the event type registry object.
Slot Value: Contains the event type attribute's Object Identifier (OID), which is obtained from the MIB file.
Attribute | Slot Key (Event Type UUID) | Slot Type | Slot Value (Event Attribute OID) |
---|---|---|---|
Service | uddi_16d34470-9a92-11dd-9b43-e319c2a6593c | xs:string | 1.3.6.1.4.1.1783.201.1.1.1 |
Target | uddi_f18b5a40-9a91-11dd-b95e-b4758b17b88b | xs:string | 1.3.6.1.4.1.1783.201.1.1.2 |
TimeStamp | uddi_c798d3c0-9a91-11dd-889e-b999c87ba6b7 | xs:datetime | 1.3.6.1.4.1.1783.201.1.1.3 |
Consumer | uddi_a7476ff0-a108-11dd-9c38-d8fd010529cc | xs:string | 1.3.6.1.4.1.1783.201.1.1.4 |
RequestStatus | uddi_a7476ff0-a108-11dd-9c38-eac6d60fc855 | xs:string | 1.3.6.1.4.1.1783.201.1.1.5 |
ResponsePayload | uddi_a747704b-a108-11dd-9c38-fde9d932116a | xs:anyURI | 1.3.6.1.4.1.1783.201.1.1.6 |
RequestPayload | uddi_a745265b-a108-11dd-9c38-bf43eee17363 | xs:anyURI | 1.3.6.1.4.1.1783.201.1.1.7 |
ProviderRoundTripTime | uddi_a7476ff0-a108-11dd-9c38-f3f84c6111f0 | xs:integer | 1.3.6.1.4.1.1783.201.1.1.8 |
TotalRoundTripTime | uddi_a7476ff0-a108-11dd-9c38-d02170b3aae3 | xs:integer | 1.3.6.1.4.1.1783.201.1.1.9 |
SessionID | uddi_21b67010-9a92-11dd-926a-991c4c180c79 | xs:string | 1.3.6.1.4.1.1783.201.1.1.16 |
ConsumerIP | uddi_a7476ff0-a108-11dd-9c38-d34f346cb3d5 | xs:string | 1.3.6.1.4.1.1783.201.1.1.17 |
An event is an instance of an event type. Events are modeled in a separate schema from the event type schema. CentraSite models events as non-registry objects (to avoid storing large amounts of unwanted event data in the registry/repository), and instead stores event data in a database collection within the Event Receiver. CentraSite maps events to their corresponding event types, using the event types' UUIDs. Similarly, events are mapped to target types, targets and services using UUIDs and the event type attributes.
The stored event data will contain:
The event Trap ID (MIB OID).
The event Trap value, which consists of:
The attribute key (MIB OID).
The attribute value.
The event data is stored in the Event Receiver as an "events" doctype.
If an event contains payloads (e.g., File-Type attributes such as ResponsePayload and RequestPayload), the payloads are stored in the Event Receiver as a "payloads" doctype, and will be referenced by the event stored under the "event" doctype, using ino:id. This is used to reduce de-serialization of the usually large payloads, and to improve performance of queries on the stored events.
You can view the run-time events and metrics that occurred for:
A particular target or all targets (see Viewing Run-Time Events and Metrics for Targets).
Each virtual service (see Viewing Run-Time Events and Metrics for Virtual Services).
Use the following procedure to view lists of run-time events for a particular target or for all targets.
If you are using the Mediator target, ensure that Mediator is configured to send event notifications to the destination(s) that are applicable for each event type. For details, see SNMP Destinations for Run-Time Events in the document Administering webMethods Mediator.
Note:
You must have the permissions to manage targets, as described in the
section Run-Time Targets.
To view a list of run-time events for targets
In CentraSite Control, go to Operations > Events > Event List.
Use the following fields to filter the event list you want to view:
In this field... | Specify... |
---|---|
Target Type | The type of the target whose events you want to view. |
Target | The target whose events you want to view (or select All to view events of all targets). |
Event Type | A particular event type, or select All to view all event types. For descriptions of the predefined event types, see the The Run-Time Event Types. |
Service Type | Select All or Virtual
Service.
Note: |
Date Range | A range of dates from which to view the events. |
Start Date | Alternatively, select the check box next to this field and click the calendar and select a starting date and time. |
End Date | Click the calendar and select an ending date and time. |
Click the
button.The generated event list displays the following information:
Field | Description |
---|---|
Date/Time | The date/time that the event occurred. Click this hyperlinked value to view the Event Detail page, which will contain the event's SOAP request or response name in the Attribute column. Click the hyperlinked request or response name to display the full SOAP request or response. |
Session ID | (Read-only.) The session ID that generated the event. |
Event Type | (Read-only.) The type of event (e.g., Monitoring, Policy Violation, Error, etc.). |
Service Name | (Read-only.) The name of the service that caused the event. |
Service Type | (Read-only.) The service’s type. |
Target | (Read only.) The target on which the event occurred. |
Target Type | (Read only.) The type of the target on which the event occurred. |
Note:
To view the list of attributes that are mapped for each event
type, go to the target type's detail page (see the section Run-Time
Targets).
You can view the events and metrics for a virtual service in its Events profile and its Performance profile. For details, see the section Virtual Services in CentraSite Control.
CentraSite provides the predefined event types described in The Run-Time Event Types. In addition, you can create custom run-time events that CentraSite will monitor.
Note:
Prerequisite: You must have the Manage Runtime Event Types
permission. By default, the predefined roles CentraSite Administrator and
Operations Administrator include this permission. For more information about
roles and permissions, see the section Users, Groups, Roles, and
Permissions.
Important:
To enable CentraSite to recognize custom event types, ensure
that your MIB file (which is contained in your target type definition file)
contains the SNMP Traps metadata and Object Identifiers for the custom events.
For more information, see the section Run-Time
Targets.
To create custom event types
In CentraSite Control, go to Operations > Events > Event Types to display the Event Types page.
The page displays all the predefined event types (Monitoring, Policy Violation, Transaction, Error and Lifecycle) and any custom event types that have been defined.
To view the details of any event type, click its hyperlinked name.
The list of attributes for the event type is displayed. You can edit the attributes of custom event types, but not the predefined event types (see Modifying Custom Run-Time Events).
To create a custom event type, click the Add Event Type button. In the Add/Edit Event Type page specify a name and description for the event type. Event type names can contain any character (including spaces), and are not case-sensitive.
In the Event Type Attribute panel, the following default attributes are displayed. These attributes are required and cannot be deleted.
Attribute | Data Type |
---|---|
TimeStamp | Date |
Target | String |
Service | String |
SessionID | String |
To create additional attributes, perform the following steps:
Click the plus button at the bottom of the attribute list.
Specify a name in the Name column and a value in the Data Type column (Boolean, File, Date, Integer or String). Attribute names can contain any character (including spaces).
To add another attribute, click the plus button at the bottom of the list.
To delete an attribute, click the minus button for the attribute you want to delete.
Click
.To edit and delete custom event types, perform the following steps.
To modify a custom run-time event
In CentraSite Control, go to Operations > Events > Event Types to display the Event Types page.
The page displays all event types that have been defined.
To delete a custom event type, select the check box next to the event type and click the Delete button.
To edit the attributes of a custom event type, perform the following steps:
Click its hyperlinked name to display the Add/Edit Event Type page.
You can change the value of an attribute’s data type, but not its name. Data types can be Boolean, File, Date, Integer or String.
To add another attribute, use the plus button at the bottom of the list.
To delete an attribute, click the minus button next to the attribute.
Click
.