Question about NSO Alarm Implementation

[previousqna]

Hi NSO experts.

I got a question from my customer about NSO Alarm implementation.

NSO Northbound APIs Chapter 5. NSO Alarms says following alarm type are supported.

alarm-type

ncs-cluster-alarm

cluster-subscriber-failure

ncs-dev-manager-alarm

ned-live-tree-connection-failure

dev-manager-internal-error

final-commit-error

commit-through-queue-blocked

bad-user-input

abort-error

revision-error

missing-transaction-id

configuration-error

commit-through-queue-failed

connection-failure

out-of-sync

ncs-snmp-notification-receiver-alarm

receiver-configuration-error

ncs-package-alarm

Also Chapter 4. The NSO SNMP Agent describes OID

tfAlarmIndeterminate notification 1.3.6.1.4.1.24961.2.103.2.0.1

tfAlarmWarning notification 1.3.6.1.4.1.24961.2.103.2.0.2

tfAlarmMinor notification 1.3.6.1.4.1.24961.2.103.2.0.3

tfAlarmMajor notification 1.3.6.1.4.1.24961.2.103.2.0.4

tfAlarmCritical notification 1.3.6.1.4.1.24961.2.103.2.0.5

tfAlarmClear notification 1.3.6.1.4.1.24961.2.103.2.0.6

Is there a list which OID is used for each alarm type?

[previousqna]

I haven’t looked into this topic for a while, below is what I can find in my notes.

NSO defines 6 different “types” of notifications. This mainly to cater for legacy Alarm Manager Applications that have a limitation of only being able to de-multiplex the alarms on the basis of severity. This is more so that NSO can interoperate with those legacy applications. These six notifications are defined in the MIB:

tfAlarmNotifs NOTIFICATION-GROUP

    NOTIFICATIONS {

tfAlarmIndeterminate,

tfAlarmWarning,

tfAlarmMinor,

tfAlarmMajor,

tfAlarmCritical,

tfAlarmClear

}

For the new breed of Alarm Manager Application there is no such restriction. Hence, inside the notification itself we have fields that should be used to uniquely identify the alarm-type (including alarms listed in the email below and/or custom alarms defined by the customer). These fields are:

1. Device

1. Managed-Object

1. Alarm-Type: using X733 conventions this is a tuple (event-type, probably-cause)

1. Specific-Problem ß Use this to define as many different Alarm types as required.

Using the “Specific-Problem” field, customer can define as many alarm types as they want over and beyond what is available via the X733 Alarm-Types. The Alarm Manager module in NSO is built to allow for the mentioned flexibility and extensibility. In the Alarm Manager being used by the customer, they just need to de-mux using the combination of the 4 key fields mentioned above:

tfAlarmIndeterminate NOTIFICATION-TYPE

    OBJECTS {

tfAlarmType,

tfAlarmDevice,

tfAlarmObject,

tfAlarmObjectOID,

tfAlarmObjectStr,

tfAlarmSpecificProblem,

tfAlarmEventType,

tfAlarmProbableCause,

tfAlarmTime,

tfAlarmText

}

[previousqna]

Thank you for answering my question.

Can I ask you one more specific question?

NSO Northbound APIs doc “Chapter 4. The NSO SNMP Agent” says there are several OIDs for Alarm.

tfAlarmIndeterminate notification 1.3.6.1.4.1.24961.2.103.2.0.1

tfAlarmWarning notification 1.3.6.1.4.1.24961.2.103.2.0.2

tfAlarmMinor notification 1.3.6.1.4.1.24961.2.103.2.0.3

tfAlarmMajor notification 1.3.6.1.4.1.24961.2.103.2.0.4

tfAlarmCritical notification 1.3.6.1.4.1.24961.2.103.2.0.5

tfAlarmClear notification 1.3.6.1.4.1.24961.2.103.2.0.6

Is it possible to predict which OIDs are used for each alarm type?

For example, which OID is used when out-of-sync occurs?

Is there a kind of list to show it?

Thanks to bother you again and I really appreciate your help.

[previousqna]

When the alarm is submitted:

submitAlarm(...,PerceivedSeverity severity)

the severity is passed on at submission time.

So, for alarms defined and submitted by a service, the service-designer has to document/communicate this piece of info to the stakeholders.

With regards to some of the alarms listed below that we have pre-defined in NSO, one could trigger them and then check the alarm-list to see the severity that they were submitted with.

I’ve done a quick search of the code-base (pardon my knowledge of erlang) and have cut-pasted the definitions for reference (please see attached file – alarm-def.txt). I’m not sure if this is documented anywhere and whether these assignments can change over time. Best to consult with engineering on this.

[previousqna]

Thank you very much.

The file you attached includes the combination of “alarm type” and “sevirity”.

So I can get which OID is used for each alarm type.

I cannot thank you enough.