I'm having some trouble finding the correct method for alarming on entries in a table from an SNMP get request. The problem I've got is the table entries are OID's that have no value and can’t be interrogated directly. It’s the upsAlarmTable that is part of rfc1628. The upsAlarmTable entries have an upsAlarmId, upsAlarmDescr, and upsAlarmTime. The upsAlarmDescr returns and OID when the alarm is present but those OID's can’t be interrogated directly so have no value they can return. The description in the MIB says as much as well:
"A reference to an alarm description object. The object referenced should not be accessible, but rather be used to provide a unique description of the alarm condition."
I can interpret the OID's returned to display the alarm name in the table but that doesn't help me to alarm off the table entries and create alarm templates since they don’t have a Param ID. Though, at least the alarms clear themselves from the table when the condition clears. I'm probably overthinking this and I'm assuming since this is rfc MIB that I'm not the first person to come across a table that behaves in this way and there is a known way to handle them. Can someone help point me in the right direction? I've been going through videos and documentation but currently I'm either looking in the wrong places or I'm just not experienced enough to realise the solution is easier than it seems?
Hi Alun,
Checking the description of the upsAlarmTable, the upsAlarmDescr column will contain a reference to one of the entries from upsWellKnownAlarms (as shown in your example).
From what I understand, the row representing the alarm will stay there as long as the failure is present on the device. I noticed something interesting in the table description:
No two rows will have the same value of upsAlarmDescr, since alarms define conditions.
Based on this, I believe there are two possible options to integrate these OIDs in the connector:
- Implement single parameters for each well known alarm: You could implement single parameter representing each possible upsAlarmDescrp. For the alarm shown in your example, you can create a single param 'Battery Bad' with two possible values: Present, Not Present. Whenever you receive a row with that description, you can set this single parameter to 'Present'. If you don't receive it, then you can set this single parameter to 'Not Present'. You could then enable monitoring on these single parameters. Drawback here is that you will loss the upsAlarmTime column.
- Implement a custom table: You could implement a custom table that will all the well known alarms (as rows). In this custom table you could add an extra column 'Alarm Present'. Similar as previous case, whenever you receive a row with that description, you can set this single parameter to 'Present'. On top of that, you could add an extra column to store the timestamp from upsAlarmTime.
Keep in mind that in both cases you will need to implement the SNMP table. However, this SNMP table should be hidden.
Hope it helps.
Ahh! Awesome! This sounds like the pointer I was searching for, thanks! I’ll try it out.