DataDog未显示PostgreSQL BEGIN查询，如何配置使其显示？

问题背景 #

运行于Gunicorn的Django站点默认启用原子数据库事务，已按DataDog文档配置Postgres与Python链路追踪，但仅能观测到事务COMMIT的Postgres Span，BEGIN查询缺失；同时/health端点无SQL查询却被事务包裹，存在单次追踪耗时9ms但偶尔延迟达10秒的响应时间“黑洞”。

让DataDog显示BEGIN查询的解决方法 #

1. 开启事务语句追踪配置 #

通过环境变量或代码配置开启ddtrace对PostgreSQL事务控制语句的采集：

• 环境变量方式：启动Gunicorn时添加环境变量：

  DD_POSTGRES_TRANSACTION_STATEMENTS=true ddtrace-run gunicorn your_project.wsgi:application
  

• 代码手动配置：在Django的settings.py或启动脚本中添加：

  from ddtrace.contrib.psycopg2 import patch
  # 开启事务语句追踪
  patch(trace_transaction=True)
  

2. 处理Django隐式事务的情况 #

Django的@transaction.atomic或全局ATOMIC_REQUESTS=True会触发隐式事务，可能不会执行显式BEGIN语句，而是依赖Postgres自动事务模式：

• 开启DjangoDEBUG模式或调整Postgres日志级别（log_statement = 'all'），确认事务开启的实际执行逻辑；
• 若为隐式事务，可通过DataDog的自定义Span来标记事务开始事件，比如在视图或中间件中添加：

  from ddtrace import tracer
  with tracer.trace('django.transaction.begin', service='postgres'):
      pass
  

3. 调整DataDog采样规则 #

确保事务相关Span未被过滤，修改DataDog Agent的datadog.yaml配置：

apm_config:
  default_sample_rate: 1.0
  span_rules:
    - name: postgresql.query
      sample_rate: 1.0

关于/health端点响应延迟的补充提示 #

该端点无SQL却被事务包裹，大概率是Django全局ATOMIC_REQUESTS=True导致每个请求自动开启事务。开启BEGIN查询追踪后，可直接观测事务开启阶段的耗时，定位是否为数据库连接池等待、Postgres事务锁等隐藏延迟导致的“黑洞”。

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