⭐ GitHub | 🌐 Website | 📚 Docs

💬 Slack | 🐦 Twitter | 💼 LinkedIn

---

Distributed tracing just became significantly more accessible. GreptimeDB v0.14 officially supports OpenTelemetry Traces ingestion and querying, completing the observability trinity of metrics, logs, and traces in a single unified platform. This isn't just about adding another data type - it's about revolutionizing how organizations approach distributed system observability.

The Missing Piece: Distributed Tracing

Modern applications span dozens of microservices, making performance issues nearly impossible to diagnose without distributed tracing. Traditional approaches force teams to manage separate systems for metrics, logs, and traces, creating operational complexity and correlation challenges.

GreptimeDB v0.14 changes this equation by providing native OpenTelemetry traces support alongside existing metrics and logs capabilities. Now you can trace request flows, correlate with performance metrics, and analyze related log entries - all within a single database query.

OpenTelemetry Protocol Integration

GreptimeDB v0.14 implements full OTLP compatibility for traces ingestion:

Standard OTLP Endpoints

# Application configuration
exporters:
  otlp:
    endpoint: "http://greptimedb:4000/v1/traces"
    headers:
      x-greptime-db-name: "public"
    compression: gzip
    timeout: 30s

Batch Processing Optimization

# Optimized batch configuration
processors:
  batch:
    send_batch_size: 1000
    timeout: 10s
    send_batch_max_size: 1500

Batch processing significantly improves ingestion performance while reducing network overhead for distributed applications.

Unified Observability Data Model

GreptimeDB's approach treats traces as first-class citizens alongside metrics and logs:

Trace Data Schema

-- Automatic trace table structure
CREATE TABLE traces (
    trace_id STRING,
    span_id STRING,
    parent_span_id STRING,
    operation_name STRING,
    service_name STRING,
    start_time TIMESTAMP,
    end_time TIMESTAMP,
    duration_ms BIGINT,
    status_code INT,
    tags MAP<STRING, STRING>,
    logs TEXT,
    TIME INDEX(start_time)
);

Cross-Data Type Correlation

-- Correlate traces with metrics and logs
SELECT 
    t.trace_id,
    t.operation_name,
    t.duration_ms,
    m.response_time_p95,
    l.error_count
FROM traces t
JOIN metrics m ON t.service_name = m.service_name
JOIN logs l ON t.trace_id = l.trace_id
WHERE t.start_time > now() - INTERVAL '1 hour'
  AND t.duration_ms > 1000;

This unified querying capability eliminates the need for external correlation tools and complex data joins across multiple systems.

Advanced Trace Analysis Capabilities

Performance Bottleneck Identification

-- Find slowest operations across services
SELECT 
    service_name,
    operation_name,
    AVG(duration_ms) as avg_duration,
    P99(duration_ms) as p99_duration,
    COUNT(*) as span_count
FROM traces
WHERE start_time > now() - INTERVAL '24 hours'
GROUP BY service_name, operation_name
ORDER BY p99_duration DESC
LIMIT 20;

Error Rate Analysis

-- Analyze error patterns across trace spans
SELECT 
    service_name,
    operation_name,
    COUNT(*) as total_spans,
    COUNT(CASE WHEN status_code >= 400 THEN 1 END) as error_spans,
    COUNT(CASE WHEN status_code >= 400 THEN 1 END) * 100.0 / COUNT(*) as error_rate
FROM traces
WHERE start_time > now() - INTERVAL '6 hours'
GROUP BY service_name, operation_name
HAVING error_rate > 5.0
ORDER BY error_rate DESC;

Integration with Full-Text Search

GreptimeDB v0.14's enhanced full-text indexing works seamlessly with trace data:

Trace Search Optimization

-- Search traces by operation or service patterns
SELECT trace_id, service_name, operation_name, duration_ms
FROM traces
WHERE operation_name @@ 'payment' 
   OR service_name @@ 'billing'
   AND start_time > now() - INTERVAL '2 hours'
ORDER BY duration_ms DESC;

Log-Trace Correlation

-- Find traces related to specific error messages
SELECT DISTINCT t.trace_id, t.service_name, t.duration_ms
FROM traces t
JOIN logs l ON t.trace_id = l.trace_id
WHERE l.message @@ 'timeout'
   OR l.message @@ 'connection refused'
ORDER BY t.start_time DESC;

Vector Integration for Traces

Vector's OpenTelemetry support enables flexible trace collection pipelines:

# Vector configuration for trace collection
sources:
  otlp_traces:
    type: "opentelemetry"
    grpc:
      address: "0.0.0.0:4317"
    http:
      address: "0.0.0.0:4318"

