Step-by-step guide for migrating from Honeycomb Beelines (End of Life) to OpenTelemetry instrumentation. Trigger phrases: "migrate from Beelines", "upgrade from Beeline to OpenTelemetry", "migrate to OTel", "replace Beelines", "Beeline end of life", "Beeline EOL", "switch from Beeline to OTel", "migrate Go Beeline", "migrate Python Beeline", "migrate Node Beeline", "migrate Java Beeline", "migrate Ruby Beeline", "W3C trace headers", "W3C propagation", "incremental migration to OpenTelemetry", or any request about migrating from Honeycomb Beelines to OpenTelemetry SDKs.
From honeycombnpx claudepluginhub honeycombio/agent-skill --plugin honeycombThis skill uses the workspace's default tool permissions.
references/migration-steps-by-language.mdreferences/w3c-propagation.mdExecutes pre-written implementation plans: critically reviews, follows bite-sized steps exactly, runs verifications, tracks progress with checkpoints, uses git worktrees, stops on blockers.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Step-by-step guide for migrating from Honeycomb Beelines (now End of Life) to OpenTelemetry instrumentation.
Honeycomb Beelines have reached End of Life and are archived. All new instrumentation should use OpenTelemetry. Existing Beeline users should migrate as soon as practical.
Migration follows a two-phase approach that allows incremental, service-by-service migration without breaking distributed traces.
Before migrating any service to OTel, all services must support W3C trace headers. This enables Beeline and OTel services to share trace context.
Minimum Beeline versions for W3C support:
| Language | Minimum Version |
|---|---|
| Go | 1.4.0 |
| Java | 1.7.0 |
| Node.js | 3.2.2 |
| Python | 2.18.0 |
| Ruby | 2.8.0 |
After all services support W3C headers:
Key rule: Complete Phase 1 across ALL services before starting Phase 2 on ANY service.
beeline.Init(beeline.Config{
HTTPPropagationHook: propagation.W3C,
})
beeline.init(
http_trace_propagation_hook=beeline.propagation.w3c.http_trace_propagation_hook,
http_trace_parser_hook=beeline.propagation.w3c.http_trace_parser_hook,
)
const beeline = require("honeycomb-beeline")({
httpTraceParserHook: beeline.w3c.httpTraceParserHook,
httpTracePropagationHook: beeline.w3c.httpTracePropagationHook,
});
For Java and Ruby configurations, consult ${CLAUDE_PLUGIN_ROOT}/skills/beeline-migration/references/w3c-propagation.md.
For each service being migrated from Beeline to OTel:
OTEL_SERVICE_NAME to match existing service namestartSpan() -> OTel tracer.start_span()addField() -> OTel span.set_attribute()OTEL_SERVICE_NAME identical to the Beeline service name — Honeycomb uses this as the dataset name, and changing it splits your data into a new datasetaddField() calls before removing the Beeline SDK — each one needs a corresponding span.set_attribute() in OTel to preserve your query dimensionshttp.request.method vs request.method), and dashboards or SLIs referencing the old names will need updating${CLAUDE_PLUGIN_ROOT}/skills/beeline-migration/references/migration-steps-by-language.md — Detailed migration code for each language${CLAUDE_PLUGIN_ROOT}/skills/beeline-migration/references/w3c-propagation.md — Complete W3C configuration for all Beeline languages