Working with ServicePulse

Over the past year I’ve had the enjoyment of working with an established system built on NServiceBus and MSMQ. If you’ve had to investigate an issue in this scenario, you’ve gone through the exercise of combing through logs and failed messages; which can get a bit tedious at times. With recent updates from Particular, it probably won’t be so painful anymore.

Enter ServicePulse

Particular has expanded on NSerivceBus with a new tier of offerings. Through the graduation of pricing levels, you gain additional tooling to make your life a lot easier. Starting at the Advanced level you gain access to ServicePulse.


Another improvement that you experience right away is the new installer. In the same nature as the Web Platform Installer you get a nice bootstrapper for everything you want (need).

Oh yea and that includes Chocolatey too! <p align="center"> </p>

An important note is that if you want ServicePulse, you need ServiceControl too. Once you have everything installed, you’ll see a couple new services running. <p align="center"> </p>

Both of these are installed into the directory: C:\Program Files (x86)\Particular Software

So what's ServiceControl?

Something that has lived in NServiceBus for a while has been the ability to forward copies of messages to a queue for further logging or diagnostics. In NServiceBus this is called Auditing. In the past, if you wanted to do anything with these messages however, you would have needed to write some kind of consumer for them.

With ServiceControl you don’t need this anymore. It will watch both your audit and error queue for messages and process them for you. Where do they get processed to?

RavenDB of course! In fact, it has it’s own embeded version of RavenDB, which you can find here: C:\ProgramData\Particular\ServiceControl <p align="center"> </p> > If you’re collecting audit messages and you have a busy system, you may want to considder configuring it to use a different location - like somwhere with enough space to store them all

There’s a bunch of other configuration changes you can make to ServiceControl.


Now that we know ServiceControl is picking up and processing our error and audit messages, we can jump over to ServicePulse and check them out.

ServicePulse will be running locally at: http://localhost:9090 <p align="center"> </p> The best part of ServicePulse is that it cuts to the chase. No more needing to squint your eyes at the body of MSMQ messages. No more sifting through log files for a stack trace. ServicePulse puts it right into a nice GUI for you and they have some great docs on how to use it.

Monitoring EndPoints

At the time of this post, ServicePulse currently only offers a dashboard to show you Red / Green status for services being up or down. They call this Heartbeats and to enable it, you just need to add a refernce to the Heartbeats package. Doing so will cause your service to periodically ping ServiceControl with a Heartbeat message. This is used to signal the up/down indication in ServicePulse.

Other Considerations

The basic functionality is pretty cool, but likely won’t be enough for serious DevOps. Thankfully, they’ve provided some extensions to help fill these gaps where a one-size solution might not fit all.

ServiceControl API

If you want more access to what’s in ServiceControl, they’ve wrapped it with an API which is what ServicePulse communicates with.
> By default it will be hosted at: http://localhost:33333/api

Clearing out noise from ServicePulse

One scenario I encountered on my testing environment was that ServicePulse filled up with a bunch of failed messages. Unfortunately the UI doesn’t ship with an easy way to solve this yet. The work around I used to clear (reset) my ServicePulse/ServiceControl data was to delete the RavenDB data file (see above). You’ll need to stop ServiceControl to do this. It’s also a pretty drastic measure and you probably shouldn’t do it in a Production environment unless you have no other choice.

ServiceControl data lifetime

By default, the messages in ServiceControls database (what you see in ServicePulse) will live for 30 days. After that, they are purged out and gone forever.

Custom Checks

One of the most interesting features is the ability to write custom checks into your services. You can read more about setting these up - I will be writing a follow up article on this soon.


It’s pretty tempting to open these tools up (they are web-based afterall). But keep in mind that the data oftern available here can make it easy for a would-be attacker to compromise your system.