transforms:
  enrich_traces:
    type: "remap"
    inputs: ["otlp_traces"]
    source: '''
    .environment = "production"
    .cluster_name = "us-west-2"
    if .duration_ms > 5000 {
      .slow_trace = true
    }
    '''

sinks:
  to_greptimedb:
    type: "greptimedb"
    inputs: ["enrich_traces"]
    endpoint: "http://greptimedb:4000"
    protocol: "otlp"

This pipeline approach enables trace enrichment, filtering, and routing before storage.

Performance Optimization for Traces

Sampling Strategies

# Application-level sampling
processors:
  probabilistic_sampler:
    sampling_percentage: 10  # Sample 10% of traces
    
  tail_sampling:
    decision_wait: 30s
    policies:
      - name: error_traces
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: slow_traces
        type: latency
        latency: {threshold_ms: 1000}

Storage Optimization

-- Configure trace data lifecycle
ALTER TABLE traces SET (
  retention_period = '30 days',
  partition_by = 'date(start_time)',
  compression = 'zstd'
);

Grafana and Jaeger Integration

GreptimeDB's trace support works with existing visualization tools:

Grafana Tempo Compatibility

# Grafana Tempo-compatible queries
- name: "Trace Duration Distribution"
  query: |
    histogram_quantile(0.95, 
      sum(rate(traces_duration_bucket[5m])) by (service_name, le)
    )

Jaeger Query Compatibility

# Jaeger-style trace queries
curl "http://greptimedb:4000/api/traces" \
  -G \
  -d "service=user-service" \
  -d "start=$(date -d '1 hour ago' +%s)000000" \
  -d "end=$(date +%s)000000" \
  -d "limit=100"

Real-World Trace Analysis Patterns

Dependency Mapping

-- Build service dependency graph
SELECT 
    parent_service,
    child_service,
    COUNT(*) as call_count,
    AVG(duration_ms) as avg_latency
FROM (
    SELECT 
        parent.service_name as parent_service,
        child.service_name as child_service,
        child.duration_ms
    FROM traces parent
    JOIN traces child ON parent.trace_id = child.trace_id
    WHERE parent.span_id = child.parent_span_id
      AND parent.start_time > now() - INTERVAL '1 hour'
) dependency_calls
GROUP BY parent_service, child_service
ORDER BY call_count DESC;

Critical Path Analysis

-- Find critical path in trace execution
WITH trace_spans AS (
  SELECT 
    trace_id,
    span_id,
    parent_span_id,
    operation_name,
    duration_ms,
    ROW_NUMBER() OVER (PARTITION BY trace_id ORDER BY duration_ms DESC) as duration_rank
  FROM traces
  WHERE trace_id = 'specific-trace-id'
)
SELECT operation_name, duration_ms
FROM trace_spans
WHERE duration_rank <= 5
ORDER BY duration_ms DESC;

Monitoring Trace Ingestion

Built-in metrics provide visibility into trace processing:

-- Monitor trace ingestion rates
SELECT 
    DATE_TRUNC('minute', timestamp) as minute,
    COUNT(*) as traces_per_minute,
    AVG(span_count) as avg_spans_per_trace
FROM trace_ingestion_stats
WHERE timestamp > now() - INTERVAL '1 hour'
GROUP BY minute
ORDER BY minute DESC;

The Complete Observability Picture

GreptimeDB v0.14's OpenTelemetry traces support completes the observability ecosystem:

• Metrics: Quantitative performance indicators
• Logs: Detailed event information
• Traces: Request flow visualization and timing

This unified approach eliminates the complexity of managing multiple observability databases while providing superior correlation capabilities that separate systems simply cannot match.

Ready to unify your observability stack? GreptimeDB v0.14's traces support brings distributed tracing into your unified observability platform, enabling comprehensive system understanding through a single, powerful interface.

---

About Greptime

GreptimeDB is an open-source, cloud-native database purpose-built for real-time observability. Built in Rust and optimized for cloud-native environments, it provides unified storage and processing for metrics, logs, and traces—delivering sub-second insights from edge to cloud —at any scale.

• GreptimeDB OSS – The open-sourced database for small to medium-scale observability and IoT use cases, ideal for personal projects or dev/test environments.

• GreptimeDB Enterprise – A robust observability database with enhanced security, high availability, and enterprise-grade support.

• GreptimeCloud – A fully managed, serverless DBaaS with elastic scaling and zero operational overhead. Built for teams that need speed, flexibility, and ease of use out of the box.

🚀 We’re open to contributors—get started with issues labeled good first issue and connect with our community.