使用@opentelemetry/auto-instrumentations-node时，traceparent是否传至数据库服务器？

核心答案 #

针对MongoDB、MySQL、PostgreSQL这类数据库，traceparent不会被传递到数据库服务器，OpenTelemetry的数据库自动插桩仅在应用层完成追踪操作。

具体原因 #

1. 协议特性限制

   • HTTP、AMQP（RabbitMQ采用的协议）本身支持自定义请求头，天然适合携带traceparent这类元数据，所以OpenTelemetry能直接把trace上下文塞进这些协议头里跨服务传递。
   • 但MySQL、PostgreSQL的底层协议是为数据库交互量身设计的，没有预留通用的自定义头字段；MongoDB的协议虽有扩展空间，但官方自动插桩工具并没有实现把traceparent嵌入请求的逻辑。

2. 插桩工具的定位

   • @opentelemetry/auto-instrumentations-node里的数据库插桩组件，核心工作是在应用发起数据库调用时，自动生成本地span，记录调用耗时、脱敏后的SQL语句、数据库地址等信息，把这些数据关联到当前的trace链路中，但不会修改数据库请求的协议内容。
   • 只有需要跨进程/跨服务传递trace上下文时，才会通过协议头传递traceparent。而数据库调用属于应用到数据库的单向依赖请求，OpenTelemetry默认不会把trace上下文传递到数据库端——毕竟主流数据库本身也没有原生支持接收和处理OpenTelemetry trace数据的能力。

3. 抓包/日志找不到的原因

   • 因为traceparent根本没被嵌入到数据库请求的数据包里，所有追踪数据都只在应用进程内生成、处理，之后导出到OpenTelemetry Collector或其他后端系统。

额外说明 #

如果想追踪数据库端的具体操作（比如SQL执行耗时、锁等待等），不能靠应用端的traceparent传递，得单独在数据库侧部署对应的OpenTelemetry插桩工具（比如针对MySQL的专用插桩），或者用数据库自带日志结合解析工具，把数据接入OpenTelemetry链路系统。

而RabbitMQ、HTTP这类跨服务场景，传递traceparent是为了实现分布式追踪，让不同服务的span能关联到同一条trace链；数据库调用更多是作为应用的依赖资源，OpenTelemetry的设计就是在应用层记录依赖调用情况，而非把trace上下文传递到数据库。

内容的提问来源于stack exchange，提问作者Govind Tomar