From: Craig M. <cra...@op...> - 2011-04-27 20:50:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, Thanks for the feedback. I think I agree with you, both for the reasons you state, and because I've had a look into some of the collectors (and the collectors looked back). To summarise: the collectors are somewhat inconsistent in how they report failure or success: HTTP: Sets the status to FAILED if any one of the URIs has a problem. Then sets the status to SUCCEEDED immediately after the loop over URIs, so you'd need to get an uncaught exception while in the main loop to get a final FAIL result. And any URIs had succeeded would have their values collected/reported. NSClient: If any items succeed, the whole collection gets marked as SUCCEEDED. Any that fail are pretty much ignored. JMX: Looks like it'll always succeed (catches any exceptions and always sets the state to SUCCEEDED at the end). SNMP: Will say "FAILED" if it encounters any substantial problem (needs to fully finish it's entire check before it marks it as SUCCEEDED). Values already obtained are returned (I think). Bugger. So somehow to fix NMS-4244 I'm going to have to know which values were collected successfully in the current run and which weren't. Oh well, back to the drawing board :) C Michael Seibold wrote: > Hi Craig, > > I believe it will be dangerous to threshold only when all values of a > collection step are received successfully. Some values -as already > described by you- might never get collected. If this prevents other > values from beeing thresholded it's quite difficult to know when our > configured thresholds will work and when not. You need deep insight in > grouping together the values etc. instead of simply configuring a > threshold and believing that it will work if the corresponding value > gets collected. > > How are these values grouped together - all values from the same data > collection package for a node, or all values from the same mib tree, or > those who will end in the same rrd file? > > - Michael > >>>> Craig Miskell <cra...@op...> 26.04.2011 23:10 >>> > _____________________________________________________________________ > > Entschlüsselungs-Informationen / 2011-04-26 23:11:34 > Signatur: Nicht ueerpruefbar (Unterzeichner unbekannt) > _____________________________________________________________________ > > > ------START-PGP------ > Hi, > Ref http://issues.opennms.org/browse/NMS-4244, I have found > something > interesting: Thresholding is attempted even if the data collection > cycle failed. > Any missing values will not be thresholded, except for counter values, > which > it'll try to do anyway based on the last value, hence the bug report. > > My question: > Can anyone see a reason why moving thresholding to only occur if > the collection > succeeded (see CollectableService.doCollection())? > > My concern is that we might currently have situations where the data > collection > partly succeeds (e.g. some OIDs are returned but not others). > Currently > thresholding will work for the values are have managed to be collected; > changing > this as suggested means it'll never threshold in the presence of any > error on > that collection cycle (per node/collector). > > Before I spend a few days in the bowels of the collectors, does anyone > know if > I'm worried about something that can even happen (partial collection > result sets)? > > Ta, > > -- > Craig Miskell > Senior Systems Administrator > Opus International Consultants > Phone: +64 4 471 7209 > 73 is the Chuck Norris of Numbers > -Leonard, on The Big Bang Theory > > > ------END-PGP------ > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > 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 > > > Ihr starker Gesundheitspartner – die BARMER GEK. > Auch 2011 gilt: kein Zusatzbeitrag! www.barmer-gek.de > > Diese Nachricht der BARMER GEK kann vertrauliche firmeninterne Informationen enthalten. Sofern Sie nicht der beabsichtigte Empfänger sind, bitten wir Sie, den Absender zu informieren und die Nachricht sowie deren Anhänge zu löschen. Unzulässige Veröffentlichung, Verwendung, Verbreitung, Weiterleitung und das Kopieren dieser Mail und ihrer verknüpften Anhänge sind nicht gestattet. > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > 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 - -- Craig Miskell Senior Systems Administrator Opus International Consultants Phone: +64 4 471 7209 "Yeah, all that emacs is missing to be counted as a full-featured operating system is an easy-to-use texteditor." - -- Arnold Krille on the Linux Audio Developer mailing list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAk24gYQACgkQmDveRtxWqnZNsQCeOYOUVULQVn4r2LncE7tFAQ2g 8W8AoJpqQp6HgOZLvjlZ9G108uBTt1sE =ByIJ -----END PGP SIGNATURE----- |