Observability 2.0 describes a fundamental rethink of how engineering teams collect, store, and query telemetry data. Where earlier approaches treated metrics, logs, and traces as three separate data types living in three separate systems, Observability 2.0 collapses those silos into a single primitive: the wide structured event. A wide event is an arbitrarily wide, structured record that carries every relevant attribute about a moment in a system's life — service name, host, user ID, trace ID, error code, latency, upstream dependency, and dozens more fields — all in one row. Query any dimension at any time, without deciding in advance which dimensions matter. Charity Majors and others in the observability community have written extensively about structured events as the replacement for the three-pillars mental model, and the idea has moved well beyond thought leadership into production architecture.

Organizations care because the status quo is becoming financially and operationally unsustainable. Log data volumes in large enterprises roughly double every 18 months, and the proprietary storage systems most teams built their observability stacks on were not designed for that growth curve. Costs balloon, retention windows shrink, and engineers spend more time context-switching between dashboards than actually debugging. Observability 2.0 responds to that pressure with an architecture grounded in open standards — primarily OpenTelemetry for collection and Apache Parquet or Apache Iceberg for storage — that separates compute from storage, stores raw events on commodity object storage, and lets teams query years of telemetry with the same analytical rigor they would apply to any business dataset.

Prometheus and similar metric stores build a new time series for every unique combination of label values. A field like user_id or request_id can explode that cardinality into millions of series, making those stores slow and expensive to operate. Teams respond by pre-aggregating — dropping high-cardinality fields before storage — which destroys exactly the context needed to debug novel failures. High-cardinality fields are effectively unqueryable in Prometheus without pre-labeling, a hard architectural ceiling that Observability 2.0 removes.

In a columnar lake architecture, high-cardinality string fields compress efficiently with dictionary encoding. Parquet typically achieves 5 to 10 times compression versus row-oriented formats for time-series and log data, and query cost depends on partitioning and sorting strategy rather than on the number of unique values at ingest. Cardinality stops being a constraint you architect around and becomes just another dimension you query.

Legacy observability vendors charge per gigabyte ingested, per host monitored, or per query executed — sometimes all three. Those models made sense when telemetry volumes were modest. They do not make sense at modern scale. Separating storage from compute, with raw events landing in object storage like S3 or GCS and a query engine reading from there on demand, changes the unit economics substantially. Apache Iceberg adds ACID transactions, schema evolution, and time travel on top of object storage, giving teams the reliability guarantees they expect from a managed database without the proprietary lock-in.

One important nuance: lower per-GB storage cost does not automatically mean lower total spend. Jevons Paradox applies directly to observability economics — cheaper storage encourages teams to retain more data and run more queries, and query compute costs can offset storage savings if the architecture is not designed carefully. Building with this in mind from the start, through aggressive partitioning, tiered storage, and schema discipline, is part of what distinguishes a mature Observability 2.0 implementation from a naive one.

OpenTelemetry is the second most active CNCF project by contributors after Kubernetes, and its tracing and metrics APIs are stable across all major languages. The OpenTelemetry Collector supports more than 50 receiver plugins and more than 30 exporter plugins, making it practical to build a vendor-agnostic pipeline that receives data from any instrumented service and routes it to any storage backend. Semantic conventions standardize attribute names across HTTP, database, messaging, and cloud resources, which means correlation across services does not require custom glue code. For a practical implementation walkthrough, the OpenTelemetry and Grafana integration guide shows how these pieces fit together in production.

Migrating to an Observability 2.0 architecture is not a weekend project. The most common friction points are schema discipline, incremental migration, and query compute costs.

Wide events require teams to agree on structured, typed fields rather than free-text log lines. Unstructured text compresses poorly and defeats columnar storage efficiency. The OTel log data model provides a starting schema, but each organization needs to enforce consistency across services.

Most teams cannot remove Prometheus, Splunk, or Datadog overnight. The OpenTelemetry Collector's Prometheus receiver allows existing metric pipelines to feed into new backends gradually, but dual-running systems temporarily increases operational complexity. Storing raw events cheaply is the easy win; querying them efficiently at scale requires thoughtful partitioning, sort key selection, and data lifecycle management. Teams that skip this step find that query costs grow faster than storage savings. The log analytics guide covers these tradeoffs in depth.

Start with instrumentation, not storage. Deploy OpenTelemetry SDKs in new services and route output through the OpenTelemetry Collector. This step alone breaks vendor lock-in at the collection layer without requiring any storage migration. The observability in 2025 outlook offers useful context on where the ecosystem is heading.

Next, pick one high-volume, high-cost data source — CDN access logs, API gateway logs, and Kubernetes pod logs are common candidates — and route it to a columnar lake backend rather than your existing SIEM or log platform. CDN and network telemetry at hyperscale is a primary driver for lake-native observability architectures precisely because the volume-to-budget ratio makes the cost argument obvious. Validate query latency and compression ratios against your existing system before expanding scope.

Finally, define a retention and lifecycle policy before data volumes grow. Iceberg's table-level expiration and compaction features handle object proliferation automatically, but only if you configure them. Teams migrating away from legacy vendors for cost reasons will find the guide on reducing Splunk costs useful for quantifying the opportunity before committing to an architectural change.