@MichaelSleeuwagen you have a number of options there.
Option one has been mentioned by @ramonsmits . In this scenario you have ServiceControl main instance and ServiceControl audit instance for each VHost but you can have a single ServicePulse hosted in IIS that can connect to any SC instance. The downside of this approach is that you won’t be able to see all the failed messages at once.
Another option is to use the ServiceControl Transport Adapter and a single instance of ServiceControl running on a dedicated VHost. You need one adapter per endpoint’s VHost but you can host all these adapters in a single console app or windows service. The downside of this approach is that each audit message is going to require two “hops” to reach service control.
Yet another option is to have the setup with SC instances per VHost but add one additional instance that aggregates all data from all instances but does not process any messages. Such an instance would allow you to see all messages in ServiceInsight in a single view, but would not help with ServicePulse – you would still have to switch the SP between SC instances to see failed messages.
So to summarize, if you care a lot about being able to manage failed messages in a single place, use the transport adapter approach. If you are concerned about throughput, use SC-per-VHost. Given that RabbitMQ is a very efficient transport, I would suggest trying the transport adapter option first (if you were on the SQL Server transport I would suggest the SC-per-database).