Marc Powell wrote: > On Jul 15, 2009, at 11:13 AM, David Rosenstrauch wrote: > >> IMO, the ideal solution here would be if I could just submit passive >> check results for services that aren't explicitly configured in >> Nagios. >> But alas, that's not allowed and it fails with messages like >> "Warning: >> Passive check result was received for service 'foo' on host >> 'mysql-dev', but the service could not be found!" > > That's correct but this would be a lot like submitting SNMP traps to > nagios. You might glance over that documentation to get ideas. You > could create a generic service, set it as passive and volatile and > then just start submitting passive results to it with descriptive/ > useful output. Each non-ok result would generate an alert so you > wouldn't miss anything but if you don't build in some protections, you > could repeat notify about the same problem. > > -- > Marc
Hmmm ... Sounds like it might be what we'd want. I'm a bit unclear about how this would work in practice though. What I'd want is that when I go check the Nagios "Service Problems" page in the GUI, I'd want to see multiple lines for the service - one line for each of the tags/files that we're having problems with. But if this is configured as just a single (passive, volatile) service, then wouldn't the GUI show only one line for the service, containing details for only the most recent tag/file that failed the check? Thanks, DR ------------------------------------------------------------------------------ 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 [email protected] 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
