Migrate Data from Honeycomb to SigNoz

This guide explains how to migrate observability data from Honeycomb to SigNoz, leveraging the unified OpenTelemetry approach that both platforms now support. You'll learn how traces, logs, and metrics flow seamlessly through a single OTLP endpoint to SigNoz, enabling enhanced correlation and unified observability.

Prerequisites

Before migrating your data from Honeycomb to SigNoz:

• SigNoz Setup: Active SigNoz Cloud account or self-hosted SigNoz instance
• Application Access: Ability to modify OpenTelemetry configuration and restart instrumented applications
• Honeycomb Data Documentation: Understanding of your current data types and retention requirements

Understanding Unified Data Flow

Before migrating your data, it's important to understand how Honeycomb and SigNoz handle observability data differently. This knowledge will help you plan your migration strategy and configure proper data correlation in SigNoz.

Honeycomb's Data Model

Honeycomb treats most observability data as events with structured fields:

SigNoz's Unified Approach

SigNoz provides native OpenTelemetry support with configurable correlation:

Unified Data Flow to SigNoz

Single OTLP Endpoint Benefits

SigNoz uses a unified OpenTelemetry collector that receives traces, logs, and metrics through a single OTLP endpoint. This seamless approach provides:

• Automatic correlation: Traces, logs, and metrics with matching trace context are automatically linked
• Unified timestamps: All signals share consistent timing for accurate debugging
• Single configuration: One endpoint handles all telemetry types without separate setup
• Reduced complexity: No need to configure separate pipelines for different signal types

How Signals Flow and Correlate

When properly configured, telemetry data flows seamlessly:

1. Applications send all signals to the same SigNoz OTLP endpoint
2. SigNoz automatically correlates data using trace context (trace_id, span_id)
3. Users can jump from metrics to traces to logs with automatic linking
4. Unified dashboards show all signals together for complete observability

OpenTelemetry Configuration

Since both Honeycomb and SigNoz use OpenTelemetry, migrating your data involves updating your OTLP endpoint configuration to point to SigNoz instead of Honeycomb.

Complete the basic setup first: Follow the OpenTelemetry endpoint migration guide to configure your applications to send data to SigNoz.

This guide covers the data aspects of migration - configuring trace correlation, formatting logs properly, understanding retention differences, and verifying that traces, logs, and metrics are all flowing correctly to SigNoz.

Configure Signal Correlation

SigNoz automatically correlates logs with traces when both contain matching trace and span IDs, providing enhanced debugging capabilities beyond Honeycomb's event-based approach.

For automatic correlation, use OpenTelemetry SDKs which automatically inject trace context into logs. For manual configuration when using file-based logs or custom setups, ensure your logging libraries include trace_id and span_id fields in the log output.

Once configured, you'll be able to jump from traces to logs directly in the SigNoz interface for enhanced debugging.

Configure Additional Metrics Sources

After completing the basic OpenTelemetry endpoint migration, you may need to configure additional metrics collection methods to capture all your Honeycomb metrics in SigNoz.

SigNoz supports multiple metrics ingestion methods:

• OTLP Metrics: Direct from OpenTelemetry SDKs (primary method)
• Prometheus Receiver: For existing Prometheus metrics endpoints
• Custom Metrics: Application-specific business metrics

Enable Prometheus Receiver

Enable the Prometheus receiver in your SigNoz OpenTelemetry Collector configuration to scrape existing Prometheus metrics:

# otel-collector-config.yaml
receivers:
  prometheus:
    config:
      global:
        scrape_interval: 15s
        evaluation_interval: 15s
      scrape_configs:
        - job_name: 'my-application'
          static_configs:
            - targets: ['localhost:8080']
          metrics_path: '/metrics'
          scrape_interval: 30s

processors:
  batch:

exporters:
```yaml:otel-collector-config.yaml
# otel-collector-config.yaml
    endpoint: "ingest.{region}.signoz.cloud:443"  # For SigNoz Cloud
    headers:
      "signoz-ingestion-key": "${SIGNOZ_INGESTION_KEY}"

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch]
      exporters: [otlp]

For detailed Prometheus receiver setup, follow the Prometheus Receiver configuration guide.

Configure OTLP Metrics

If your applications use OpenTelemetry SDKs, ensure metrics are enabled:

Environment Variables:

export OTEL_METRICS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://ingest.{region}.signoz.cloud:443/v1/metrics
export OTEL_EXPORTER_OTLP_HEADERS="signoz-ingestion-key=${SIGNOZ_INGESTION_KEY}"

Data Retention and Historical Considerations

Historical Data Migration

Important: SigNoz cannot directly import historical data from Honeycomb. Plan your migration strategy accordingly:

While both platforms use OpenTelemetry for data ingestion, they store data in different formats. Honeycomb uses proprietary event-based storage, while SigNoz stores telemetry data in ClickHouse using schemas optimized for analytical queries. Direct data migration between these systems is not supported.

Retention Policy Comparison

SigNoz offers more flexible retention options, especially with self-hosted deployments where retention is limited only by your storage capacity. This can provide significant cost advantages for organizations requiring longer data retention periods.

Cost Planning: Use the SigNoz pricing calculator to estimate your monthly costs based on your expected data volume and retention needs.

Next Steps

With your data migration complete, continue with the remaining migration components:

1. Migrate Dashboards - Recreate Honeycomb boards with enhanced SigNoz visualizations
2. Migrate Alerts - Convert triggers to SigNoz alert rules with multi-signal correlation