X in Y solution components

Four fields

XinY VARCHAR(4096)

This field is the string field that stores the successive time stamps. The way this field is used in conjunction with the NVP functions effectively behaves as an array. The time stamps are stored within the field by the NVP functions in the following format:

t1="1332419954";t2="1332419954";t3="1332419954";t4="1332419954"

16 characters are required per time stamp for the first 9 time stamps (that is t1 thru t9), 17 characters are required per time stamp for the next 90 time stamps (that is t10 thru t99) and 18 characters are required per time stamp thereafter. On this basis, up to 234 time stamps can be stored within the 4096 character field thereby supporting a maximum XEvents value of 234.

Note: 234 is the maximum value that should be used for the field XEvents for this reason.

NumXinY INTEGER

Note that it is possible to receive multiple instances of the same event (that is, with the same Identifier) that have valid XEvents and YSeconds values, as well as ones that have invalid, non-zero XEvents and YSeconds values. time stamps are only collected for events where both the XEvents and YSeconds fields have valid, non-zero values. As a result, while the Tally field stores the total number of occurrences of any event, NumXinY stores the number of events with valid XEvents and YSeconds field values. This field is used by the X in Y functionality therefore to decide whether enough time stamps are stored to enable threshold calculations to be done. Threshold calculations are performed only once there are XEvents number of time stamps.

XEvents INTEGER

This field stores the first part of the threshold: the number of events.

YSeconds INTEGER

This field stores the second part of the threshold: the number of seconds. This field is used together with the field XEvents to calculate whether there has been a threshold breach. Both this and the XEvents fields must be set to valid, non-zero values in order for the X in Y functionality to activate for any given event.

Two procedures

xiny_add_time stamp

The purpose of this procedure is to add a time stamp to the time stamp field XinY. If no time stamp is provided when the procedure is called (that is, a zero value is received), the procedure adds the current time stamp into the time stamp field.

The procedure will only store at most XEvents number of time stamps since this is the minimum number required to make a decision as to whether there has been a threshold breach. Storing any more than this will unnecessarily increase the field size within memory and thus the ObjectServer’s memory footprint.

The procedure will store successive time stamps in chronological order, from newest to oldest, and also only store the most recent XEvents number of time stamps. If the procedure is called with a time stamp that is older than the oldest value currently stored and the time stamp field already has XEvents number of time stamps, the incoming value is dropped.

xiny_calculate_breach

This procedure takes the time stamp field XinY, the threshold values XEvents, and YSeconds and determines whether a threshold breach has occurred. If a threshold breach has occurred, this is indicated and passed back to where the procedure was called from. In the case where a threshold breach is detected, the SuppressEscl field is set to 1 meaning it is now in an “Escalated” state. Operators can then see the event is escalated in the Event List and can take action.

Note: The procedure xiny_calculate_breach is only included in the Aggregation layer ObjectServers since breach calculations are only done at the Aggregation layer.

Two ObjectServer database triggers

xiny_on_insert

This database trigger fires before an event is inserted into the ObjectServer that has valid, non-zero values for both XEvents and YSeconds, and the Severity of the incoming event is not zero. If these conditions are true, the current time stamp is added to the time stamp field XinY.

On an Aggregation layer ObjectServer, this procedure will only insert a time stamp if the incoming event did not come from a Gateway. This is because if the incoming event came from a Gateway, it originated within another ObjectServer and therefore will already include a set of XinY values. In any case, a breach calculation is done for each insert into an Aggregation layer ObjectServer.

Note: Threshold breach calculations are only carried out at the Aggregation layer.

If a breach is detected, which is possible if an event has been received from the Collection layer with a number of time stamps included, a journal entry is added and the event is escalated.

Note: At the Aggregation layer, this trigger will only fire on the acting primary.

xiny_on_reinsert

This database trigger fires whenever an event is reinserted into the ObjectServer that has non-zero values for both XEvents and YSeconds, and the Severity of the incoming event is not zero. If these conditions are true, the current time stamp is added to the time stamp field XinY.

On an Aggregation layer ObjectServer, this procedure treats reinserts coming from the Collection Gateway differently from events being reinserted from other sources. Because time stamp collection is also occurring at Collection layer ObjectServers, the incoming reinserts from the Collection layer include a set of XinY values that need to be merged into the values already at the Aggregation layer.

It does this by iterating over the incoming XinY value set and adding it to the local set through the procedure xiny_on_reinsert. This ensures that all incoming values are stored in sorted, chronological order. If the local copy of the event already has XEvents number of time stamps stored and any of the incoming values are older than the oldest one already present, those individual incoming values are dropped.

Note: The solution includes a modified table replication definition file for the Collection to Aggregation Gateways that clears the XinY and NumXinY fields at the Collection layer copy of the event after the event has passed up to the Aggregation layer. This way the Aggregation layer triggers can assume that any incoming values to the Aggregation layer have not been processed previously and need to be added to the current set of collected time stamps.

Reinserts coming from other sources except the failover Aggregation ObjectServer Gateway, for example a Probe, trigger an insert into the XinY time stamp field with the current time stamp.

Reinserts coming from the failover Aggregation ObjectServer are ignored regarding threshold calculations since the event source is the counterpart Aggregation ObjectServer replicating its events.

In all cases where a time stamp is inserted, a threshold breach check is carried out through the procedure xiny_calculate_breach and the event is escalated, if necessary.

Note: Threshold breach calculations are only carried out at the Aggregation layer.

If the event is escalated, a journal entry is also added to the event to indicate that it was the X in Y functionality that escalated the event and at what time.

Note: At the Aggregation layer, this trigger will only fire on the acting primary.

Modified Collection to Aggregation Gateway table replication definition

AFTER IDUC DO 'Tally = 0, SentToAgg = 1, XinY = \'\', NumXinY = 0'

An example of this is where a Probe has failed over or failed back between a pair of Collection layer ObjectServers. In this case, there might be occurrences of the same event coming from more than one Collection layer ObjectServer, each with a set of time stamps, converging on the Aggregation layer that needs to be merged.