On 09/11/2013 08:59 AM, Florian Lohoff wrote:
Basically we dropped most of the packaged nagios-check scripts except the very simple tcp/udp/dns checks. But thats a one-time thing to do.
Yeah, if you want subtle monitoring then nagios might involve a bit of coding of checks - the stuff on nagios exchange tends to be very server-oriented.
e.g. we had to write checks monitoring STP root placement, presence of all vlans on all uplinks, and so on.
Then we wrote an exporter for our config/asset database to generate a nagios config with all the parent relations, alert groups etc ...
+1 this is the way to go - export your asset DB, and force it to be authoritative. Ongoing maintenance of nagios is then close to zero; the occasional bit of patching, tweak thresholds here and there, etc.
Now we export config via cron - people just tell in the asset/config db which interfaces or details to monitor (packet discard, error, temperature, filesystem free %) with which threshholds and whom to alert. Not for someone without config/asset database purely relying on autodiscovery.
Frankly, if people are relying purely on autodiscovery then they have bigger problems to solve than what monitoring system to use IMO!
Using auto-discovery to supplement an asset DB - for example, populating serial numbers, current software versions - is a very sensible strategy. Even using it to populate the asset DB the first time around. But not to *define* the list of things you monitor!
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
