SNMP Monitoring conundrum
Max
perldork at webwizarddesign.com
Fri Jul 17 00:08:25 CEST 2009
On Thu, Jul 16, 2009 at 5:50 PM, Israel
Brewster<israel at frontierflying.com> wrote:
> Anyone else run into a similar situation? What does everyone else think the
> best approach here is? Thanks.
We do a lot of SNMP monitoring for a number of various agents -
Net-SNMP, Cisco, Sysedge. I have found it to be much easier to
maintain and release the scripts by doing one agent type per script.
This lets you create a 'bundle' of scripts for an agent type.
E.g.
net-snmp/check_net_snmp_cpu.pl
net-snmp/check_net_snmp_disk.pl
net-snmp/check_net_snmp_la.pl
net-snmp/check_net_snmp_mem.pl
net-snmp/check_net_snmp_procs.pl
net-snmp/check_net_snmp_swap.pl
sysedge/check_sysedge_cpu.pl
sysedge/check_sysedge_la.pl
sysedge/check_sysedge_mem.pl
sysedge/check_sysedge_swap.pl
sysedge/check_sysedge_unix_storage.pl
This then helps us also keep our configurations consistent as we do
the service definitions and comand definitions in files by type ..
ommands/net-snmp.cfg
commands/sysedge.cfg
services/net-snmp.cfg
services/sysedge.cfg
As you know, code bases get pretty big pretty quickly with SNMP, so
having one agent type per script also decreases the chances of bugs
and makes it easier to fix bugs when they arise.
So my personal recommendation is to keep the scripts to 1 agent type per script.
- max
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
More information about the Users
mailing list