Skip to main content
Version: Nightly

Observability 2.0

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

GreptimeDB supports this approach, but does not require it. Metrics, logs, and traces remain first-class capabilities. GreptimeDB provides ingestion paths for each signal, SQL queries across all signal types, PromQL for metrics, and a Jaeger-compatible query API for traces. You can keep these signals in their existing forms, introduce wide events for selected workloads, or use both models together.

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.

A unified model reduces these boundaries by using consistent schemas and query tools. Wide events are one way to retain more context, not a replacement for every metric, log, or trace.

Metrics, logs, and traces remain in independent tables while sharing common data-model concepts, storage, and query layers.

Wide Events: A Unified Data Model​

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 Context-Rich Events​

In this approach, a context-rich 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 Maps to This Model​

GreptimeDB uses a common data model and query layer across observability workloads. The mapping is:

PatternGreptimeDB capabilityHow to use it
Native metricsPrometheus Remote Write, OpenTelemetry OTLP/HTTP, PromQL, and SQLIngest Prometheus or OTLP metrics; keep existing metrics and dashboards in their native form.
Logs and tracesLoki Push API, OpenTelemetry OTLP/HTTP, Elasticsearch Bulk API, SQL, and the Jaeger-compatible query APIIngest with the supported protocols; query all signal types with SQL, and traces with the Jaeger-compatible API.
Shared schema conceptsTag, timestamp, and field columnsApply a consistent table model across different telemetry tables.
Structured logs and context-rich eventsPipeline, wide tables, and SQLParse and transform logs into structured events before storage, then keep selected events for detailed or retrospective analysis.
Derived metricsFlowContinuously aggregate stored context-rich events into a separate metrics table.
Cross-signal analysisSQL across tables and shared correlation identifiersRelate signals when their schemas and instrumentation provide common keys.

A unified table model does not mean writing all data into one table. Metrics, logs, traces, and raw events can use separate tables with different schemas, retention policies, and indexes. The unification is at the schema concepts, storage system, and query layer.

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 then continuously aggregate the stored events into metrics tables for dashboards and alerts.

Pipeline can process logs during ingestion, while Flow can aggregate stored events 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 unified-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​