Internal events: consider adding a new field, the associated client connection's IP address

[defesteban]

Is your feature request related to a problem? Please describe.

We have a problem with detecting the microservice that deletes queues, exchanges, etc. in RabbitMQ. The events from Event Exchange Plugin contain information about user that performed the action, but we need to find out the microservice IP address, because it uses the main RabbitMQ credentials for its actions.
Now in the event we can see only the following information:

Exchange	amq.rabbitmq.event
Routing Key	exchange.deleted
Redelivered	○
Properties	
    timestamp:		1685615384
    delivery_mode:	2
    headers:	
        name:				test
        timestamp_in_ms:		1685615384798
        user_who_performed_action:	user
        vhost:				/
        x-delivery-count:		0

Describe the solution you'd like

The Event Exchange Plugin events contain IP address of the one who performed the action.

Describe alternatives you've considered

No response

Additional context

No response

[michaelklishin]

This is exactly why client-provided connection names were introduced several years ago.

Not all internal events have enough context to access to the client connection, leave alone its socket details. If something
like that were to be added, I think it should be the client-provided connection name and not the IP address.

[michaelklishin]

Or you can use separate users for separate services. "User that performed the action" is also available for most if not all events, and it has been the case for years. In fact, you have it listed in the example event.

[michaelklishin]

Two more arguments against this feature:

• Client IP addresses are dynamic and can be completely useless in certain environments. Apps running in Kubernetes pods behind a load balancer of some kind would be one example. A set of instances in an autoscaling group would be another
• Without a Proxy Protocol-enabled proxy, IP addresses exposed in internal events will be useless if clients connect using any kind of intermediary (a proxy, load balancer, et cetera; external or internal to the platform)