This is an issue I've had customers struggle with over the years as well. I would actually always suggest working with TAC on this one rather than just monitoring and alerting on it. Many of the past issues I've run in to with this revolve around tuning and cleaning up the deployment, but these have also been large customers. Some examples of this could be aggressive snmp query timers generating heavy profiling traffic, or misbehaving endpoints/nads. Since it sounds like this deployment might not be under much load right now these are of particular concern, adding load won't make it any better, and tuning is typically a solution when it creeps up later in a deployments expansion.
From an alerting stand point it's certainly good to know when it's happening, but there is usually little resolution other than resyncing a node or waiting for replication traffic to drop. Finding a long term solution is high on the list. The three alarms for replication issues, "slow replication info, warning, then error are cascading based on the severity of the situation. They can be configured for email alerting, or flagged in an external syslog such as splunk. If the replication backlog hits 1,000,000 messages, the node will be disconnected and require a manual resync.
As a side note, it might also be worth exploring the possibility of moving the primary PAN/MNTs to London. While it could certainly be a lift and bunch of work, it's entirely possible that the RTT of London <>Singapore could be up to 100 ms less than Chicago <> Singapore. A lot of this depends on the customers providers, but I've seen some environments where this would be ideal. London to Chicago is relatively low latency in this context, so worth looking in to. In some older Cisco on Cisco sessions from Cisco Live, they actually had a very similar situation with the Cisco internal ISE deployment.
