Designated stats node(s)

[sushi90]

I need a way of setting which node is Stats node.Because some node have my durable queue, they are very busy.If they selected Stats node.The performance is too bad!

[michaelklishin]

There is no way to do that presently. One designated node sounds like a bad idea availability-wise.

[noahhaon]

I would like to add a +1 to this feature request. In Google's whitepaper on scaling RabbitMQ they make mention of running a dedicated stats node, and in my conversations with Pivotal support they suggest this as well. We do this in our deployment, by being careful which node gets started first in our cluster, and ensuring that fewer queues are running on the stats node.

The lack of a configuration to select the stats node makes this difficult to do, but something similar to the ha-policy which applies to queues would be very nice to have for the stats node. If the recent improvements to the management plugin have allowed the process(es) on the stats node to utilize multiple cores, then this may be more important as it could now have an even larger footprint on the node it is on, causing more contention with other processes.

[michaelklishin]

How should this work if the designated stats node is unavailable? At the very least it should be a set of nodes.

[noahhaon]

I think the easiest to reason about would be something like,

1. Node is selected via existing behavior
2. If Node is not in preferred list, defer/fail over to plugin running on preferred Node if available, in order specified in list
3. If all plugins on preferred Nodes are unavailable, log error and remain running

What do you think?

[michaelklishin]

By "log an error and remain running" do you mean "migrate the database to a different node not on the list"?

[noahhaon]

No. In step 1, I assume the normal/legacy stats db startup has happened (or is happening). In step 3 it would just continue running on whichever node it started on in step 1, per the current behavior, instead of migrating to a "preferred" node.

[michaelklishin]

We're discussing this as part of #236 but in 3.7.0. Many open ended deployment questions, in particular with a cluster of collectors ("management nodes"), so far.

[michaelklishin]

#236 (which is close to being merged) makes this issue effectively obsolete.