Skip to main content
Version: 1.1

Observability 2.0

Observability 2.0 is an industry term for an approach to telemetry, not a product category. It usually refers to retaining wide events and analyzing them without deciding every question in advance.

GreptimeDB's data model supports native metrics, logs, and traces alongside wide events. This page focuses on the wide-event approach associated with Observability 2.0. GreptimeDB supports this practice but does not require it; metrics, logs, and traces remain first-class capabilities.

The Limits of Three Pillars​

Metrics, logs, and traces remain useful abstractions. The problem is not the signals themselves, but the operational boundary that often forms around each one:

  1. Separate context: When signals are stored and queried in separate systems, correlating an alert with the relevant logs and traces takes extra work.
  2. Questions fixed at collection time: Pre-aggregated metrics answer known questions efficiently, but cannot recover dimensions that were not recorded.
  3. Lost structure: Plain-text logs often contain useful fields that are expensive to parse and index later.

Shared schema concepts, storage infrastructure, and query tools reduce these boundaries. Wide events are one way to retain more context, not a replacement for every metric, log, or trace.

Wide Events​

A wide event is a structured record with many fields describing one operation or business event. It can include high-cardinality values such as user IDs, session IDs, trace IDs, and request attributes.

What is a Wide Event?​

For example, an event for a POST request might include user and subscription data, database and cache operations, HTTP attributes, outcome, and duration:

{
  "timestamp": "2026-08-12T08:15:30Z",
  "method": "POST",
  "path": "/articles",
  "service": "articles",
  "outcome": "ok",
  "status_code": 201,
  "duration": 268,
  "user": {
    "id": "fdc4ddd4-8b30-4ee9-83aa-abd2e59e9603",
    "subscription": { "plan": "free", "trial": true }
  },
  "db": {
    "query": "INSERT INTO articles (...)"
  },
  "cache": { "operation": "write" },
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Capture only the context that is useful and safe to retain. Credentials, personal data, query parameters, prompts, and request bodies may require filtering or redaction before ingestion.

Views Derived from Wide Events​

In this approach, a wide event can produce several views:

  • a metric aggregated by status and time window;
  • a searchable log record containing the event details;
  • a trace or span view linked by trace and span IDs.

This is a useful mental model, not a requirement that every signal must be reconstructed from raw events. Native metrics are often the better representation for fixed aggregations, and standard trace data remains useful for call graphs and latency analysis.

AI and the Need for Fine-Grained Observability​

AI applications often need to relate model requests, responses, tool calls, latency, token use, evaluations, and application state. A structured event can keep this context queryable when the instrumentation captures it.

The same trade-offs apply as in other workloads: prompts and responses can be large or sensitive, session identifiers create high cardinality, and incomplete instrumentation produces incomplete context. Teams should choose fields, retention periods, and redaction rules based on the questions they need to answer.

The table semantic layer can describe what each table represents so that agents and tools do not have to infer signal type, source, or metric type from column names.

How GreptimeDB Supports Wide Events​

GreptimeDB stores wide events in regular time-indexed tables. Pipeline, SQL, and Flow support different stages of the approach:

StageGreptimeDB capabilityRole
Ingest, when neededPipelineParse, transform, and enrich incoming logs before storage.
Store and analyzeTime-indexed tables and SQLRetain wide events for detailed and retrospective analysis.
DeriveFlowContinuously aggregate incoming rows into separate metrics tables.

Wide events do not require native metrics, logs, traces, and raw events to share one table. Each can use separate tables with different schemas, retention policies, and indexes.

Pipeline and Flow handle different stages. Pipeline parses, transforms, and enriches logs during ingestion. Its output is structured, multi-column data; when those fields retain the context of an operation or business event, each row can serve as a wide event. Flow can continuously aggregate the same event rows as they arrive into metrics tables for dashboards and alerts.

Pipeline can process logs during ingestion, while Flow can aggregate incoming event rows into a derived metrics table.

For example, Flow can derive a status metric from an event table:

CREATE FLOW http_status_count
SINK TO status_metrics
AS
SELECT
  status_code,
  COUNT(*) AS count,
  date_bin('1 minute'::INTERVAL, timestamp) AS time_window
FROM access_logs
GROUP BY status_code, time_window;

The stored events remain available for detailed SQL queries, while the sink table serves fixed dashboards and alerts efficiently.

Trade-offs​

The wide-event approach changes where you pay for flexibility:

  • Wider events increase data volume. More fields and repeated context consume ingestion bandwidth and storage, even with columnar compression.
  • High cardinality and long retention increase cost. Keep only useful dimensions, and set retention independently for raw and derived data.
  • Complete context depends on instrumentation quality. Missing identifiers, inconsistent schemas, or poor propagation cannot be repaired by the database.
  • Native metrics still fit fixed aggregations. Counters, gauges, histograms, recording rules, dashboards, and alerts usually do not need a raw event behind every sample.

Schema governance, sampling, redaction, and retention are part of the design. A wide event should be as wide as the investigation requires, not as wide as the application can produce.

Adoption Paths​

Keep Native Signals and Unify Storage and Query​

Continue using existing ingestion protocols. Query metrics with PromQL, query all signal types with SQL, and use the Jaeger-compatible API for traces. Store each signal in separate GreptimeDB tables, and use shared identifiers and SQL when cross-signal analysis is needed. This path minimizes instrumentation and dashboard changes.

Start with Prometheus, logs, OpenTelemetry, or traces.

Add Raw Events Where Full Context Matters​

Instrument selected business operations or AI workflows as structured events. If the context starts in logs, use Pipeline to extract and transform it into structured columns during ingestion. Keep the event table for retrospective analysis, and use Flow to derive metrics for known dashboards and alerts. This path provides more context at the cost of higher data volume and stricter schema and retention management.

The two paths can coexist. Adopt raw events only where the additional context justifies their cost.

Further Reading​