This is the reality of the market in 2025-2026 : despite the marketing promises, no single tool satisfactorily covers the entire spectrum, from the lowest-level network monitoring to the most fine-grained application tracing.
Understanding this fragmentation is essential before choosing any solution. Here is why each family of tools has its own blind spots.
Monitoring tools are evolving… but remain limited
Infrastructure tool vendors are making considerable efforts to add observability capabilities : better log management, integrations with trace sources, richer dashboards. These improvements are real and useful.
However, these tools remain fundamentally designed for infrastructure monitoring. Their data model, their architecture, and their agents are optimized to poll devices via SNMP, WMI, or specific sensors. They are not natively suited to the paradigms of application observability : OpenTelemetry instrumentation, high cardinality, distributed tracing.
Observability platforms don’t replace monitoring
Conversely, observability platforms excel at processing application metrics, structured logs, and distributed traces. But they are not designed to replace an infrastructure monitoring tool :
- Automatic discovery of network devices (switches, routers, firewalls)
- Fine-grained SNMP monitoring with thousands of preconfigured sensors
- Mapping and dependencies of physical infrastructure
- SLA management and reporting for network teams
The “all-in-one” trap
Some SaaS solutions (Datadog, New Relic, Dynatrace) promise to cover everything. While these platforms are powerful, they raise other questions :
- Cost : pricing based on the volume of data ingested, potentially very high at scale. At 500 GB/day of logs and metrics, the bills can quickly reach tens of thousands of dollars per month.
- Vendor lock-in : dependence on a proprietary ecosystem that complicates any future change. Switching vendors means re-instrumenting, re-training, and re-budgeting.
- Data sovereignty : outsourcing all of your telemetry to a third-party cloud, most often a U.S. one. For regulated IT environments (ANSSI, HDS, NIS2), this is a deal-breaker.
- Actual coverage : insufficient coverage of low-level network and on-premise storage monitoring. “All-in-one” is often “all-for-the-public-cloud.”
The critical challenge of data volume
When we talk about observability, we are talking about data volumes that are on an entirely different scale from traditional monitoring. A classic monitoring tool collects a few thousand metrics at spaced-out intervals. An observability stack continuously ingests millions of time series, log streams from every application component, and traces covering every request.
At the scale of a mid-sized infrastructure, volumes quickly run into the hundreds of gigabytes. For larger environments—microservices, Kubernetes, multi-cloud—you easily reach the terabyte mark, or even tens of terabytes over retention periods of just a few months.
The choice of an observability backend cannot be based on features alone : storage efficiency is a strategic criterion that determines the economic viability of the project.
How should the tools fit together?
Rather than searching for a single tool, we advocate a so-called “two-headed” approach—two complementary pillars, each optimized for its own scope, interconnected through open standards. That is the subject of our next article.
This article is drawn from our white paper “From Monitoring to Observability” (PDF, 2026).
