Use servicecontrol to monitor endpoints using different transports

1

We are in the process of setting up servicecontrol for the 1st time, to monitor our endpoints (starting on DEV, and then the other environments will follow)

We have endpoints using MSMQ, some of these run on the same server, and some on different servers where each server has got 1 error queue for the endpoints it runs
We also are building new endpoints that will use Azure Servicebus as transport as these are running in azure and we don’t want to use MSMQ there

We have these questions:

  1. How should we setup servicecontrol and serviceinsight/servicepulse in such an environment?
    Do we need to install 1 servicecontrol instance per transport type?
    Or can we just install 1 instance to ingest all messages from different transports?
    Because we see that selecting a Transport is part of the installation choices when adding an instance

  2. How should we name the instance(s) and paths to install to?
    We don’t want the servicecontrol files and data on the OS drive, so a D drive is available for installation
    Assuming that we need to install an instance per transport type, I figure adding the transport type somewhere in the instance name and paths is wise
    If 1 instance will do, we stick with the default paths but use the D drive instead

  3. Is it possible to pass different paths to the servicecontrol management program?
    We do not see any options to do that, so the installation of new instances is on the OS drive
    After adding the instance there’s an option to change locations and such, but that feels a bit stupid.
    Alternatively we could try to use the powershell module instead, but we just want to be sure we don’t oversee something in the UI

B.t.w. we downloaded the latest version of all tools yesterday

1 Like
2

How should we setup servicecontrol and serviceinsight/servicepulse in such an environment?

I would recommend the following:

  1. One ServiceControl instance on Azure ServiceBus ingesting the error queue on ASB
  2. ServiceControl Audit instance on Azure ServiceBus ingesting the audit queue on ASB
  3. One audit instance for each MSMQ audit queue
  4. A bridge for each MSMQ error queue to bridge that error queue over to the ASB error queue (see Bridge configuration options • Messaging Bridge • Particular Docs)

In this setup, you will get a 360 view of your system with all errors managed in a single place and all audit messages visualized.

The reason to go with separate audit instances is to avoid having to move all audit messages over the bridge which can become a bottleneck.

How should we name the instance(s) and paths to install to?

Adding the transport name to at least the audit instances seems reasonable. Perhaps also server name for the MSMQ ones.

Is it possible to pass different paths to the servicecontrol management program?

Not via the UI but as you mention this can be scripted via Powershell, see:

Does this make sense?

Cheers,

Andreas

3

Hi Andreas,

Thanks for your reply. We’ll have a go with the suggestions you made.

Regards,
Mike

4

For completeness, another option is to leverage the multi-site deployment option for ServiceControl and configure each “site” for a different transport.

5

Hi Mike,

We’ve now documented this scenario here ServiceControl remote instances • ServiceControl • Particular Docs

Cheers,

Andreas

1 Like
6

We ended up following that setup. The messages in the remote error queues got visible in the central instance. But we were not able to retry them from there.

We decided to leave it for now. ASB setup works, we have other tools for MSMQ error queue management in place.

7

@codefitter, by any chance, do you have an error in the logs that you can share? If you prefer to do that in a private conversation, please drop an email at support@particular.net.