Comments on: Scalability and Performance (Design and Testing) in the xSNMP Management Packs

By: David Bruce

David Bruce — Tue, 28 Sep 2010 11:36:24 +0000

My last comment contained a question, but maybe it was too hidden as nobody has replied.
Is it not the case that any simple schedule with fixed values for Interval and SpreadInitOverInterval will be cooked down to a single scheduler, thereby completely negating the purpose of SpreadInitOverInterval? That’s certainly what my experiments seem to show.
I have a couple of other questions that I would really appreciate any advice on.
I have several rules and monitors targetted to SNMP network devices. When the device goes offline, these all fail and log errors in the event log. Is there a way to make these rules and monitors dependent on the availability state of the devices, as already determined by the CheckDeviceStatus rule?
Would I be likely to achieve higher scalability by combining several OIDs into a single data source type? At the moment, each rule and monitor probes a single OID, so sending a separate SNMP Get request for each, but I wonder if these could be combined into a single request to reduce the loading on the Windows SNMP module and avoid all those 0x6f errors.

By: David Bruce

David Bruce — Mon, 20 Sep 2010 10:52:18 +0000

I’ve found this post very useful and have implemented some of the suggestions on breaking cookdown, which has helped greatly, but my experience has been different from yours and I think I must be missing a point or two.

I have a dozen or so performance rules that gather SNMP data every minute. Each rule is based on a data source module type; each data source contains a system scheduler with a simple recurring schedule and a probe action.

Simply adding a SpreadInitializationOverInterval to the simple recurring schedule in each data source module type made absolutely no difference. SCOM (I think) cooked down all the system schedulers to a single one, so all the SNMP probes fire simultaneously. By setting a different spread interval to each data source module type, I was able to get the probes for each performance rule to fire at different times, but the probes for all devices for a single performance rule still fire simultaneously, so I still have a nasty scaling problem.

I can, and almost certainly will, add a random value to the device config to circumvent this, as you suggest, but I’m curious how you managed to get device workflows spread without this little trick. It’s almost as though something in your management pack stopped cookdown from checking the internal structure of your data source and realising that, although the config for the data source was different (was based on the device), the system scheduler that is a member module of the data source module type is exactly the same (config is just interval and spread interval) so the schedulers could all be shared.

By: Pavel

Pavel — Fri, 22 Jan 2010 14:01:42 +0000

Awesome job, Kristopher (and everyone who is contributed to this project)!
Thank you!
Are you planning creating additional MPs for xSNMP in the near future? And if yes what devices were you planing to include? Personally I would like to see AVAYA and VMWare MPs.

Thanks again

Pavel

By: xSNMP Management Packs – Beta Version 1.0.8 Release « Operating-Quadrant

Thu, 21 Jan 2010 21:32:36 +0000

[...] Scalability and Performance (Design and Testing) in the xSNMP Management Packs [...]

By: Kristopher Bash

Kristopher Bash — Sun, 20 Dec 2009 05:05:34 +0000

You can email me at opquad@ live.com

By: Stephen Hull

Stephen Hull — Sun, 20 Dec 2009 03:04:23 +0000

Kris,

Excellent information on your site! I am new to MP Authoring and your info has helped greatly.

I am developing my own Cisco MP and it is a little different. I have some questions for you, if you have a little time. Where is the best place to communicate with you? Is it here? Where on this site, if it is here.

Thanks a bunch and keep up the good work.

-Stephen

By: René Eigenmann

René Eigenmann — Thu, 17 Dec 2009 12:27:47 +0000

Hi Kristopher

I like your Cisco MP and firstible a wand chang the MP for my Wlan Router. But now i see your Project and i am very happy.

Thanks for this great work

Kind regards

René Eigenmann

By: Kristopher Bash

Kristopher Bash — Wed, 16 Dec 2009 01:50:20 +0000

Thanks for your comments. I hope you find these MP’s to be much improved over the original Cisco MP…when they are released.

By: Mike Clark

Mike Clark — Tue, 15 Dec 2009 10:10:14 +0000

Thanks Kristopher. This has definately cleared up a lot with the new management pack. Ive found the older pack heavy on performance and have ended up removing it for the time being until this new pack is available.

Thank you for developing this, it really is nice and neat to get everything in OpsMgr.