After spending way to much time trying to get the queuesizes via the message queuing service (which in turn uses a messagecount.exe utility found in the sensor system sub directory of the prtg install location) I finally gave up.
Situation:
Forest with 2 domain. PRTG running in domain A, wants to check queue on server in domain B. due to some rights reason I simply cannot access the queue information even though the credentials should work. Long story short, it's a hassle.
During my testing I finally dove in and tried to see what the message count utility does...
To my surprise (which later on I should have figured out earlier) the messagecount util does the following:
it gets all the messages from the queue you try to count, keeps them in memory (nice if you have < 1000 messages in queue.. not so nice when you have 100000 or more in the queue...) and does a count. Obviously, all these messages traverse the network. Checking a queue with 100k messages therefor takes a long time. :(
So in the end, I gave up, wrote a custom wmi query (since the application belonging to the queue does write this info to performance counters) and now the size of the queue is not relevant any more. The only hassle is creating all the custom WMI queries. But(at least in v9) the wmi queries can have place holders.
So what have I learned from fiddling with prtg and message queuing:
If the message count util works for you, and your queues usually have less than say 10k messages in them, use it. Else, pray and hope the application that uses the queue you are trying to monitor also has performance counters with the same information :)
Add comment