# US 10,372,542 B2 · Fault tolerant event management system

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 10,372,542 B2
- Document ID: US10372542B2
- Status: Granted
- Kind: B2
- Application number: 14/868,184
- Filed: 2015-09-28
- Published: 2017-03-30
- Granted: 2019-08-06
- Earliest claimed: 2015-09-28
- Assignees: CA, Inc.
- Applicants: CA, Inc.
- Inventors: Richard Bennett Whitner
- Web page: https://patentgrep.com/patent/US10372542B2

## CPC

- G06F 11/1658: {Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit}
- G06F 11/2038: {with a single idle spare processing component}
- G06F 11/2097: {maintaining the standby controller/processing unit updated (initialisation or re-synchronisation thereof G06F11/1658 and subgroups)}
- G06F 11/2025: {using centralised failover control functionality}
- G06F 11/3055: {Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available (error or fault processing without redundancy G06F11/0703; error detection or correction by redundancy in data representation G06F11/08; error detection or correction of the data by redundancy in operations G06F11/14; error detection or correction by redundancy in hardware G06F11/16)}
- G06F 2201/86: Event-based monitoring
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)

## Abstract

If an event management system or component within an event management system fails, events generated by systems and applications monitored by the event management system may not be processed or analyzed. As a result, the performance and health of the systems and applications may be unknown. To reduce the impact of a failure, an event management system can include at least two event managers: a primary event manager and one or more standby event managers. The standby event managers are configured to handle event processing tasks upon a failure of the primary event manager. To be prepared for a failure of the primary event manager, the standby event manager receives state data and copies of events. After determining that the primary event manager has failed, the standby event manager can begin processing events.

## Claims

### Claim 1

A method comprising:
receiving a first batch of events into a first buffer of a first event manager and receiving the first batch of events into a second buffer of a second event manager, wherein the first batch of events are received into the first buffer from a communication bus which receives events from a plurality of components of a network;
communicating, by the first event manager to the second event manager, first state data that at least indicates state of processing of the first batch of events by the first event manager;
based on indication of the first state data from the first event manager to the second event manager,
the first event manager discarding the first batch of events from the first buffer;
without processing the first batch of events, the second event manager discarding the first batch of events from the second buffer; and
receiving a second batch of events into the first buffer of the first event manager from the communication bus and receiving the second batch of events into the second buffer of the second event manager;
determining, by the second event manager, that the first event manager is not operational; and
based on determining that the first event manager is not operational,
processing, by the second event manager, the second batch of events from the second buffer based, at least in part, on the first state data; and
updating, by the second event manager, the first state data based, at least in part, on processing the second batch of events.

### Claim 2 (depends on 1)

The method of claim 1, wherein receiving the first batch of events into the first buffer of the first event manager and receiving the first batch of events into the second buffer of the second event manager comprises:
requesting, by the first event manager, the first batch of the events from the communication bus;
communicating, by the first event manager to the second event manager, a notification to request the first batch of events from the communication bus; and
based on receiving the notification, requesting, by the second event manager, the first batch of events from the communication bus.

### Claim 3 (depends on 1)

The method of claim 1, wherein the communication bus sends the first batch of events to the second event manager in response to a request for the first batch of events from the first event manager.

### Claim 4 (depends on 1)

The method of claim 1 further comprising:
determining, by the second event manager, that the first event manager is operational; and
based on determining that the first event manager is operational, sending, by the second event manager, the updated first state data to the first event manager.

### Claim 5 (depends on 4)

The method of claim 4, wherein determining that the first event manager is not operational comprises receiving a notification that the first event manager is not operational, wherein determining that the first event manager is operational comprises receiving a notification that the first event manager is operational.

### Claim 6 (depends on 1)

The method of claim 1 further comprising:
determining, by a monitoring component, that performance of the first event manager meets a criterion; and
based on determining that the performance of the first event manager meets the criterion, indicating that the first event manager is not operational.

### Claim 7 (depends on 6)

The method of claim 6, wherein the second event manager is the monitoring component.

### Claim 8 (depends on 1)

The method of claim 1 further comprising:
receiving, by the second event manager, second state data, wherein the second state data is generated by the first event manager based, at least in part, on the first event manager processing a subset of the second batch of events; and
based on determining that the first event manager is not operational,
identifying, by the second event manager, a set of unprocessed events and a set of processed events based, at least in part, on second state data, wherein the second batch of events comprises the set of unprocessed events and the set of processed events, wherein the set of processed events corresponds to the subset of the second batch of events;
wherein processing the second batch of events from the second buffer comprises processing the set of unprocessed events and not processing the set of processed events.

