Provide a "Polling Weight" for Nodes

When we're trying to balance the load between multiple pollers we're currently needing to add up the node + interfaces + volumes + SAM components to get an idea of how much impact a particular node is having on a poller. It would be great, since it looks like there's some weight calculation already happening to get the % of consumption on a poller, to have that generated value on a per-node basis.

For example, an ICMP node would be given a slightly lower score than a WMI or SNMP node

Find more posts tagged with

weight

balance

Polling

Status: None

Comments

jm_sysadmin

I love this idea! Maybe polling frequency be included in the weight too

wluther

Yup!! It would make things so much easier if we had a value to call in a query, similar to how we call a custom property, or any other property.

+1 up vote from me!

nick_scott

Alll the large customers would benefit SIGNIFIGANTLY from this. The ad hoc report is nice, however something out of the box would be a nice feature for SLW to market.

borgan

With more and more large customers with multiple apps and polling engines, this is a much needed feature in order to know the true impact of moving nodes between PEs. Those nodes are likely to have applications attached, be flow sources, SLAs, transactions associated, etc.

jm_sysadmin

Paging jbiggley what you do think?

yaquaholic

Bump!

If Orion could fully understand the element usage and then tie that back per node, it would have made my last costings exercise, so, so ,so much easier!

I ended up deep in SQL and spreadsheets, to come up with an element per customer group type report.

wluther

Actually, Orion already knows this information... If you build an additional polling engine, all of the stats for that new APE are 0... Then, if you were to move only a single node onto that new APE, and give it a few minutes, all of those polling stats would update, giving you the total costs of polling that node, as well as all of the individual costs too. So, since the formula appears to exist already, I think they could "fairly easily" incorporate that data into a couple of node properties, custom or otherwise, which should solve this whole issue, or at least bring it down to a far more manageable level, until they can develop a better way.

Or maybe they could just build us an internal macro that would do all of the back end calculations, where we could just make a custom property, and then drop in ${PollingCost}, showing the weight of each node... (I'm sure there is more to it than that, as always...)

wluther

cobrien While we all know you may or may not be able to say, or not say, anything that would, could, or should, definitively address any issues, features, or aspects of anything related to anything that could have, or not have, any issues, features, or aspects to relate to... What's the deal with this feature request? I mean, it has been here 13+ hours, and I still don't see anything being done about it... Okay, now that I have that out of my system...

Are there currently any paths being walked at SolarWinds that could possibly cross anything to do with automated balancing of polling engines? Anything that could eventually allow the users to see the total polling cost per node, and see that value on each node, being able to call it?

Thank you,

-Will

jbiggley

To my understanding, this is the secret sauce of the Orion platform. Obviously Orion (as if it is some sentient being!) knows this already and could provide the data or at least data in such a way that we might be able to reverse engineer it. We'd definitely need to get someone from SolarWinds to weigh in on this one.

To add some complexity to the equation, it appears that SAM is far more efficient at polling and storing data than some other platforms. I think this is due both to the focus on SAM as a platform for innovation, but also to the fundamentals behind how data is collected. I can point to UnDPs at a large scale as being far less efficient at handling queries against those tables than the same data stored in SAM.

I suspect that the data behind the collection weight for a node could be calculated whereas the weight of a node on your SQL infrastructure might be a little more obtuse.