DataDog近期在GitHub上开源了名为pg_tracing的PostgreSQL扩展，该扩展专为生成分布式追踪的服务器端Span而设计，目标是增强对PostgreSQL数据库操作的细粒度可见性。该工具通过捕获SQL执行生命周期中的关键事件，使用户能够将数据库活动映射到更广泛的分布式追踪系统中，从而简化性能瓶颈的定位。
根据项目文档，pg_tracing支持PostgreSQL版本14、15和16，并提供了两种主要的追踪上下文传播机制：通过SQLCommenter作为SQL注释传递，或通过GUC参数pg_tracing.trace_context进行设置。该扩展在采样到的查询上生成Span，这些Span可以通过pg_tracing_consume_spans视图或pg_tracing_json_spans函数以OTLP JSON格式输出，便于集成到现有的可观测性平台中。
pg_tracing的追踪覆盖范围极为细致，它不仅记录SELECT、INSERT等标准语句的耗时，还将追踪深入到PostgreSQL的内部函数，包括Planner、ExecutorRun以及执行计划的每个节点，例如SeqScan或HashJoin。此外，对于触发器执行、并行工作进程以及事务提交过程中WAL的fsync时间，该扩展均会独立生成Span，提供了全面的操作视图。
要部署此扩展，用户需要使用PGXS编译，并将pg_tracing添加到postgresql.conf的shared_preload_libraries中，随后需要重启PostgreSQL服务才能激活。配置中包括`pg_tracing.otel_endpoint`参数，允许后台工作进程以设定的间隔（`pg_tracing.otel_naptime`）自动将收集到的Span通过OTLP协议发送至指定的OpenTelemetry收集器。
项目仓库同时提醒开发者，pg_tracing目前仍处于早期开发阶段，可能存在不稳定性，建议谨慎部署于生产环境。尽管如此，其对数据库内部执行流程的深度追踪能力，预示着其在数据库性能监控领域的潜力。
通过设置`pg_tracing.sample_rate`参数，用户可以控制追踪的采样率，例如设置为1.0即可追踪所有查询，这为在不影响整体性能的前提下进行故障排查提供了灵活性。这种基于扩展的、低侵入性的数据捕获方式，代表了数据库可观测性工程的一个重要发展方向。
pg_tracing的发布，是DataDog在基础设施监控领域持续深耕的一个体现，旨在填补传统APM工具在数据库内核级细节捕获上的空白。它使用户能够更精确地量化数据库内部操作对端到端事务延迟的影响。
