用途：帮助把 OpenTelemetry 逐步接入已有、尚未埋点的应用，区别于全新项目的 OTel 搭建和 Beeline 专用迁移。
主要能力：按六个可独立部署、可验证的阶段推进。1）SDK 初始化与关闭：配置 TracerProvider、MeterProvider、LoggerProvider 与 OTLP 导出器，入口尽早初始化，信号处理中按 traces、metrics、logs 顺序刷新并设超时；初始化失败不应影响应用运行。2）HTTP 中间件：为每个入站请求自动生成 Span，是收益最高的一步；不同框架获取 OTel 上下文方式不同，如 Go Fiber v2 用 c.UserContext()，Gin 用 c.Request.Context()，误用会导致链路静默中断。3）上下文传播重构：把 trace 上下文从处理器贯穿到 I/O 操作，通常占约 60% 工作量；Go 最难，需逐层加 context.Context，Java 在线程池、CompletableFuture、响应式流中易丢失，Python、Node.js、.NET、Ruby 相对容易。4）自定义 Span：先覆盖数据库、外部 HTTP、缓存等 I/O 边界，再补业务逻辑，并记录属性与结果。5）日志迁移：将现有日志桥接到 OTel 以关联 trace，通常需同时输出到 stderr 和 OTel，printf 风格需先转结构化日志。6）指标桥接：已有 Prometheus 指标可桥接而非重写，保留 /metrics 端点，桥接额外提供 OTLP 导出。
使用方式：每阶段完成后按验证清单核对；本地无 Honeycomb 账号时可用随附 collector 脚本以 debug 输出和 NDJSON 捕获 Span。
适用场景：已有日志、指标或上下文模式需与 OTel 共存，需重构函数签名传递 trace 上下文，或使用 Fiber、Gin、Express 等有中间件陷阱的框架。
限制：资料未提供具体安装命令、价格、平台支持范围与效果数据；各语言细节需查阅对应参考文件。