From: Gary <ga...@80...> - 2005-03-10 16:52:10
|
David Thanks for replying.. See below... > -----Original Message----- > From: ope...@li... [mailto:opennms-devel- > ad...@li...] On Behalf Of David Hustace > Sent: Thursday, March 10, 2005 7:48 AM > To: ope...@li... > Subject: Re: [opennms-devel] snmp-event.pl and outage events > > > On Mar 9, 2005, at 10:41 PM, Gary wrote: > > > Ok here is my second post since I figured out my first problem in > > building > > custom plug-ins myself. > > Very good. > > > I have extended the plugin interface to support > > BeanShell which lets me write my own plug-ins very quickly. > > Pretty cool. > > > I am however somewhat dependant on the send-event.pl script for adding > > descriptions to events (i.e. the output from a failed https call using > > curl) > > I'd like to understand the difference in behavior from the HTTPS > monitor and the curl command line. I don't doubt that you have > extended the functionality or have a different behavior entirely. My > only concerns are: > The primary purpose of using curl is for dealing with SSL sites using BASIC-AUTH. I can use a .netrc file to pass the authentication parameters into the session and get my HTTP return code and Headers.. > - The dependencies that this places on curl / perl. I like your > ideas > for easily extending monitoring with bsh. Why are you sending events > with the perl script? 1) the monitor should indicate to the poller > that a service is down and the poller should generate the event and 2) > couldn't you send this event directly from your bsh processes. > Yes you are right, I started off just returning an exit code and allowing the poller to handle the event creation. The problem is (and I think this was mentioned before) my developers need to see the failure results of the HTTPS GET... We look for things like "account lockout" or 3xx messages which verify the application/db connections are in working order. I have never found a way to pass back the STDOUT results back into the event unless I utilize the send-event.pl with the -d option.. But even if I could create the event using the JAVA methods, I still don't see how to generate the outage record unless I hack the existing poller (which I do not want to do). > - The overhead of the Runtime class calls (3 threads for each > process > to monitor stdin, stderr, stdout) and the waitFor() that blocks until > the subprocess terminates. > > My concern for this is scalability. If you are only monitoring a few > nodes every 5 minutes (not to mention downtime model polls) then > probably not a concern. > I agree, the advanced polling is limited in scalability, maybe the answer is a priority queue which external queries have a lower priority so they don't block... > >> From the Release notes: "For those of you who keep up with the code, > >> notice > > that there is no longer a separate outage daemon. All of that > > functionality > > has been integrated into the poller." > > > > So now it seems that if you issue a nodeDown or nodeLostService event > > from > > send-event.pl an outage event is not triggered. Is this intentional? > > The poller is statefull doesn't and listen for this event because we > make the assumption that the poller will maintain that state by > controlling the monitor's behavior (i.e. node outage processing and > downtime models). The return codes of you monitor should cause the > poller to generate that event and write the outage records. Prior to > the rewrite, the outage writer listened for these events from the > poller only to write the outages. > > > Do you expect to handle externally generated events through the SNMP > > trap interface now? I desperately need an answer. > > We do handle externally generated events and other processes can/will > listen for node lost service even though the poller doesn't. If you > want to extend the functionality of the poller, write up a bug and a > your requirements. > So in conclusion, you can't handle node outage processing out of the stateful poller so any attempt to utilize event driven node down outages is futile. I would have no problem with this as long as I can pass back the STDOUT messages back into the event creation. Is this easily doable today? Thanks -g > -David > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://wiki.opennms.org/tiki-index.php?page=MailingListFaq > > opennms-devel mailing list > > To *unsubscribe* or change your subscription options, see the bottom of > this page: > https://lists.sourceforge.net/lists/listinfo/opennms-devel |