Using the Trap Adapter Aggregate parameter

An aggregate notification is a notification that is composed of one or more component events. When one of the component events occurs, 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 window of the Global Console.

  You use the aggregate in your trap definition to create an aggregate notification as well as the aggregate’s component events. You are required to define an EventName for each aggregate or component event. Because 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. As both traps indicate system degradation, if either trap is received, a 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. Because 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 appear 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 window by clicking the Aggregate tab.