More data alone will not explain an incident (Observability Part 2)

Routers provide performance metrics, security components log events, and the service desk records complaints. Yet investigating a slow cloud application often starts with manually gathering information from different sources. What is missing is the connection between the data already available: which metric relates to which site, access path, and application?

While monitoring reveals technical conditions and trends, observability also requires clear connections between those observations. The key is to establish which operational question the data can answer. That determines which signals are needed and what context they must be linked to.

Which signals answer which questions

Different types of data provide different insights into how a service behaves:

• Metrics describe measurable characteristics such as network utilization, latency, and packet loss. They reveal trends and deviations but cannot explain their causes on their own.
• Logs record individual events, such as a failed access attempt or a security rule being applied. Their value depends on whether the relevant events are actually logged.
• Flow data describes communication patterns and the volumes of data transferred. It helps identify which systems communicate with one another and how traffic changes over time.
• Synthetic tests perform predefined access attempts. They show how a service behaves from a particular measurement point. A test from a data center, however, does not automatically reflect the experience of an employee using the local wireless LAN.

Investigating a slow application may require several of these perspectives. The scope and selection depend on the affected service and the potential causes along the entire network path.

From metrics to context

Consider a branch office where employees report slow response times from a cloud application in the morning. A synthetic test from the site confirms the delay. Network utilization at the site is rising at the same time. The initial suspicion seems reasonable: the site connection is overloaded.

To test this hypothesis, the measurements must align in both time and technical scope. Does the test follow the same network path as the application? Does the utilization figure relate to the link that carries the application traffic? Do the measurements actually cover the same period? Only when these relationships are established can the team assess whether the observations are connected.

Further information may change the direction of the investigation. Flow data could reveal a large data transfer running over the affected link at the same time. Evidence of packet loss would provide further information for assessing the connection. If, however, only employees on the local wireless LAN experience delays while a test over a wired connection shows no issues, the wireless network should also be investigated.

Observability therefore needs a shared context model. It describes how sites, devices, service providers, applications, and network paths relate to one another. Information about security rules and previous changes adds further context. This makes it possible to identify which part of a service a metric or event relates to. Events occurring at the same time provide a starting point for investigation; a cause still needs to be confirmed through further analysis.

Connecting existing systems where it matters

These relationships can also be established across multiple specialized systems. Monitoring systems, security tools, cloud systems, and the service desk can retain their respective functions. To support a shared analysis, the relevant information must be connected through interfaces and mapped consistently.

Before expanding data collection, IT leaders should therefore check whether existing sources are already usable. Are mappings to sites and services up to date? Are timestamps comparable? Is the time resolution sufficient to detect brief periods of degraded performance? Missing or outdated mappings can lead to incorrect conclusions even when large amounts of data are collected.

For a specific service, requirements can be captured in a simple matrix: operational question, required signal, data source, and necessary context. Where this reveals gaps, teams can make a targeted decision about whether they need additional measurements or better connections between existing information. AI-assisted analysis also depends on reliable underlying data and clear, traceable mappings.

Want to assess which data will help you understand your most important services? Our experts can support you evaluate existing sources, identify missing context, and determine which integrations would be useful.


Image: created with AI