Uniquely Identifying Alarms
With current releases of Orchestrator supporting the Orchestrator Notification Service, alarms generated both natively by the appliances and by Orchestrator can be sent in real-time to different log receiver types. This provides users with a single consolidated stream of reliable alarms, regardless of changes in the SD-WAN topology or deployment. The aggregated alarm notification stream can be provided via syslog, HTTP/HTTPS, and Kafka. A message ID is incorporated into the alarm structure, enabling recipients to detect missing alarms and request resending of any missed notifications.
The Orchestrator provides and aggregated catalog of the alarms that it and the attached appliances may generate. This catalog is downloadable and contains information about each of the alarms. Each alarm includes a default perceived severity, an alarm description, a recommended action, and 3 fields that can be used to unique identify the alarm. This 3-tuple comprises the following:
-
Product Type (System Type): this field identifies the type of system that is generating the alarm. Alarms today can be generated by EdgeConnect itself, by Orchestrator (or an orchestration tenant, as in the case of the multi-tenant orchestration solutions), or by the top-level multi-tenant orchestrator itself (Orchestrator-SP and Orchestrator Global Enterprise).
• The values that Product Type can take on include • 0: appliance-generated alarms • 100: Orchestrator or orchestration tenant-generated alarms • 200: Orchestrator-SP or Orchestrator Global Enterprise generated alarms
-
Alarm Category (Source Type): within each Product Type, the alarms are divided into different categories. There
are 5 alarm categories:
• 1: tunnel alarms (applicable to both Orchestrator and appliance alarms)
• 2: traffic class alarms (used by appliance only)
• 3: equipment related alarms
• 4: software related alarms
• 5: threshold crossing related alarms (used by appliance only) -
Alarm Index/ID: within each alarm category, each specific alarm is enumerated using an alarm index that is
unique.
The 3-tuple is stored in the “msgId” field of each alarm. The “msgId” itself can be used to uniquely identify an alarm type, but if there is a need to access the specific values for Product Type, Alarm Category, and Alarm Index, the msgId can be parsed into these 3 values using the following technique:- Bit-shift the msgId value by 16 (msgId >> 16) - If the resulting value is between 0-99 • The ProductType value is 0 (Appliance generated alarm) • The Alarm Category is represented by the result - If the resulting value is between 100-199 • The ProductType value is 100 (Orchestrator generated alarm) • The Alarm Category is represented by the result minus 100 • In decimal, these alarms have msgId values greater than 6553600 - If the resulting value is >200 • The ProductType value is 200 (Orchestrator-SP generated alarm) • The Alarm Category is represented by the result minus 200 - The Alarm Index value is represented by the rightmost 8 bits (msgId & 0xFF)
Note: alarms contain both an alarm type ID as well as a unique alarm ID. The alarm type ID is the index value of an alarm within a certain alarm category. For example, within the alarm category of Equipment alarms, there are specific equipment-related alarms that are generated, each with a unique index within that category. The above is the method for identifying the type of alarm. Within each Orchestrator instance, a unique ID (known as the alarm ID) is generated for every raised alarm. This ID is used to correlate Clear notifications with the alarm-raised notification within Orchestrator.
For each alarm type, there may be a raised event and a cleared event, The unique identifier for any specific alarm is the “alarmId”, and is used to correlate raise/clear events on a particular alarm instance.
Updated about 1 year ago