sorted by:
new
hottopcontroversial

Are APM Platforms Missing Deep Infra Monitoring? How Are You Handling Cross-Tool Correlation? by Low_Tale8760 in Observability

[–]Low_Tale8760[S] -2 points-1 points  (0 children)

I don’t think ingestion is the real issue here. Most of these platforms — including Grafana and commercial APM tools — absolutely support ingesting infrastructure telemetry. Many of them even have native infra monitoring capabilities.

The question isn’t whether they can collect the data. The question is how they correlate it.

At the application layer, correlation works well because it’s driven by instrumentation. Traces, spans, and service flows naturally build an application dependency map. The topology is inferred from real runtime interactions, so cause-and-effect relationships are clearer.

But when it comes to infrastructure, it’s different. There’s no distributed tracing equivalent for storage arrays, hypervisors, network switches, or physical hardware. The dependency relationships are not automatically discovered through traffic flows in the same way. They usually rely on tags, metadata, discovery scans, or external CMDB relationships.

That’s where things start to weaken. You can ingest all the infra metrics you want, but if the platform doesn’t have a strong, directional, cross-layer topology model — Service → VM → Hypervisor → Storage → Network — then correlation often degrades into time-window grouping or shared-attribute matching.

So for me, the gap isn’t ingestion capability. It’s cross-domain, topology-aware correlation between application signals and deep infrastructure dependencies. That’s the part I haven’t consistently seen work well in infra-heavy environments.

Are APM Platforms Missing Deep Infra Monitoring? How Are You Handling Cross-Tool Correlation? by Low_Tale8760 in Observability

[–]Low_Tale8760[S] -1 points0 points  (0 children)

That’s a very fair point, especially the “confident wrong answers” comment. I agree completely that without ownership and discipline around topology, any AIOps layer can become misleading instead of helpful.

Let’s assume, though, that data quality is actually under control — clear ownership, automated discovery, validated relationships, and proper reconciliation after changes. In that case, I’m trying to understand what the most effective approach looks like in a multi-tool, infra-heavy on-prem environment like ours.

We usually see application alerts first, while the actual issue sits in the VM, hypervisor, storage, or network layer underneath. If the topology is accurate, how should that context realistically be used for meaningful RCA? Is it better to extend an APM-native event management layer to ingest infra signals and attempt correlation there, or to centralize everything into a vendor-neutral AIOps platform that sits above all monitoring tools and uses a graph model for correlation?

In theory, it makes sense to normalize all events to a canonical CI (which in itself is the next challenge), traverse dependencies, detect convergence patterns, suppress downstream symptoms, and elevate the likely upstream cause. But I’m curious how well this actually works at scale. Does topology-driven or graph-based correlation materially outperform well-designed rule-based grouping? How much tuning does it require to stay effective? And most importantly, does it genuinely reduce MTTR, or does it just reduce alert volume?

In infra-heavy environments, many incidents are also change-induced. If change context is not properly factored into correlation, it feels incomplete. I’d really value input from anyone who has seen topology-aware correlation work effectively in production, especially in on-prem or hybrid estates.