Thanks to Jim and Mike. The idea of Nagios sending traps actually is much in line with the SCOM way of doing things, as far as I have understood.
Personally, I find the trap-based approach rather fragile, though: - The receiver (SCOM) may be down when a trap is sent. Actually not that far off during a service window where the Nagios server could very well be up before the SCOM server. - There may be situations with mismatches between alarm-mails and recovery mails, like Mike described. This can lead to alarms which keep living long after the problem-situation went away. I much prefer polling-based monitoring, because transient misdelivery of messages (such as traps) doesn't undermine the trustworthiness of the monitoring setup. - But the trap-based approach certainly seems like an easy way to get something going. -- Regards, Troels Arvin <tro...@arvin.dk> http://troels.arvin.dk/ ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Nagios-users mailing list Nagios-users@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
