Around the World in 80ms: Alerting by Geography, Network and Device

Posted by on August 17th, 2015
January 9th, 2017

Over the past few months we’ve introduced some great improvements for alerting on your network performance. If you’re not already familiar with alerts in ThousandEyes, check out our post on Alerting on Network Performance, as well as how to set up alerts for BGP routing and DNS. Today we’ll cover two related features: geographic-based alerts and Path Trace alerts.

Varying Latency Thresholds by Geography

Frequently you’ll want to alert and report on the speed of a service. This may be measured as latency, response time, page load time, transaction time or a number of other metrics. But latency often varies greatly by the region that you monitor from. Within the United States latency may be less than 60ms but from Africa or Australia back to the U.S. latency may be 200ms or more. And this variation in latency will mean ever greater disparities for response, page load and transaction times.

We’ve introduced the ability to tie alert conditions to specific agents or groups of agents, such as geographic regions. Easily define a group of agents for China, as an example, and customize alert thresholds for just those monitoring points. Then clone that alert, assign it to Africa, and adjust the expected latency (or loss, error, etc.) threshold. You’ll no longer need to create separate tests for different regions; now just customize the alerts.

Figure 1
Figure 1: A packet loss alert that is constrained only to monitoring points in China.

Monitor GSLB and DNS-based Load Balancing

The same alert geo-fencing can be used to understand the service endpoints as well. Say you use a CDN or multiple CDNs. Or that you have multiple data centers around the world. And that each location is meant to service a specific geographic market. You can use geographic-based alerts to match the destination IP address range, hostname or AS name to the appropriate geographic region. For example, users in China are served from Hong Kong; users in Europe from Amsterdam; and any deviation from this is likely a DNS or routing issue. This can be quite powerful to quickly detect suboptimal traffic paths.

Figure 2
Figure 2: In this alert, 52 European monitoring points should always be served by ServiceNow’s Amsterdam data center.

Set Alerts by Network Segment and Device

Another recent feature addition is Path Trace alerts, which make it possible to alert on data that you see in a Path Visualization. For example, you can alert on delay for paths that traverse specific networks or through a set of devices. Here are four interesting scenarios you can capture with Path Trace alerts.

Within External Providers

Utilizing Path Trace alert logic you can alert on external providers such as CDNs, ISPs, DNS or hosting firms. You’ll most likely want to use AS numbers to specify the provider network, though with CDNs using the hostname may work better as the edge locations can often be in a variety of networks. Set your delay threshold and constrain the geographic region, if relevant.

Figure 3
Figure 3: An alert that triggers when delay in the Akamai network is high.

Backup Paths

You can not only track delay, but also understand whether traffic is being routed through certain networks. This can be handy to detect a failover route to your backup ISP or DDoS mitigation provider. Select ‘Any Hop’ to detect a change anywhere in the path, or input a ‘Hop #’ to narrow it down to a specific portion of the path. Then specify an IP address range (, hostname wildcard (* or AS name (3356).

Figure 4
Figure 4: This condition triggers when the upstream provider, 3 hops from the destination, is not in Level 3 (AS 3356 or AS 3349).

Specific Devices

Similar to how you can narrow an alert to only paths that flow through a certain network segment, you can also do it for a specific device. Just specify the IP address range ( or hostname wildcard (* and the delay metric.

Figure 5
Figure 5: Use rDNS or IP addresses to specify performance for paths that travel through a particular device.

QoS Markings and Path MTU

You can detect deviations from expected DSCP code, Path MTU or TCP MSS values throughout the traffic path. This can be particularly valuable for alerting on VoIP circuits or for protocols with non-standard segment sizes.

Figure 6
Figure 6: An alert for VoIP circuits that triggers if any hop does not maintain the Expedited Forwarding DSCP code.

With these geographic and Path Trace alerts you should be able to reduce false positives while tuning your notifications to provide you even more valuable information. You can put all of these tips into practice right now with your existing tests; learn more about alerts in the Customer Success Center, the recorded webinar on Alerting in ThousandEyes or the 5-minute video tutorial. If you don’t yet have a ThousandEyes account, sign up for free and begin monitoring your network.