Reference¶
Look-up facts for the Observability 2.0 paradigm: vocabulary, a dated timeline, the field groups of a wide event, sampling keep-rates, the backend landscape, and the OpenTelemetry components that matter for wide events. Facts were checked on 2026-09-25 against the linked sources. For the reasoning behind them see Explanation; for recipes see How-to Guides.
Glossary¶
| Term | Definition |
|---|---|
| Observability 1.0 | Majors' label for the multi-tool, "three pillars" approach: separate metrics, logs and traces (plus APM, RUM) stored and queried in different systems, much of it metrics-backed |
| Observability 2.0 | Majors' label for tools built on "arbitrarily-wide structured log events" as a single source of truth, from which metrics, traces and log views are derived at read time |
| Wide event | One structured record per unit of work (usually per request per service hop) with tens to hundreds of fields covering request, infrastructure, business and error context |
| Canonical log line | Stripe's name for one summary log line emitted at the end of each request with its key characteristics. The direct precursor of the wide event |
| Single source of truth | Storing raw events once and deriving every other view from them, instead of emitting separately shaped signals |
| Cardinality | Number of distinct values of a field. user_id is high cardinality; http.request.method is low |
| Dimensionality | Number of fields on an event. More fields means more ways to slice data without re-instrumenting |
| Known unknowns / unknown unknowns | Failures you anticipated (and built a dashboard for) vs failures you did not; the 2.0 argument is that only raw, high-cardinality events let you explore the latter |
| Head sampling | Keep/drop decision made when a request starts, usually from the trace ID. Cheap, but blind to the outcome |
| Tail sampling | Keep/drop decision made after the request or trace completes, based on outcome (errors, latency, attributes) |
| Sample rate | The N in "kept 1 in N". Stored on each kept event so queries can reweight counts |
| BubbleUp | Honeycomb feature that compares a selected slice of events to the baseline and ranks the dimensions that differ most |
| OTel Event | In OpenTelemetry, a LogRecord with a mandatory event_name and a schema, emitted via the Logs API. Not the same thing as a wide event |
| Span event | A timestamped annotation on a span. The Span Event API is being deprecated in favor of log-based events (2026) |
| Materialized view / continuous aggregation | Database-maintained aggregate over raw events that serves dashboards cheaply; moves pre-aggregation from the app into the store |
Timeline¶
| Date | Event | Source |
|---|---|---|
| 2016 | Honeycomb founded by Charity Majors and Christine Yen; builds the Retriever column store | Honeycomb |
| 2016-11-26 | Brandur Leach publishes "Using Canonical Log Lines for Online Visibility" | brandur.org |
| 2019-07-30 | Stripe blog: "Fast and flexible observability with canonical log lines" | Stripe |
| 2022-08-15 | Majors: "Live Your Best Life With Structured Events" (arbitrarily wide structured events) | charity.wtf |
| 2023-12 | Majors proposes versioning observability in a post on X | Honeycomb |
| 2024-08-07 | "Is It Time To Version Observability? (Signs Point To Yes)" | charity.wtf |
| 2024 (late) | Version of the essay published on Honeycomb's blog as "Introducing Observability 2.0" | Honeycomb |
| 2025-01-22 | Pragmatic Engineer episode "Observability: the present and future" with Majors | Pragmatic Engineer |
| 2025-03-13 | ClickHouse announces acquisition of HyperDX | ClickHouse |
| 2025-03 | ClickHouse 25.3 marks the JSON, Dynamic and Variant types production-ready |
ClickHouse 25.3 |
| 2025-04-18 | OTel blog "OpenTelemetry Logging and You": events are named logs, signals correlated by context | OTel |
| 2025-04-25 | Greptime: "Observability 2.0 and the Database for It" | Greptime |
| 2025-05 | ClickStack launched (ClickHouse + HyperDX + OTel Collector) | ClickHouse |
| 2025-06 | ClickHouse: LogHouse beyond 100 PB, internal system logs moved from OTel to the SysEx exporter | ClickHouse |
| 2025-10-30 | Majors: "How many pillars of observability can you fit on the head of a pin?" | charity.wtf |
| 2025-11-05 | OTel announces complex attribute types on all signals (OTLP 1.9.0) | OTel |
| 2026-03-11 | Honeycomb Metrics generally available | Honeycomb |
| 2026-03-17 | OTel announces deprecation of the Span Event API (OTEP 4430) | OTel |
| 2026-04 | GreptimeDB v1.0 GA (GA blog dated 2026-04-14; some trackers list the tag as 2026-04-08) | Greptime |
| 2026-06 | Observability Engineering, 2nd Edition (Majors, Fong-Jones, Miranda, with Parker) released | Honeycomb |
| 2026-09-16 | GreptimeDB v1.2.1 (after v1.2.0 on 2026-09-08 added the JSON2 type) | GreptimeDB release notes |
Context Groups in a Wide Event¶
Field groups used in the checkout example in Explanation.
| Group | Example fields | Purpose |
|---|---|---|
| Identity | request_id, trace_id, timestamp |
Correlation and ordering |
| Infrastructure | service, version, deployment_id, region |
Where the event happened |
| Request | method, path, status_code, duration_ms |
What happened |
| User / Business | user.id, user.subscription, user.account_age_days, user.lifetime_value_cents |
Who was affected and business impact |
| Operation | payment.method, payment.provider, payment.latency_ms, payment.attempt |
Domain-specific operation details |
| Error | error.type, error.code, error.message, error.retriable |
Failure specifics |
| Experiments | feature_flags.* |
Active flags for correlation analysis |
When the wide event is an OpenTelemetry span, identity, request and infrastructure fields map to built-in span data and semantic conventions (trace_id, http.request.method, http.response.status_code, service.name, service.version, cloud.region). Business, operation, error-detail and flag fields go under a project prefix such as app..
Sampling Rules Summary¶
| Rule | Keep rate | Rationale |
|---|---|---|
| Errors (5xx, exceptions) | 100% | Never lose failure evidence |
| Slow requests (above your p99) | 100% | Tail latency is where problems hide |
| VIP / enterprise customers | 100% | Business-critical; immediate escalation |
| Feature-flag rollouts | 100% | Correlate new code with new failures |
| Everything else | 1-5% | Healthy, fast requests; enough for baselines |
Record the effective sample rate on every kept event, or derived rates and counts will be skewed. Config examples are in How-to Guides.
Backend Landscape¶
Products and projects commonly cited as Observability 2.0 backends, grouped by layer. "Latest" values were checked 2026-09-25.
| Product | Layer | License | Storage model | Wide-event stance | Latest / status |
|---|---|---|---|---|---|
| Honeycomb | SaaS backend + UI | Proprietary SaaS | Retriever, custom distributed column store | Originator of the 2.0 framing; events first, Metrics GA since 2026-03 | SaaS (continuous) |
| Honeycomb Refinery | Tail-sampling proxy | Apache-2.0 | Stateless proxy cluster | Dynamic, rules-based, throughput and deterministic sampling | v3.4.0 (2026-09-03) |
| ClickHouse | Columnar OLAP database | Apache-2.0 | MergeTree columnar parts; object storage in ClickHouse Cloud | Promoted by ClickHouse as the wide-event store behind ClickStack | Monthly releases |
| ClickStack | Full stack (ClickHouse + HyperDX UI + OTel Collector) | ClickHouse Apache-2.0, HyperDX MIT | Per-signal tables (logs, traces, metrics, sessions) | "All observability data should be ingested as wide, rich events" | Launched 2025-05; managed ClickStack in ClickHouse Cloud |
| GreptimeDB | Observability database | Apache-2.0 core; Enterprise edition | Columnar engine on object storage; tags + timestamp + fields | Markets itself as the database for Observability 2.0 | v1.2.1 (2026-09-16) |
| SigNoz | OTel-native platform | MIT core, proprietary ee/ |
ClickHouse | OTel-native unified UI on ClickHouse | See topic |
| OpenObserve | Unified platform | AGPL-3.0 | Parquet on S3 | Unified logs/metrics/traces store | See topic |
| Monoscope | Platform | AGPL-3.0 | TimeFusion (DataFusion + Delta Lake) on user S3 | Full-fidelity, no-sampling storage | See topic |
| Dash0 | SaaS platform | Proprietary SaaS | TBD — not publicly documented | OTel-native, semantic-context positioning; does not brand itself "Observability 2.0" (unverified) | SaaS |
| Polylane (formerly nominal.dev) | AI operations layer | Proprietary | N/A | Founded by Boris Tane (loggingsucks.com author); "nobody should be on-call" self-operating software, not an event store | Early-stage |
GreptimeDB vs ClickHouse for O11y 2.0¶
| Dimension | GreptimeDB | ClickHouse |
|---|---|---|
| Design intent | Purpose-built observability database (metrics, logs, traces) | General-purpose OLAP engine, used heavily for observability |
| Data model | One table model: tags, timestamp, fields; time index required | Arbitrary tables; sort key chosen per table (time usually part of it) |
| OTel ingestion | Native OTLP; spans to opentelemetry_traces, logs to opentelemetry_logs |
Via the OTel Collector ClickHouse exporter (beta for traces/logs) or ClickStack's Collector |
| Other ingest | Prometheus Remote Write (v2 since 1.2.0), Loki Push, Elasticsearch Bulk, InfluxDB line protocol | Native protocols, Kafka engine, many table functions |
| Query | SQL, PromQL, Jaeger-compatible trace API, MySQL/PostgreSQL wire | SQL (ClickHouse dialect); PromQL not native |
| Dynamic schema | New attributes auto-create columns; JSON2 structural type since v1.2.0 | JSON type (production-ready since 25.3) stores each path as a subcolumn; Map columns in the OTel exporter schema |
| Derived metrics | Flow engine (continuous aggregation) | Materialized views, refreshable materialized views |
| Workload isolation | Read replicas and workload isolation are Enterprise-only | Compute-compute separation in ClickHouse Cloud; replicas in open source |
| Maturity | 1.x since April 2026; newer | Long production history at very large scale |
Corrected 2026-09
An earlier version of this comparison said ClickHouse "requires ALTER TABLE or migrations for new columns" and "requires ClickStack or external middleware (Kafka, Redis)". Both are outdated: the ClickHouse JSON type absorbs new attributes without DDL, and ClickStack or the Collector's ClickHouse exporter ingest OTLP directly.
OpenTelemetry Components for Wide Events¶
| Component / spec item | Status (2026-09) | Relevance | Source |
|---|---|---|---|
tail_sampling processor |
Beta (traces); contrib and k8s distributions | Outcome-based trace sampling in a gateway tier | README |
load_balancing exporter (formerly loadbalancing) |
Beta (traces, logs); alpha (metrics); contrib and k8s distributions | Routes all spans of a trace to one tail-sampling replica | README |
adaptive_tail_sampling processor (formerly dynamic_sampling) |
Development; in no distribution | Adaptive per-rule sample rates encoded in W3C TraceState (ot=th) |
README |
| ClickHouse exporter | Beta (traces, logs); alpha (metrics) | Writes OTel data to ClickHouse otel_* tables |
README |
| Complex attribute types (maps, heterogeneous arrays) on all signals | OTLP 1.9.0; SDK rollout in progress | Nested wide-event context on spans; backend support varies | OTel blog |
Span Event API (Span.AddEvent, Span.RecordException) |
Being deprecated (OTEP 4430) | Put context on span attributes or log-based events | OTel blog |
| Events API/SDK | Deprecated; use Logs API with event_name |
OTel "events" are named log records | OTel blog |
Pricing Reference¶
Pricing changes often; confirm on vendor pages before budgeting.
| Vendor | Model | Known data points | Source |
|---|---|---|---|
| Honeycomb | Per event ingested | Free plan: up to 20 million events per month. Pro plan pricing changed in 2026 (Honeycomb doc "2026 Pro Plan Changes"); third-party reviews report a July 2026 per-event rate increase — unverified against Honeycomb's own page | Honeycomb pricing |
| Honeycomb Metrics | Per time series | Launch promotion "as low as $2 per 1,000 time series per month", valid to end of June 2026 (expired) | Honeycomb |
| ClickStack | Open source, or ClickHouse Cloud consumption | Self-hosted free; Cloud billed on ClickHouse Cloud compute and storage | ClickStack |
| GreptimeDB | Open source core; Enterprise and GreptimeCloud | Edition comparison on the pricing page | Greptime pricing |
Sources¶
- charity.wtf — Is It Time To Version Observability?
- Honeycomb — It's Time to Version Observability: Introducing Observability 2.0
- Brandur Leach — Using Canonical Log Lines for Online Visibility
- Stripe — Fast and flexible observability with canonical log lines
- ClickStack README and HyperDX README
- GreptimeDB README and v1.2.0 release blog
- Honeycomb Refinery
- OpenTelemetry Collector contrib CHANGELOG
- Polylane (formerly nominal.dev)