在Pingora代理中基于Rust tracing/OpenTelemetry实现请求生命周期跨异步回调的Span关联

我之前在基于Pingora做代理开发时，正好碰到过和你一模一样的链路追踪问题——Tokio/Pingora的异步回调机制太灵活了，各个阶段的函数可能在任意线程、任意时间被调用，要把每个阶段的Span都正确挂到请求的父Span下面，确实费了点功夫。结合我用tracing和OpenTelemetry的实践，给你整理两个靠谱的解决思路：

方案一：在请求上下文存储tracing::Span实例，回调时激活父Span #

这是最直接且稳定的方案，核心思路是把请求入口的父Span存在自定义的请求上下文中，每个阶段回调时先激活父Span，再创建子Span，子Span会自动继承父Span的上下文。

1. 首先定义包含父Span的请求上下文结构体：

use tracing::Span;

// 自定义请求上下文，存储父Span和其他请求相关数据
pub struct RequestContext {
    pub parent_span: Span,
    // 其他字段：比如请求头、上游地址等
}

2. 在请求入口处创建父Span并保存到上下文：

// 当请求刚进入代理时，创建根请求Span
let parent_span = tracing::info_span!("Request/Parent Span");
// 初始化请求上下文，把父Span存进去
let req_ctx = RequestContext {
    parent_span,
    // 初始化其他字段
};
// 把req_ctx传递给Pingora的各个阶段回调（比如通过Pingora的Request对象扩展）

3. 在各个阶段回调中激活父Span并创建子Span：

// 以Stage 1的回调为例
fn handle_stage1(ctx: &RequestContext) {
    // 激活父Span，返回的guard会在作用域内保持父Span为当前活跃Span
    let _parent_guard = ctx.parent_span.enter();
    
    // 创建并激活当前阶段的子Span，它会自动关联到父Span
    let _stage_guard = tracing::info_span!("Stage 1 Span").entered();
    
    // 执行Stage 1的业务逻辑
    // ...
}

// 上游请求的回调同理
fn handle_upstream(ctx: &RequestContext) {
    let _parent_guard = ctx.parent_span.enter();
    let _upstream_guard = tracing::info_span!("Upstream").entered();
    
    // 处理上游请求逻辑
    // ...
}

方案二：存储Span ID，回调时查找并激活父Span #

如果你的场景中无法直接存储Span实例（比如需要序列化上下文），可以存储Span的Id，回调时通过Id从tracing的全局注册表中查找并激活父Span。

1. 修改请求上下文存储Span ID：

use tracing::span::Id;

pub struct RequestContext {
    pub parent_span_id: Id,
    // 其他字段...
}

2. 入口处保存Span ID：

let parent_span = tracing::info_span!("Request/Parent Span");
let req_ctx = RequestContext {
    parent_span_id: parent_span.id().clone(),
    // ...
};

3. 回调中查找并激活：

fn handle_stage2(ctx: &RequestContext) {
    // 通过Span ID查找父Span，注意要处理查找失败的情况
    if let Some(parent_span) = tracing::span::Span::from_id(ctx.parent_span_id) {
        let _parent_guard = parent_span.enter();
        let _stage_guard = tracing::info_span!("Stage 2 Span").entered();
        
        // 执行Stage 2逻辑
        // ...
    }
}

关键注意事项 #

• Tokio异步任务的特殊处理：如果Pingora把阶段逻辑放到新的Tokio任务中，必须在任务内部执行父Span的激活操作，不能在任务创建时激活——因为Tokio任务会被调度到任意线程，而tracing的Span激活是线程局部的，任务创建时的激活无法带到新线程。
• OpenTelemetry自动关联：只要tracing的Span父子关系正确，OpenTelemetry的导出器会自动将这种层级关系转换成链路追踪的节点，最终生成你期望的树形结构：

|-- Request/Parent Span ---------------------------------------|
|-- Stage 1 Span --|
|-- Stage 2 Span --|
|-- Upstream --|

• 避免生命周期陷阱：tracing::Span是轻量级的Arc引用类型，直接存储实例是安全的，不用担心悬垂引用问题；不要尝试存储Span的引用（比如&Span），会导致生命周期冲突。

内容来源于stack exchange