Event processing
While events from dynamically discovered servers and manually defined servers are collected in different ways, event processors (EPs) process events all in the same way.
Collecting events from dynamically discovered servers
Dynamically discovered servers, such as IBM® Global High Availability Mailbox, post events to a RESTful API known as the event repository (ER) that is hosted by the application servers. Because these servers post events to IBM Control Center, these types of servers do not need to be explicitly registered or added by an administrator. IBM Control Center is able to dynamically discover these types of servers.
Dynamically discovered servers do not need to be manually added through the IBM Control Center console. To monitor a dynamically discovered server, you need to configure the server to publish events to the URL of event repository, in the standard event format.
IBM Control Center dynamically discovers new servers that post events and automatically assigns the servers to the least busy EP.
Collecting events from manually defined servers
You need to configure manually defined servers in IBM Control Center, such as IBM Sterling Connect:Direct® and IBM Sterling B2B Integrator, before the servers can communicate with IBM Control Center.
Events from manually defined servers are not posted to the ER. Instead, events are collected by the assigned EPs through polling, listening on a queue, or receiving Simple Network Management Protocol (SNMP) traps.
Processing events
EPs communicate with manually defined servers and process events from these servers right after the events are received. Node services in IBM Control Center are responsible for the communications that transpire between monitored servers and IBM Control Center.
Similar to dynamically discovered servers, events from manually defined servers are written to the EVENTS table in the database after they are processed.
IBM Control Center EP processes events from both dynamically discovered servers and manually defined servers and evaluates events through DVG membership, rules, and SLCs. Events are passed through the following series of services:
- Visibility service - The visibility service applies data visibility group (DVG) criteria to all events before the events are passed on to the metadata service.
- Metadata service - The metadata service applies enabled and active metadata rules to all events.
- Rule service - The rule service applies enabled, active, linked, and non-linked rules to all
events after they are processed by the metadata rule service. Events that are handled by the rule
service trigger rules and their associated actions to be taken. The following actions can be taken:
- Generating an email
- Sending an SNMP trap
- Raise an alert
- Sending a self-defined server command to the server the event resulted from
- Running a self-defined operating system command or script by the EPs to the operating system
- SLC service - The SLC service generates events when things do or do not happen within a certain time frame or occur for a specified duration according to performance objectives that you define. Those events are run through the rules service to take actions.