Datadog sells instrumentation agents as an "observability platform," Dynatrace positions OneAgent as delivering observability, and New Relic rebranded its APM line as "full-stack observability." All three collapse the distinction that should drive your tooling decisions: telemetry is data your systems emit, and observability is a property of the system itself. Getting the telemetry vs observability distinction right changes how you evaluate every vendor on your shortlist.
Telemetry, monitoring, and observability: what each term means
OpenTelemetry's observability primer defines telemetry as "data emitted from a system and its behavior. The data can come in the form of traces, metrics, and logs." Telemetry is raw material. It exists whether or not anyone queries it, and its quality sets a hard ceiling on everything built above it.
DORA defines monitoring as "tooling or a technical solution that allows teams to watch and understand the state of their systems. Monitoring is based on gathering predefined sets of metrics or logs." You decide in advance what can go wrong, set thresholds, and the system pages you when a service crosses one. Monitoring answers the questions you thought to ask before you deployed.
Observability is a system property. The CNCF TAG Observability whitepaper grounds it in control theory: "observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs." The CNCF Glossary calls it "a system property that defines the degree to which the system can generate actionable insights."
DORA's companion definition sharpens the contrast with monitoring: "Observability is based on exploring properties and patterns not defined in advance." You can buy telemetry pipelines and monitoring dashboards. A property has to be built.
How the three concepts fit together as a pipeline
The three concepts stack in layers. Instrumentation produces telemetry. Monitoring consumes a predefined subset of that telemetry and checks it against thresholds. Observability emerges only when the telemetry underneath is complete enough and correlated enough to answer questions nobody anticipated.
The CNCF whitepaper makes the dependency explicit: "instrumentation is the key step to increase your observability qualities." The flow runs one direction. Services and nodes emit telemetry signals; those signals land in storage; monitoring rules watch known thresholds; engineers query across all of it when something unexpected breaks.
Gaps propagate upward through this stack. If teams sample traces or drop logs at ingestion to control cost, they make certain questions unanswerable. Teams cannot recover telemetry they never stored.
Metrics, logs, and traces: the three telemetry signal types
The CNCF whitepaper pushes back on the "three pillars" framing: "We like to think of them as the 'primary signals' instead of 'three pillars'," noting that profiles and crash dumps are joining the set. Still, metrics, logs, and traces are what most stacks collect today, and each captures something the others structurally cannot.
Metrics
Metrics aggregate numeric measurements over time: request rate, error count, p99 latency, node memory. They are cheap to store and fast to query because aggregation discards per-request detail at write time. That same aggregation makes cardinality the binding constraint.
Prometheus documentation is blunt about the limit: "Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values," because every unique label combination creates a new time series. Its instrumentation guide recommends keeping metric cardinality below 10. Engineers use metrics to see that something changed. They rarely show for whom or why.
Logs
Logs are discrete timestamped events, and they carry the high-cardinality context metrics discard: request IDs, user IDs, error strings, stack traces. Structure determines their value.
Parseable, indexed fields make logs useful. Free-text log lines force regex extraction at query time and shrink the set of questions you can ask, whatever backend stores them.
Distributed traces
Traces record a request's path across service boundaries as a tree of spans sharing a trace ID, with each span capturing one operation's timing and metadata. In a microservices architecture where one user request touches dozens of services, traces are the only signal that preserves causality across hops.
Sampling undercuts that value because teams cannot recover dropped requests during an incident.
No single signal suffices because each answers a different question: engineers use metrics to see latency changes, logs to inspect what one service recorded at that moment, and traces to locate where the request path slowed. Even the Prometheus FAQ draws the line: "Don't use Prometheus for logs!"
Known unknowns vs unknown unknowns: the core architectural divide
The CNCF whitepaper draws the line between the two: "Sometimes monitoring is called a system that can detect known unknowns," it says, "as opposed to observability which emphasizes being able to find and reason about unknown unknowns as well." Charity Majors makes the same operational distinction: monitoring covers known-unknowns through thresholds and checks; observability handles unknown-unknowns and requires a different mindset and toolchain.
Published postmortems show what happens when a novel failure meets a threshold-only stack:
- Monzo, July 2019: The postmortem cites "the lack of metrics showing Cassandra as a primary cause of the issue." Engineers had to bypass the configuration service and query Cassandra directly to confirm root cause.
- Slack, May 2020: The team asked "why our monitoring didn't catch this problem. We had alerting in place for this precise situation, but unfortunately, it wasn't working as intended."
- Cloudflare, November 2020: A switch failed in a Byzantine state where control-plane protocols stayed up while the data plane silently dropped packets. Cloudflare's postmortem says, "This failure scenario is completely invisible to the connected nodes."
When teams anticipate the failure mode, monitoring pages you and the runbook works. When they do not, you need to interrogate raw, high-cardinality telemetry until you can explain the failure. The 2021 Accelerate State of DevOps report found elite performers who meet their reliability targets are 4.1 times more likely to have solutions that incorporate observability into overall system health.
Why observability is a system property
Buying a platform does not confer the property. Gartner's 2022 Magic Quadrant quoted one executive: "It feels like we monitor everything, but see nothing." The quote captures the gap: dashboards everywhere, answers nowhere.
The prerequisites live in your system, not in a vendor's feature list. Your services must emit telemetry (instrumentation), that telemetry must carry enough structure and cardinality to support arbitrary queries, and it must land somewhere it can be correlated across signals. Miss any one and no UI compensates.
Instrumentation: the mechanism that produces telemetry
Instrumentation is deliberate engineering work at one of two layers. Code-level instrumentation means SDKs and agents per language: the OpenTelemetry Java agent manipulates bytecode, Python uses the opentelemetry-instrument CLI, and Go auto-instrumentation is eBPF-based and still in beta. Node-level instrumentation means kernel capture via eBPF, which trades per-service rollout work for infrastructure requirements: privileged DaemonSets and minimum kernel versions.
Code-level instrumentation also creates debt. Whichever path you choose, an agent you install is a mechanism for producing telemetry, and telemetry is still only the input to observability.
OpenTelemetry: standardizing how telemetry is collected
OpenTelemetry standardizes instrumentation across vendors: a set of APIs, SDKs, and the OTLP wire protocol for metrics, logs, and traces. The OpenTelemetry scope page states that OpenTelemetry instruments application code to make systems observable; the backend remains a separate choice. It reached CNCF graduation on May 11, 2026 with over 12,000 contributors from more than 2,800 companies, and the 2025 CNCF Annual Survey found 49% of respondents using it in production.
The architectural payoff is decoupling. Instrument once against the OTel API, export OTLP, and point the pipeline at any compliant backend; your instrumentation investment survives a vendor change.
groundcover treats OTel as a first-class data source that coexists with Flora. OTLP spans, metrics, and logs land in the same backend as the signals the Flora eBPF sensor captures at the kernel level, so services you have already instrumented with OTel SDKs coexist with kernel-captured data without duplication or re-instrumentation.
SLIs, SLOs, and the reliability contract observability enables
The Google SRE book defines an SLI as "a carefully defined quantitative measure of some aspect of the level of service that is provided" and an SLO as "a target value or range of values for a service level that is measured by an SLI." An SLO is a contract. Teams can trust that contract only when the telemetry behind it is complete enough to measure user experience.
The SRE book warns that "averaging request latencies may seem attractive, but obscures an important detail: it's entirely possible for most of the requests to be fast, but for a long tail of requests to be much, much slower." Percentile-based SLIs require raw enough latency data to compute p99 and p99.9. Pre-averaged gauges lose the distribution.
Sampling is the quieter risk. Head-based trace sampling can drop the outlier requests that matter most during SLO analysis, so error budgets computed from sampled traces can undercount real burn when the sample misses slow or failing requests. 100% span capture avoids that sampling blind spot and makes error budget arithmetic closer to what your users experienced.
Alert fatigue and how better observability reduces it
The structure of threshold-only alerting produces noise; tuning is secondary. The Google SRE Workbook works the math: a service sitting at its SLO threshold with a simple 10-minute threshold alert "could receive up to 144 alerts per day every day, not act upon any alerts, and still meet the SLO." Industry survey data shows the same pattern. BigPanda's July 2025 analysis of monitoring tool effectiveness found a median actionability rate of 18% of incidents, and Splunk's State of Observability 2024 (n=1,850) found 57% of respondents call alert fatigue somewhat or highly problematic.
Noise makes teams miss real incidents. The SRE book names the consequence: "When pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a 'real' page that's masked by the noise."
Multiwindow, multi-burn-rate alerts, which Google's workbook calls "the most viable and most highly recommended option," page on error budget consumption and cut false positives tied to raw thresholds. When the alert carries the trace, logs, and Kubernetes events for the affected request path, engineers have the context needed to start diagnosis without switching tools. Grafana Labs' 2026 survey (n=1,363) found 30% of respondents name alert fatigue the biggest obstacle to faster incident response.
Choosing your observability stack: criteria for platform engineers
Platform engineers can turn the distinction into concrete evaluation criteria.
Evaluation criteria for any stack
Test any candidate stack against these six:
- Cardinality support: High-cardinality fields (user IDs, request IDs, pod names) are the highest-value debugging data, and pricing often punishes them. Datadog lists custom metrics at $5.00 per 100 per month, with overage charges beyond plan allotments. Ask what a cardinality spike does to your bill and your storage before it happens.
- OpenTelemetry compatibility: Native OTLP ingestion over both gRPC and HTTP protects your instrumentation investment and your exit path.
- APM vs full observability: An APM tool covers application traces. Full observability requires backend traces plus infrastructure metrics, logs, and Kubernetes events correlated in one place. Tools that cover one slice leave the unknown-unknowns problem unsolved.
- Sampling vs 100% fidelity: Sampled traces make some incident questions permanently unanswerable and skew SLO math. Demand zero-sampling capture or a precise account of what gets dropped.
- Data residency: If telemetry must stay in your VPC, ask where each signal lands: logs, metrics, traces, RUM, and events. A SaaS-only control path differs from BYOC (Bring Your Own Cloud), where your data plane runs in your own cloud account and storage and processing stay there.
- Pricing decoupled from volume: Ask whether ingest, cardinality, or user count changes the bill. Vendors that price by ingest volume create an incentive for teams to sample and drop the very data observability depends on.
How groundcover maps to those criteria
groundcover's architecture is one answer to all six at once:
- Sensor and deployment: The Flora eBPF sensor deploys as a Kubernetes DaemonSet, one pod per node, and captures telemetry signals and Kubernetes events directly from the Linux kernel with zero application instrumentation: no SDKs, no per-service agents. Kernel capture cannot produce custom business-logic attributes or in-process spans, which is why OTLP ingestion sits alongside Flora.
- Storage and BYOC: ClickHouse holds logs, traces, and events; VictoriaMetrics holds metrics with full PromQL compatibility. Both run inside your own cloud account under the BYOC model, the default at every tier including free. groundcover manages both stores while every byte of telemetry stays in your account.
- Pricing and fidelity: Flat per-node pricing decouples cost from data volume, cardinality, and user count, so a 10x log spike during an incident changes nothing on the bill and nothing gets sampled away.
If you want to test the zero application instrumentation claim, the free tier includes the full BYOC architecture: deploy Flora on a single cluster and get full-cluster visibility within hours.
.svg)
