(This is mainly for the benefit of others; ytti and me discussed this on IRC as well)
On Sat, Sep 14, 2013 at 8:37 AM, Saku Ytti <s...@ytti.fi> wrote: > This sounds like you're polling. Correct. > I pains me how little used SNMP traps are, which to me is the first check > list item (before even ICMP ping) for functional NMS. > [...] > It's cheaper (computationally) and faster than polling. Traps can get lost. As we are not using traps, we would need to start listening for them. And then design monitoring to ensure that we can receive traps. Plus, even with SNMP inform, in a worst case scenario, the device will retry sending the trap, but not be able to deliver. If that's because of misconfiguration, it will be permanently silent with no way of catching it. So now we have to maintain a list of all trap-sending devices and make them send a trap every 24 hours so we _know_ what's up. Polling will either return a result you can trigger upon or not return a result, which a second level trigger can then act upon. While more expensive, it's an inherently safer design. As per IRC, we are working with Zabbix to have their solution trigger on certain SNMP polling items going into/being in "not supported" internally. In the meantime, it looks as if I will parse our "show foo" backup database and look for missing PSUs that way. As those are well-maintained and monitored aggressively we _know_ that the data in there is both current and good. -- Richard _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/