Active network monitoring (a network monitoring technique) is real-time testing, performed by software agents or hardware sensors, on network infrastructure and against applications to verify that the network (or applications) are available and performing well. Active tests report real-time data such as end-to-end reachability, packet loss, jitter, bandwidth, and HTTP response time. One of the most common tests run by active network monitoring tools is the ping command, which verifies round trip time to a remote host as well as packet loss.
$ ping www.google.com PING www.google.com (18.104.22.168): 56 data bytes 64 bytes from 22.214.171.124: icmp_seq=0 ttl=46 time=69.206 ms 64 bytes from 126.96.36.199: icmp_seq=1 ttl=46 time=208.630 ms 64 bytes from 188.8.131.52: icmp_seq=2 ttl=46 time=62.758 ms 64 bytes from 184.108.40.206: icmp_seq=3 ttl=46 time=307.980 ms 64 bytes from 220.127.116.11: icmp_seq=4 ttl=46 time=112.118 ms --- www.google.com ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 62.758/152.138/307.980/93.751 ms $
Benefits of Active Network Monitoring
One of the benefits of this technique is that it reports real-time information on network availability and performance. In a previous blog post, I covered the Cisco IP SLA network performance monitoring suite. If you are a network engineer familiar with this technology, you may find active network monitoring to be very similar. In fact, as stated in the Cisco IP SLA Configuration Guide, “IP SLAs uses active traffic monitoring—the generation of traffic in a continuous, reliable, and predictable manner—for measuring network performance”.
Active network monitoring is indeed very effective for quickly detecting network and application problems; it tests the actual network routes and applications with real traffic (instead of monitoring individual devices in a network, or components of an application) to infer network and application availability and performance for the end-users based on their overall status. This is one of the reasons why NetBeez is primarily based on active tests: to quickly detect network problems before the users detect them.
Screenshot of the NetBeez dashboard of a ping test to www.google.com run by a Ethernet active monitoring sensors.
Test Interval and Detection Time
Based on the frequency of the network and application tests, the network manager can decide how quickly a problem needs to be detected. For example, the table below shows that if we run a ping test every five seconds, and declare a remote network unreachable after five consecutive tests fail, we’ll have detected connectivity issues within twenty-five seconds. That’s a very short detection time when compared to the five-minute interval that most SNMP systems are configured by default.
|Test||Primary Metric(s)||Test interval*||Detection time*|
|PING||RTT, Packet loss||5 seconds||25 seconds|
|DNS||DNS lookup time||30 seconds||2 minutes 30 seconds|
|HTTP||HTTP GET time||60 seconds||5 minutes|
|Traceroute||Hop count, RTT, MTU||120 seconds||n/a|
|VoIP||Jitter, packet loss, MOS||User-defined||n/a|
The above table reports only some of the tests that can be run via an active network monitoring tool.
To conclude, network engineers and administrators that are interested in proactively detecting network and application problems on large, complex enterprise networks, should implement active monitoring against web and cloud applications.