
I've found over time, that regardless of SCOM or other active monitoring in place for your Exchange infrastructure, you can often see problems show up early and first in queuing behavior on your HubTransport servers:
- Experiencing mail server storage latency issues? You'll probably see increasing patterns of queuing in the MapiDelivery queues to the problem stores, as you move into peak business primetime hours and increasing mail load delivers into the hubs, but can't be delivered into the mailbox server transaction logs and stores, fast enough to keep pace with the mail flow.
- Experiencing cpu-saturation, or other capacity issues on your hubs, or Hub-CAS hybrid systems? You'll probably see the footprint on the CPU-dependant AV-scanning processes (you ARE running antivirus scanning on your hubs, correct? :D), which will lead to mail queuing in the Submissions queues.
--in my case, I most recently saw this as a product of CAS Exchange Web Services load -- from Lync -- soaking up more CPU than the systems had been provisioned for, in 2007, well before the Lync infrastructure had been tacked onto the Exchange infrastructure -- looong story behind that one, that predated my arrival at the firm. :P))
So in a nutshell, I've found it a pretty good backup-monitoring option, to run a self-refreshing console display on the current queue status of all hubs in a given Exchange revision.