Self-Hosted Observability Directory

Migration playbook

Replace Honeycomb with OSS tracing and high-cardinality analysis

A cautious path for replacing Honeycomb-style event analysis with OpenTelemetry pipelines, trace backends, and queryable logs.

Vendor Honeycomb
Timeline 8-12 weeks
Difficulty High

Honeycomb replacement should be framed as workflow migration, not just trace storage. Preserve the incident questions engineers ask most often, then decide which exploratory gaps are acceptable.

Recommended OSS Stack

Stack Options

Trace-first investigation

Best for: Teams whose Honeycomb usage centers on distributed traces and service debugging.

Grafana Tempo · Grafana · OpenTelemetry Collector

  • Strong trace correlation, but ad hoc high-cardinality event slicing is less Honeycomb-like.
  • Sampling and retention choices must be explicit before cutover.

APM plus event search

Best for: Teams that need trace workflows and searchable structured events.

SigNoz · Uptrace · Quickwit · OpenTelemetry Collector

  • Closer to exploratory analysis, but requires more careful pipeline design.
  • High-cardinality dimensions can still become a cost or performance problem.

Migration Phases

  1. Identify Honeycomb behaviors

    1-2 weeks

    Outcome: Boards, triggers, datasets, derived columns, and high-cardinality fields are documented.

    • Export or inventory boards, triggers, SLOs, datasets, and query examples.
    • List dimensions that engineers rely on during incidents.
    • Classify derived columns and BubbleUp-style workflows that need replacement.

  2. Normalize telemetry contracts

    2-3 weeks

    Outcome: OpenTelemetry attributes, sampling rules, and event schemas are stable enough for migration.

    • Define required resource and span attributes for services, deploys, users, and tenants.
    • Route telemetry through OpenTelemetry Collector processors for redaction and normalization.
    • Choose tail, head, or dynamic sampling policies by service criticality.

  3. Rebuild investigation paths

    3-4 weeks

    Outcome: Engineers can answer the most common incident questions without Honeycomb.

    • Create trace, service, deploy, and error investigation dashboards.
    • Port trigger alerts and compare them against Honeycomb for two release cycles.
    • Document where exploratory queries require a different workflow.

  4. Reduce dependency

    2-3 weeks

    Outcome: Honeycomb is no longer the primary incident investigation system.

    • Move runbook links and deploy annotations to the OSS stack.
    • Keep Honeycomb read access while teams validate edge-case investigations.
    • Retire datasets only after owners confirm replacement coverage.

Cutover Checklist

  • Required OpenTelemetry attributes are documented and enforced.
  • Sampling policy preserves errors, slow traces, and high-value tenants.
  • Top incident queries have equivalent workflows.
  • Triggers or SLO alerts are recreated and tested.
  • Known gaps versus Honeycomb exploratory analysis are explicit.

Risks To Manage

  • Honeycomb's exploratory high-cardinality UX does not map cleanly to every OSS backend.
  • Poor sampling choices can erase the exact traces needed during an incident.
  • Derived columns and dataset conventions may hide business logic that needs to move into telemetry pipelines.

Back to migration playbooks