You can actually setup delivery monitoring quite quickly by setting up a bunch of paths with the default configuration. But rather than simply taking the fastest route to monitoring, this workflow aims to give you leave you with a deployment that makes sense for your operating environment, and is easy to manage in the long run.

To be successful, you’ll need to have a high-level understanding of your network, and the access required to reconfigure networking equipment and workstations. If that’s not you, then the challenge for this deployment will be more on a communication rather than technical level. You’ll have to coordinate with your network and systems admins, and most likely schedule some of this work.

We strongly recommend that you consider this workflow a rubric for the determining your stakeholders and the planning your deployment, rather than an action list that can be completed in one session.

  1. Prerequisites
  2. Choose your targets
  3. Data or voice?
  4. Is QoS applied?
  5. Asymmetric first mile?
  6. LAN or WAN?
  7. Set up a path
  8. Next steps


  1. Before you set up delivery monitoring, you need to set up a monitoring point.
  2. Turn on email notifications for delivery monitoring events.

Choose your targets

Once you’ve identified which application you want to monitor, this step is about mapping the application to an IP address or hostname. In plain language this means, ‘what is the thing you are trying to reach via the internet?’ If its a web service, either one you build or one you consume, you’ll want to target the webserver. If you’re monitoring voice/video, the best target is an AppNeta monitoring point in the same network segment as the handset or workstation of the person you are trying to contact. Monitoring points as targets yields the most accurate data, plus it’s a requirement for voice tests. If you don’t have an monitoring point deployed in that area, your next best option is the handset or workstation itself, however it’s important understand how these targets impact capacity measurements.

Data or voice?

Setup is the same whether you’re monitoring voice, video, large data transfers, or transactional data, with one exception. To monitor voice quality, you’ll have to know which audio codec your voip deployment is configured to use, so that APM can properly simulate that traffic. In case you’re wondering why codec specification isn’t required for video, this is because even though video data is subject to sampling and compression just like voice, and the same application level protocols are used to transmit that data, the end result amounts to a large data transfer, the type that is addressed natively by APM.

Is QoS applied?

Monitoring the application path is not just about the route that traffic takes, but also the prioritization—or quality of service (QoS)—the traffic receives while in transit. This because your intention should be to use APM to understand the network from the perspective of your application data.

So, before you make a path you’ll want to know whether QoS is applied within your AD. If it is, you’ll specify that in the path configuration, and choose an alert profile with a QoS condition so that you can verify that the QoS you intended isn’t being changed en route.

Asymmetric first mile?

The first mile—or last mile, depending on your perspective—is the link that connects the customer’s LAN to the access layer of the ISP. In many cases it’s asymmetric and therefore likely the bottleneck.

We recommend that any path that includes this link be a dual-ended path. Even if you know that the is link provisioned equally for upload and download, make at least one of your paths dual-ended—perhaps to a AppNeta WAN target—so that you can verify that this is the really what your applications and end users are experiencing.

If you know the link to be asymmetric, you should definitely make the path dual-ended because when a single-ended path is used in this this scenario, all of your capacity measurements will reflect the slower of the two directions.


APM differentiates LAN from WAN according to these definitions. But, for ease of use, you can set all of your paths to LAN. APM performs a nightly check, and any paths designated as LAN are changed to WAN if it meets the WAN criteria, and your application license counts are adjusted accordingly.

It’s important to note that the reverse is not true. WAN paths are never changed to LAN even if LAN is the appropriate designation or a transient condition flipped LAN to WAN. Keep in mind that you might run out of licenses if many paths change from LAN to WAN overnight.

Set up a path

The path setup wizard is recommended way to set up a path. You can configure one or more paths at a time, target any reachable IP address world-wide including other monitoring points, and it makes all path attributes available for customization.

Set up a path now…

Next steps

APM returns monitoring results on the path performance page. You’ll likely want to start by examining capacity measurements.
APM runs a diagnostic on every path upon creation. You’ll find a link to it in the right-side panel of the path performance or path list page.
Delivery alerts
Describe what poor performance looks like in terms of path metrics like capacity and loss, or changes in connectivity and qos, so that APM can take appropriate action.
Path management
APM gives you tools to help keep your organization tidy as your path list grows.
Path Plus
A collection of basic network investigation tools, e.g., ping, traceroute, and nslookup, plus a stress testing tool called PathTest.
A toolset specifically for ensuring good voice quality.
A tool for testing video conferencing quality.
Assess the health of an entire network, rather than just a single path. It rates on a proprietary readiness scale how paths would perform if they were loaded with user-generated application data.