Obkio Network Monitoring App Tour

Obkio’s Network Monitoring SaaS app was born from a need within the industry to simplify network performance monitoring for modern, decentralized networks. What are some of Obkio’s features, and how can you use Obkio to troubleshoot network problems? We’re showing you how in this network monitoring app tour - told through screenshots.

Obkio Network Performance Monitoring software is a simple Network Monitoring and Troubleshooting SaaS solution designed to monitor end-to-end network performance from the end user perspective, and to fulfil the need within the industry for a solution that simplified Performance Monitoring.

Obkio leverages Network Monitoring Agents and synthetic traffic to continuously identify the causes of intermittent VoIP, video, and applications slowdown in seconds - and collect the data you need to troubleshoot and ultimately improve the end-user experience.

Learn more about Obkio’s features.

To make this app tour as fun as easy to understand as possible, we’ll be using screenshots to tell a story.

The story is a use case for network troubleshooting, using Obkio’s network monitoring app and features. This story features a fictional Network Admin and company trying to troubleshoot a network problem related to VoIP in their branch office.

P.S. You can always book a demo with our team for a real-time app tour!

It’s 7:00 AM on a weekday.

A Network Admin, let’s call her Alice, is contacted by her company’s support team because users from the company’s Branch 50 have been complaining about network performance issues related to voice and video calls since that morning.

To get a better picture of what’s going on, Alice connects to Obkio’s Network Monitoring Web Application and lands on the Homepage.

This is what she sees:

The home page displays Obkio’s Chord Diagram, which showcases the live performance of all the branches where Obkio Monitoring Agents have been deployed.

Monitoring Agents are probes that can be deployed in all network locations to monitor network performance using synthetic traffic.

Looking at the Chord Diagram, Alice notices that the performance at Branch 50 is being affected.

She selects the Branch 50 Monitoring Agent to focus only on this Monitoring Agent and see the related Monitoring Sessions.

The red status on both monitoring sessions indicates a performance issue on the UDP packets generated and exchanged between the Monitoring Agents to measure the network performance.

A problem is definitely happening at this branch location!

To drill-down even further in Obkio’s Network Monitoring app, Alice selects the monitoring session between the Branch 50 and Data Center Agents and is brought to the Network Session Page.

This page shows mainly two graphs: Network Response Time and the VoIP Quality for the past 10 hours.

• The Network Response Time Graph shows raw network metrics like Packet Loss (via the yellow and red columns in the graph), Latency (via the solid blue line) and Jitter (via the different shades of blue around the solid blue line).

• The VoIP Quality Graph uses the metrics of the Network Response Time graph to measure MoS and provide visibility on the call quality for users located in Branch 50.

The graph shows two episodes of significant packet loss. One from around 23:00 to 2:00 and another that started around 6:00 and is still going on.

Back on the app’s Home Page, Alice creates a Dynamic Dashboard from the Data Center point of view.

By comparing the information, Alice notices that only Branch 50 is experiencing over 11% packet loss.

The other locations don’t follow this pattern, which confirms that the issue is not on the Data Center side.

Alice goes back again to the home page, but this time, she builds a Dynamic Dashboard from Branch 50’s perspective.

The network monitoring graph between Branch 50 and the Data Center shows 11% packet loss, and the graph from Branch 50 to the Microsoft Azure Public Monitoring Agent (provided by Obkio and reachable via Internet) shows the same thing.

Since the same pattern is happening on both monitoring sessions, the performance issue is clearly located on Branch 50’s end.

Now that she knows that the network problem is happening with Branch 50, Alice selects the predefined dashboard she built before the incident specifically for Branch 50, which shows the branch’s network health at a glance.

The dashboard includes the network performance graphs towards the Data Center and Microsoft Azure Agents, as well as the related VoIP Quality and Packet Loss graphs to these destinations.

The graphs on the last column in the dashboard catch her eye. The graphs provide data from SNMP polling, done from the Branch 50 Agent to the Branch 50 SD-WAN Firewall showing CPU and bandwidth usage on both WAN ports.

An increase in bandwidth usage on WAN port 1 and high CPU usage is happening simultaneously with each packet loss test.

P.S. Monitoring network equipment and devices is done using Obkio’s Network Device Monitoring feature.

Alice concludes the Firewall is not able to properly digest the amount of traffic and is missing CPU, thus dropping a lot of packets.

She logs into the Firewall and finds a source IP using a significant amount of bandwidth to perform file transferring.

She applies a rate limiting rule for file transfers, thus significantly reducing the bandwidth and CPU usage of the Firewall, solving the issue for now.

After solving the issue, she continues to review the data collected from the application. At this point, it’s time for some serious network troubleshooting, so she decides to use Obkio Vision, Obkio’s advanced Visual Traceroute tool.

She creates a Network Map and runs Traceroutes for the Branch 50 Agent.

By looking at the Network Map and Traceroute results, the network admins confirm that the packet loss was starting right from the SD-WAN Firewall.

It is also clear from the traceroutes that the Firewall is also replying to the ICMP packets with significant high latency and jitter compared to the other hops along the way.

She confirms that something is wrong with the network equipment from this point of view.

Alice then goes to the configurations for Obkio’s Network Monitoring app and looks at the Network Monitoring Thresholds used for raising alerts for network issues.

The sessions are configured to trigger a warning issue for over 2% packet loss and an error issue for over 5% packet loss, corresponding to the yellow and red columns seen in the previous graphs.

There are also latency and jitter thresholds in place to raise issues regarding these metrics.

Alice wonders if she was notified of the network issue. She looks at her inbox and confirms she received an email notification highlighting the packet loss on both sessions when the first episode started around 23:00.

Now that you’ve had a sneak peak of Obkio’s Network Monitoring App including features, and how to identify and troubleshoot network problems, it’s time to start for real.

With the rise of SD-WAN and Cloud infrastructures, our reliance on a high functioning network is more important than ever. Network Monitoring helps you ensure that your network is performing at its best.