Hi All,<br><br>I decided to go down the path of Nagios for a number of reasons, primarily it already exists and is configured as well as NRPE being installed already on all of the servers. It also gives us the flexibility of actioning based on environmental alarms and closed circuit switch alarms etc. I looked at NUT and the snmp driver is currently experimental and it specifically states to "not use this driver for productions networks", plus the windows client looks particularly primative in the shutdown department (shutdown after X minutes...no option for running a script or shutting down services first).<br>
<br>In any case I have since discovered something particularly annoying. I am by no means any kind of SNMP expert but I believe I understand enough to be dangerous, and this lack of expertise has prohibited my arguements with the UPS vendor. I am wanting to poll 'upsAlarmOnBattery' for obvious reasons and when I do I get no response. The official word from the UPS manufacturer is that certain OID's only respond when they are in an alarm state and not to blame them because they are simply following the RFC1628. However, in my opinion, either their implementation of the RFC is wrong or the RFC itself is broken. Here is the Object:<br>
<br>upsAlarmOnBattery OBJECT-IDENTITY<br>    STATUS    current<br>    DESCRIPTION<br>        "The UPS is drawing power from the batteries."<br>    ::= {upsWellKnownAlarms 2}<br><br>I can understand if there was an ACCESS option specified that was preventing me connecting, but there isn't. <br>
<br>So, my question is this...Should I be able to retrieve an "ok" from this object when there is no alarm and a "critical" if there is? Can anyone who has an SNMP equiped UPS try retrieving this from their UPS to see if it works for you? If I can't retrieve this can someone explain how to differntiate between a valid (no returned value) lookup and a failed lookup, and why it would have been setup like this?<br>
<br>Kind regards,<br><br>Adam.<br>