An aggregate notification is a notification that is composed of one or more component events. When one of the component events occur, the aggregate notification is notified. Creating an aggregate notification provides several benefits:

  • Aggregation compresses multiple component events into a single aggregate notification.

  • Aggregation helps you organize related traps into meaningful categories.

  • Aggregation provides a method by which the details of the component events can be displayed to an operator. The component events of an aggregate notification are displayed in the Aggregate tab of the Notification Properties Dialog Box of the Global Console.

    You use the aggregate in your trap definition to create an aggregate notification as well as the aggregate’s component event(s). You are required to define an EventName for each aggregate or component event. Also, since all notifications are uniquely identified by EventName and the ClassName, and the InstanceName it OccurredOn, values must also be derived for the two latter attributes.

    VMware, Inc. recommends that you explicitly define the ElementName:<object-handle> within the Aggregate portion of the trap definition. If you do not explicitly define the ElementName within the Aggregate portion, then the ElementClassName and ElementName of the trap definition are used, if available. Alternatively, if ElementName and ElementClassName are not defined, then the ClassName and InstanceName are used to define the aggregate.

    The following example illustrates how to configure two different trap definitions to generate the same aggregate notification. The first trap definition processes an incoming trap that indicates a system is experiencing low memory. The second trap definition processes an incoming trap that indicates that a system’s processor is experiencing high utilization. Since both of these traps are indicative of system degradation, if either trap is received, a Service Assurance notification is generated to indicate that the system is degraded. 

    BEGIN_TRAP .1.3.6.1.4.1.546.1.1 6 1
 ClassName:    Memory
 InstanceName:    MEM-$SYS$
 EventName:    Low
 Aggregate:    {
       EventName: Degraded
       ElementName:$SYS$

     }
 Severity:    1
 Expiratiton:    30
 State:    NOTIFY
 ClearOnAcknowledge:    TRUE
END_TRAP
BEGIN_TRAP .1.3.6.1.4.1.546.1.1 6 2  
 ClassName:    Processor
 InstanceName:    PRO-$SYS$
 EventName:    HighUtilization
 Aggregate:    {
       EventName: Degraded
       ElementName:$SYS$

     }
 Severity:    1
 Expiratiton:    30
 State:    NOTIFY
 ClearOnAcknowledge:    TRUE
END_TRAP

    Using the example, if a trap with OID .1.3.6.1.4.1.546.1.1 6 1 is received from Router::CoreRouter1, the component event Memory::MEM-CoreRouter1 Low is generated. Similarly, if a trap with OID .1.3.6.1.4.1.546.1.1 6 2 is also received from the same router, then the component event Processor::PRO-CoreRouter1 HighUtilization is generated. Since the same aggregate is defined for both of these traps, this will also generate the aggregate notification, Router::CoreRouter1 Degraded.

    Although all events are propagated to the Service Assurance Global Manager, only the aggregate notification (Router::CoreRouter1 Degraded) will display in the Global Console. This is because the default NotificationList used by the Global Manager is configured to filter out the component (raw trap) events. If desired, the Global Console operator can display the component events from the Notification Properties Dialog Box by choosing the Aggregate tab.