MSMQ Monitoring

[Phil Sandler]

All,

We are currently use MSMQ as our transport for NServiceBus across the enterprise.  While ServiceControl/Pulse serves the need for monitoring delivered messages, we occasionally have issues with MSMQ itself.  From my experience, MSMQ is 100% reliable as long as the queues (including error/audit/journal/dead letter) are kept "clean".  If too many messages are left to linger in unattended queues, we tend to start having problems with messages not getting delivered, I believe as a result of messages not being deliverable from the outgoing queues on the sending machine (although it's hard to say with any certainty, given the limited MSMQ tooling).

I'd like to get the community's feedback on any specific tools you've used to help administer, troubleshoot and monitor MSMQ across a large(-ish) number of servers.

I'm generally familiar with SCOM, and our ops team is as well, but I'd like to give the ops team specific types of issues to monitor for.  Also would be interested if anyone has used other 3rd party monitoring tools for MSMQ with success.

Thanks,

Phil

[Indu Alagarsamy @ Particular.net]

Hi Phil,

I have used Cogin's QueueExplorer (http://cogin.com) in the past to view the queues and messages across several servers and found the tool generally helpful. It has a much better user interface than the windows current UI for viewing and managing queues!

While I have used their QueueExplorer tool, I have not used their QueueMonitor, therefore I can't say one way or the other how that works. 

If you have a general monitoring solution already in place, you can set up alerts based on the performance counters, especially the transactional dead letter queues. 

As you're probably already aware, when you purge messages in other transactional queues, if the dead-letter attribute is set on those messages, then those messages will go to the transactional DLQ and you will have to purge messages from there as well. 

You normally shouldn't have Journaling turned on in the queues, unless you're in the middle of debugging an issue, as Journaling can quickly fill up your queues and the MSMQ limit. 

Depending on the message volume you're dealing with with you can also increase the MSMQ storage limit from the default 1GB limit to something higher. 

More details, see: https://docs.particular.net/nservicebus/msmq/troubleshooting#messagequeueexception-insufficient-resources-to-perform-operation-resolution

Hope this helps,

Cheers,

Indu Alagarsamy

Particular Software

[Victor Chircu]

Hi Phil,

I've also looked into monitoring MSMQ. I've put my findings in this blog post: http://www.simpleorientedarchitecture.com/msmq-administration/. I think performance counters surfaced through SCOM is a good option. 

Most of the problems that I've encountered were caused either by MSMQ running out of space or DTC.

Victor