/SERVICES

The problem is rarely a lack of data. Most organisations monitor their network, their servers and their applications quite well. The problem is that this data lives in separate tools, with separate timelines and separate alerting. Nobody sees the whole chain, from the network link to the user who is waiting, in one place.

In this post we take that meeting as our starting point, rebuild it in our lab with IBM Instana, and show what it takes to answer the question in minutes instead of in a meeting, and what that means for the business.

This is the second post in our observability series. In the first one, Stop Guessing Thresholds, we looked at how Smart Alerts with adaptive thresholds cut down false positives. Here we look at what happens after an alert fires: finding the cause.

What slow answers really cost

An unclear root cause is not just an annoyance for IT. The outage lasts longer, because every minute spent deciding whose problem it is, is a minute the application stays slow for customers or colleagues. It burns expensive people: five engineers in a call for an hour is five hours of senior time, and it happens again with the next incident. And it damages trust. When teams or suppliers keep pointing at each other, management loses confidence in IT. In a managed services relationship, not being able to show who owns a problem is one of the fastest ways to sour a contract.

Why separate tools lead to slow answers

A typical setup looks like this. PRTG, or a similar tool, watches ping times, packet loss and interface traffic. An APM or infrastructure tool watches hosts and services. Each tool raises its own alerts, and each alert lands in its own channel.

When something breaks, someone has to line up the timestamps by hand. Did the latency spike start before or after users started to complain? Was the application slow because of the network, or was the network busy because of a backup? That manual correlation is where most of the time to resolution goes.

There is a second blind spot. Server-side monitoring measures how fast the application answers once a request arrives. It does not see the time a request spends on the way there. When the network is the problem, the APM dashboard can stay green while users wait.

Keep your network monitoring, connect it

The fix is not to replace your network monitoring. It is to bring its signals into the same place as your application data, next to a measurement of what the user actually gets. We use PRTG as the example, because it is what we see most often at customers, but the approach is the same for Zabbix, Checkmk or any tool that exposes its data through an API. Three kinds of signals come together in Instana.

• Network metrics are exposed in Prometheus format and picked up by the Prometheus sensor of the Instana host agent. They show up as custom metrics on the host, next to CPU, memory and the processes running there.
• Network events are sent to the local REST API of the host agent when a threshold is crossed. Because the event goes through the agent on that host, Instana knows which entity it belongs to.
• The user view comes from an Instana synthetic test. A point of presence calls the application every minute, the way a user would, and records how long the answer takes. The point of presence can be hosted by IBM or run in your own environment.

An example from our lab

In our lab, a small web application runs behind a firewall on a host with the Instana agent. A script plays the role of PRTG: every 30 seconds it measures latency, jitter and packet loss to the gateway and two public endpoints, and raises an event at 40 ms (warning) and 100 ms (critical). A synthetic test calls the application every minute from a point of presence on the other side of the WAN link. Normally the user gets an answer in about 40 ms.

Then we degraded the WAN link: 150 ms of extra delay and 3 % packet loss, for about twelve minutes. This is what Instana showed.

The user view: the synthetic test in IBM Instana. Response times climb to between 500 and 880 ms, and the network timings show the time is spent waiting.

The server view of the same period: the application reports "No issues" and a mean latency of 3 ms.

The network events on the host: critical latency to the gateway and the public endpoints, and the recovery when the link was restored.

The order of events tells the story. In one of our runs, the network probe raised a critical event 24 seconds after the link was degraded. Less than two minutes later, the Smart Alert on the synthetic test fired because users were getting slow responses. All that time, the application itself kept answering in a few milliseconds. Three views, one time axis, and the conclusion is clear within minutes: the application is fine, the network is not, and the network team can start working on it right away.

One view, one timeline, no guessing.

What Instana correlates today, and what it does not

We want to be precise here, because this is where marketing and reality often drift apart.

• When a service slows down on a host where a network event is active, Instana uses its Dynamic Graph, the live model of how hosts, processes, services and calls are connected, to group the events into one incident. Its probable root cause analysis, currently in public preview, works on incidents raised by application, service, endpoint and SLO Smart Alerts.
• When only the user feels it, as in our lab, the server-side metrics stay flat and no service incident is created. The synthetic alert and the network events are separate events. Instana puts them on the same timeline, but it does not merge them into one incident on its own.
• The Instana AI assistant (preview - 11/2026) can help connect the dots. When we asked it about the synthetic failures with the right time window, it pointed to the network events as the root cause. Its explanation was not entirely correct, so we see it as a helpful second opinion, not as the answer.

That is still a big step forward from three tools and a meeting room. And it shows why the user view matters: without the synthetic test, this incident would have looked like nothing at all on the application side.

Measure what your users feel

The most useful lesson from the lab is not about the network. It is about where you measure. A server that answers in 3 ms means nothing to a user who waits 800 ms. Synthetic tests measure the full trip, including the parts you do not own: the WAN link, the internet provider, the firewall. Put a test on the transactions that matter most, attach it to the application in Instana, and you see user impact even when every server looks healthy.

That changes the conversation. Instead of "all our dashboards are green", the team can say "users are waiting, and here is where the time goes".

What it brings to the business

• Shorter incidents. The time spent working out where the problem sits shrinks, because the timeline already shows it.
• Fewer war rooms. Only the team that owns the cause gets involved. Everyone else keeps working on what they were doing.
• Facts instead of opinions. When an internet provider or hosting partner is involved, you go into the discussion with timestamps and measurements, which makes it far easier to hold them to the SLA you pay for.
• No rip and replace. The network team keeps PRTG and the way they work. You protect what you already invested in and add value on top.
• Honest reporting. You report on what users experienced, not only on what servers did, which is what management and customers want to see.

How to get started

1. Decide which network signals matter for your applications: usually latency, packet loss and the status of key links.
2. Expose them through a Prometheus endpoint, or a small script that reads them from your existing tool.
3. Configure the Instana agent to collect those metrics and send events on the hosts they belong to.
4. Add a synthetic test for your most important user transactions, from a location that sits where your users are.
5. Put a Smart Alert on the synthetic test and on the network latency, and check the timeline the next time something slows down. Network latency has a daily rhythm too, so an adaptive threshold works well here. We explain how in Stop Guessing Thresholds.

Key Takeaways

• Slow troubleshooting usually comes from separate tools, not from missing data.
• Network metrics and events from PRTG or similar tools can be brought into Instana through the Prometheus sensor and the host agent API, without replacing anything.
• Server-side monitoring cannot see network delay. A synthetic test shows what users actually get.
• With network, server and user view on one timeline, the cause is clear within minutes, even when Instana does not merge everything into one incident.
• The result is shorter incidents, fewer people pulled in, and facts to hold suppliers to their SLA.

Read more in this series

• Stop Guessing Thresholds: How Dynamic Thresholds in IBM Instana Make Application Alerting Smarter: fewer false positives with Smart Alerts that learn what normal looks like.
• How Phronesys scaled to 350+ tenants on AWS with IBM Instana at the center: how one of our customers uses Instana in production.

Let's talk!

At NubeX we help teams connect their existing monitoring to IBM Instana, so every incident gets a clear owner and a faster fix. Want to see the lab scenario live, or what this means for your own environment and tools? Let’s talk, or book a demo.

/INSIGHTS

Your trusted partner for Cloud Neutral Platform Managed Services