Software AG Products 10.7 | Using CentraSite | Runtime Governance | Runtime Events and Key Performance Indicator (KPI) Metrics | CentraSite Configuration to Receive Run-Time Events and Metrics
 
CentraSite Configuration to Receive Run-Time Events and Metrics
 
Configuring the Event Receiver
Event Type Modeling
Event Modeling
Prerequisites:
*Ensure that Mediator is configured for publishing events to an SNMP server, as described in the Administering webMethods Mediator guide.
*If you use a target type other than Mediator or webMethods Insight, ensure that you configure CentraSite to publish events by providing the MIB file in your target type's definition file, as described in Gateway Management. (CentraSite provides a MIB file for Mediator and Insight Server.)
*Modify CentraSite's default settings for logging run-time events. 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 through the SNMP (Application-Layer) protocol, and contains the logic to parse and store event data in the Event Receiver's data store.
Components of the Event Receiver
The Event Receiver contains the following components:
*The SNMP Listener
CentraSite's SNMPv3 Trap Listener that supports SNMP4J. This Listener starts automatically when CentraSite starts.
*The Intermediate Queue
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 modes supported are:
*FileSystem: Incoming Traps are stored temporarily in the file system.
*InMemory: Incoming Traps are stored temporarily in memory.
*NoQueue: Incoming Traps are not be stored in any intermediate queue. The SNMP Listener threads are processed.
*The Event Processor
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:
1. 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.
2. Parses the Trap attributes and obtains the Service (UUID), the Target (Name), the TimeStamp, and the SessionId. The processor then searches the registry or repository and obtains the corresponding UUID for the Target Name. This mapping is also cached to improve performance.
3. Collects the remaining attributes from the Trap.
4. 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
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.
*The RuntimeEvents Collection
The run-time events are stored in the RuntimeEvents Collection as non-registry objects.