### Claim 9 (depends on 8)

The method of claim 8, wherein identifying the set of processed events comprises comparing a plurality of event identifiers of the second batch of events to a plurality of event identifiers that comprise the second state data.

### Claim 10 (depends on 1)

The method of claim 1 further comprising performing an initial synchronization of state data between the first event manager and the second event manager.

### Claim 11

One or more non-transitory machine-readable media having program code for a first event manager stored therein, the program code comprising instructions to:
receive a first batch of events into a first buffer of the first event manager from a communication bus which receives events from a plurality of components of a network, wherein the first batch of events is also received in a second buffer of a second event manager;
receive first state data from the second event manager that at least indicates state of processing of the first batch of events from the second buffer of the second event manager;
based on indication of the first state data from the second event manager,
without processing the first batch of events, discard the first batch of events from the first buffer; and
receive a second batch of events in the first buffer from the communication bus, wherein the second batch of event is also received in the second buffer of the second event manager;
determine that the second event manager is not operational; and
based on a determination that the second event manager is not operational,
process the second batch of events from the first buffer based, at least in part, on the first state data; and
update the first state data based, at least in part, on processing the second batch of events.

### Claim 12 (depends on 11)

The machine-readable media of claim 11, wherein the instructions to receive the first batch of events into the first buffer from the communication bus comprise instructions to:
receive a notification from the second event manager to request the first batch of events from the communication bus; and
based on receipt of the notification, request the first batch of events from the communication bus.

### Claim 13

An apparatus comprising:
a processor; and
a machine-readable medium having program code executable by the processor to cause the apparatus to:
receive a first batch of events into a first buffer of the apparatus from a communication bus which receives events from a plurality of components of a network, wherein the first batch of events is also received in a second buffer of an event manager;
receive first state data from the event manager that at least indicates state of processing of the first batch of events from the second buffer of the event manager;
based on indication of the first state data from the event manager,
without processing the first batch of events, discard the first batch of events from the first buffer; and
receive a second batch of events in the first buffer from the communication bus, wherein the second batch of events are also received in the second buffer of the event manager;
determine that the event manager is not operational; and
based on a determination that the event manager is not operational,
process the second batch of events from the first buffer based, at least in part, on the first state data; and
update the first state data based, at least in part, on processing the second batch of events.

### Claim 14 (depends on 13)

The apparatus of claim 13, wherein the program code executable by the processor to cause the apparatus to receive the first batch of events into the first buffer from the communication bus comprises program code executable by the processor to cause the apparatus to:
receive a notification from the event manager to request the first batch of events from the communication bus; and
based on receipt of the notification, request the first batch of events.

### Claim 15 (depends on 13)

The apparatus of claim 13, wherein the communication bus sends the first batch of events in response to a request for the first batch of events from the event manager.

### Claim 16 (depends on 13)

The apparatus of claim 13 further comprising program code executable by the processor to cause the apparatus to:
determine that the event manager is operational; and
based on a determination that the event manager is operational, send the updated first state data to the event manager.

### Claim 17 (depends on 16)

The apparatus of claim 16, wherein the program code executable by the processor to cause the apparatus to determine that the event manager is not operational comprises program code executable by the processor to cause the apparatus to receive a notification that the event manager is not operational, wherein the program code executable by the processor to cause the apparatus to determine that the event manager is operational comprises program code executable by the processor to cause the apparatus to receive a notification that the event manager is operational.

### Claim 18 (depends on 13)

The apparatus of claim 13 further comprising program code executable by the processor to cause the apparatus to:
determine that performance of the event manager meets a criterion; and
based on a determination that the performance of the event manager meets the criterion, indicate that the event manager is not operational.

### Claim 19 (depends on 13)

The apparatus of claim 13 further comprising program code executable by the processor to cause the apparatus to:
receive second state data, wherein the second state data is generated by the event manager based, at least in part, on the event manager processing a subset of the second batch of events; and
based on a determination that the event manager is not operational,
identify a set of unprocessed events and a set of processed events based, at least in part, on second state data, wherein the second batch of events comprises the set of unprocessed events and the set of processed events, wherein the set of processed events corresponds to the subset of the second batch of events;
wherein the program code executable by the processor to cause the apparatus to process the second batch of events from the first buffer comprises program code executable by the processor to cause the apparatus to process the set of unprocessed events and not process the set of processed events.

### Claim 20 (depends on 19)

The apparatus of claim 19, wherein the program code executable by the processor to cause the apparatus to identify the set of processed events comprises comparing a plurality of event identifiers of the second batch of events to a plurality of event identifiers that comprise the second state data.