On Mar 2, 2017, at 1:46 PM, Garrett Michael Hayes <garr...@verbalimaging.com> wrote: > > I would like to set up a Linux host as a central monitoring system for UPSs > throughout our network. I’d like that system to be able to see the various > UPSs basically in one of two ways: > 1) Tapping into a native network interface on the target UPS (such as > some larger APC and Tripp-Lite UPSs we have) > 2) Talking to a Raspberry Pi connected to the UPS via a USB or serial > cable (for lower end UPSs that don’t have network capability)
One of the design goals of the NUT drivers is that they provide their status and measurements using a common naming scheme. There is a SNMP driver that covers most the APC and Tripp-Lite MIBs, so that should cover case 1. (The three-phase names are similar to the single-phase names.) I have done a fair amount of testing with a Raspberry Pi and USB, and it is no worse than USB on a PC, so that covers at least part of case 2. I think you would need a level-shifter to do RS-232 serial with a RPi, and you may need to fiddle with the cable if modem control lines are involved, but it should be possible. I will point out that we sometimes run into regressions with firmware upgrades on SNMP network cards, but often it is something that can be fixed by downgrading the firmware, or bugging this list to fix the NUT side. Also, there are some Tripp-Lite USB models which seem to have trouble keeping a connection up long-term. Either way, we do have an extensive collection of sample datasets here, if you are interested in seeing the sort of values you can expect (and problems that users have noticed) on a Vendor/Model basis: http://networkupstools.org/ddl/ > I’m interested in monitoring and alerting, not so much in making changes to > the UPS settings or shutting down computers, etc. > For monitoring, you would run "upsd" plus the model-specific driver(s) on a nearby system. If you are monitoring over the network, fewer hops between driver and UPS network card would be best. USB pretty much means the machine with the USB host port must run upsd, although as you pointed out, that machine can be an embedded system. If your USB UPS reports a unique serial number (as seen in "lsusb" or kernel message logs; the 16-bit user-definable Tripp-Lite unit ID seen in their GUI doesn't meet the criteria), you can even have several USB UPSes monitored by one upsd. From there, you have a number of choices for polling the data from upsd. NUT comes with "upsmon", a basic shutdown/alerting tool, but you can always define the shutdown command to be something innocuous like /bin/true, and/or give each UPS a "power value" of zero. You can use upsmon for "raw" notifications - reporting an event as soon as it happens, basically. If you want to "de-bounce" an event (that is, only send an email if the power is out for more than 30 seconds), you can configure upsmon to call "upssched" to start a timer, and trigger an action if the timer hasn't been stopped. * http://networkupstools.org/docs/man/upsmon.html and http://networkupstools.org/docs/man/upsmon.conf.html * http://networkupstools.org/docs/man/upssched.html and http://networkupstools.org/docs/man/upssched.conf.html It has been a while since I last set up the NUT CGI components, but I suspect you can just list each UPS in the template for upsstats, and add in upsimage references where you want graphs: * http://networkupstools.org/docs/user-manual.chunked/ar01s02.html#_cgi_programs * http://networkupstools.org/docs/man/upsstats.cgi.html * http://networkupstools.org/docs/man/upsimage.cgi.html You can ignore upsset for a read-only dashboard. We don't have a lot more documentation on the CGI scripts (other than reference material), so if you don't feel comfortable setting this up from scratch, you might want to see if any of the monitoring systems listed here would be quicker to configure for your dashboard idea: http://networkupstools.org/projects.html#_network_management_systems_nms_integration (I personally use collectd, since it gathers stats on other subsystems that I care about in addition to NUT. I either use kcollectd to view the RRD files locally in X, or I have set up collection3.cgi for remote viewing.) You could probably configure the monitoring system to alert you to various UPS conditions as well. One thing that hasn't been mentioned yet is that you can prototype all of this by using the dummy-ups driver. This driver simply reads values repeatedly from a file, and you can edit that file to simulate events like short power glitches. Again, you can consult the DDL site listed above to pull sample values for a model similar to one that is deployed, and test the entire driver/upsd/upsmon stack on a laptop or VM without needing actual UPS hardware. If you use an automation system like Ansible, it should be fairly easy to create templates for all of the configuration files (including setup of the RPi nodes), and just change the host list when it is time to deploy to the production system. Let us know how it goes. (opinions are my own - I do not speak for my employer, etc, etc.) -- - Charles Lepple https://ghz.cc/charles/ _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
