--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Dec 05, 2003 at 03:12:06PM -0000, Sam Stickland wrote:
> I'm after a slightly better solution for SNMP trap monitoring.
>=20
> SNMP traps are submitted as passive service checks. All the examples show
> the a single service defination for the traps - this has the unfortunate
> effect of the next SNMP trap overwriting the previous. I'd like to have
> different services definations for different SNMP traps on our networking
> equipment, but that would result in a LOT of service definations.
>=20
> It would be nice if there was a sub-service id that could be submitted wi=
th
> passive checks, that effectively divides a single service into multiple
> services on demand, without the need for 1000's of service definations.
>=20
> Is there a solution to this that I've missed, or is it going to require
> changes to Nagios? I'm a fair programmer so I'm happy to make these chang=
es
> myself, but others might not consider this a good solution to this proble=
m.
I have a similar problem here, with rougly 1000 hosts and almost 10000
services.
I have a perl daemon running which recieves traps and inserts them as
passive check results.
For those reading at home, I didn't want to use the net-snmp trapd and make
it call a perl process, because it's SLOW doing a fork() & exec() for every
single trap, when I receive about 5 every second. I get lots because my
systems send status updates as well as faults.
The way I deal with it is by creating service definitions for critical
stuff, and ignoring almost everything else.
It's amazing the amount of traps that Cisco devices, for example send which
we really don't need to deal with. This has enabled me to receive alerts
for stuff I need, but still at only 10 services per host average.
It's probably not ideal, but it does what we need.
--=20
Regards,
David Parrish
0410 586 121
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/1Q6u3t7cw0+u5QwRAmhaAKC0dN/kbD8eznnmALGVyawVxH2qRwCgxRyX
4IoZGd+ca/pX9ZNkBA/xw0Q=
=m57/
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: david@dparrish.com