Naming the keda connections in Rabbitmq

[Sathya-omnius]

Proposal

Hi Team,

It would be good feature to add a name for the connection established by Keda in Rabbimq to estimate the no of connections consumed by each Keda config.

Use-Case

When Keda establishing Rabbitmq we could not name the connections , In our product multiple micro-services are connecting to Rabbitmq we can name the connections for all the micro-services so that we can estimate the no of connections utilized by the micro-services , In the similar way we have 100+ keda configs connecting to Rabbitmq but we could not name the connections to understand no of connections used by keda in Rabbitmq.

We observed multiple connections are named with ? but we could not understand whether these connections are used by Keda or others.

Is this a feature you are interested in implementing yourself?

No

Anything else?

If this feature can be implemented in different way in the existing Keda, could you please let us know.

[zroubalik]

Does RabbitMQ support naming of connections? If so and if it is part of the client library, then this could be added.

[mauvilsa]

It does support naming connections. You can see in the screenshot, the first 9 connections are named, the gray text below the IP:PORT. The other connections below are unnamed, which is why you see a question mark ?.

[zroubalik]

OK, then this should be doable, if Rabbit clients supports this. Also worth noting that KEDA supports 2 protocols: http and amqp. Ideally we should add this for both (if supported).

Are you willing to contribute this?

[mauvilsa]

I would be willing to contribute, though I don't know go. Maybe with some guidance it could be doable by me.

But before implementation, there should be an agreement on what to implement. What would be the connection names? Would the names be configurable?

From the github dependencies I see one is amqp091-go, is this the client? In python I have some code that creates named connections. And providing the name is not even required to be supported by the client because it is part of the url. I have something like broker_url = base_broker_url + '?client_properties={"connection_name":"' + connection_name + '"}'. If in keda the connections are already done using an url, then it is just changing that part of the code. More changes would be needed if the name is configurable.

[robpickerill]

Does #6093 get somewhere towards this, it is a static name right now, but can easily include a hostname or something relevant.

This is for the AMQP protocol.

[mauvilsa]

I think it would be nicer if the connection name would be the same name of the scaler in kubernetes. But if that is difficult, a fixed name like currently in #6093 is already quite useful.

[JorTurFer]

if the connection name would be the same name of the scaler in kubernetes.

What do you mean? The same as the ScaledObject name?

[mauvilsa]

Yes, I meant the ScaledObject name. Just would be clearer which connection corresponds to what.

[JorTurFer]

It can be a problem because the scaler doesn't have information about the ScaledObject/ScaledJob. Keeping the isolation point aside, you could have multiple ScaledObject/Job with same naming in different namespaces so we should include name-namespace. Is there any max length for the connection name?

[mauvilsa]

I am not aware of a connection name max length.

What information does the scaler have access to? Would the ScaleTargetName be an option? Namespace for sure could be useful.

[mauvilsa]

I tried a name with 147 characters and it still took it complete. If there is a limit, it is relatively high.