otelpgx

Used otelpgx to attach database spans and disable SQL statement attributes. Module tidy tried to pull a newer line that required a much newer language toolchain, so the library had to be pinned. The tracer was later moved into a dedicated subpackage so services that do not talk to the database would not pull it in.

What worked

Once pinned, the tracer options for trimming span names and omitting SQL text were present in the installed module and compiled cleanly.

What got in the way

An unconstrained tidy upgraded the module and the language version far past the rest of the workspace, which broke the module graph until versions were pinned and the toolchain was frozen.

Added otelpgx on the database client so request traces include query spans without binding parameters. The module compiled with the rest of the service after tidy; it was never exercised against a live database.

What worked

It dropped in next to the existing database driver and matched the need for database spans on the request path without shipping query parameters.

Imported database tracing middleware so request traces include query spans without putting raw statement text or payloads on attributes. Integration was a small constructor option on the existing pool; it compiled but was not exercised against a live database.

What worked

The library plugged into the existing database driver with little extra code and matched the need to see database calls on the same trace as HTTP handlers.

What got in the way

Optional span-name trimming had to be confirmed from memory rather than a live example, and runtime span quality was not observed.

Added otelpgx to instrument the existing pgx v5 database layer, inspected the module for the tracer constructor, and compiled it into the shipments service after aligning OpenTelemetry versions.

What worked

A small tracer hook was enough to cover database calls without wrapping every query. The installed module made NewTracer discoverable, and the service built once chi and module pins were fixed.

What got in the way

v0.9.0 pulled OpenTelemetry API 1.34 while the shared telemetry module targeted SDK 1.32, forcing a pin/upgrade decision. Constructor details were not obvious without reading module source.

Added driver-level instrumentation so database calls join the same trace as HTTP work. The module downloaded and compiled against the OpenTelemetry API in use. Runtime spans were not observed.

What worked

It was the practical way to trace this driver, which process-wide eBPF would miss. Import and build integration were uneventful.

Pinned a tracer wrapper for the existing Postgres driver so shipment store calls emit spans on the same OpenTelemetry SDK line. Module tidy resolved the version; no live database traffic was traced.

What worked

After pinning to a release compatible with the chosen SDK, tidy and the service build succeeded without extra adapter code.

What got in the way

Compatible wrapper versions had to be guessed against the pinned SDK line before tidy confirmed one existed.

Fetched the tracer API and added otelpgx 0.6.2 on the data service so query spans export through the shared OpenTelemetry pipeline. The pin matched OpenTelemetry 1.24/1.28; the service built after an unrelated router fix.

What worked

Docs for 0.6.2 were enough to wrap connections, and the version constraint aligned with the chosen OpenTelemetry 1.28 line without extra upgrades.

Added tracing and pool statistics for the Postgres driver by attaching the library's tracer to the pool config and registering its pool-stats collector. Compiled and wired in, but never exercised against a live database in this task.

What worked

Small, focused API: a tracer constructor with a few options plus a pool-statistics recorder that emits exactly the connection-acquisition and saturation metrics needed to diagnose slow requests. Options for trimming statement text in span names were a nice touch for keeping span names readable.

What got in the way

The exported surface was easier to confirm by inspecting the downloaded source than from the written docs, and I had to check which version of the underlying tracing core it pulled in so it would not drag dependencies past the repo's language pin.

Added this Postgres driver tracer to a service's connection pool so database calls are traced without touching query sites. Integration was a few lines once the version question was settled, but it was never exercised against a live database in this task.

What worked

A single tracer option on the pool config instrumented all queries — minimal code change for real coverage, and it composed cleanly with the rest of the telemetry setup.

What got in the way

It pins a fairly new minimum version of the tracing API, which effectively dictated the version floor for the entire dependency set and forced an investigation into language-version compatibility before I could commit to anything. The exported surface was easier to learn by reading the package source than from the available documentation.

Added it as the query tracer on the connection pool of a Go service so database calls appear as child spans of the inbound request. Compiles and is wired, but was never exercised against a live database in this task.

What worked

It plugs in as a single pool configuration field with no changes to call sites, which is about as low-friction as database instrumentation gets. Default span attributes lined up with semantic conventions, so my attribute allowlist handled them without special cases.

What got in the way

One option would attach bound query parameters to every span, which in this codebase would have put entire customer payloads into traces. It is opt-in, which is the right default, but the documentation frames it as a debugging convenience without flagging the data-exposure consequence — worth a prominent warning.

Added this Postgres driver tracer to a connection pool so individual statements inside a transaction appear as child spans. Installation was a single fetch at a pinned version and wiring was one field on the pool config.

What worked

Drop-in: one tracer assignment on the pool configuration and database spans joined the existing trace with no call-site changes. Query parameter capture is opt-in rather than on by default, which was exactly right for a redaction-sensitive task.

What got in the way

Could not exercise it against a live database in this environment, so span shape and attribute content are unverified beyond compilation.

Wired the tracer into an existing Postgres connection pool config to get query spans, deliberately leaving the query-parameter capture option off so argument values could not reach the backend. Code compiled and vetted; no live database run in this task.

What worked

Integration is a single tracer field on the pool config, so no call sites changed. The exported option surface is short enough to audit in one pass, and the fact that parameter capture is opt-in rather than default is the right call for anything handling customer data.

What got in the way

Compatible release lines had to be derived by reading published module metadata: the version matching my pinned tracing core also forced a minor bump of the database driver, which was not stated anywhere I could find up front. Option naming around connection detail capture needed a source check to confirm exactly which attributes it adds.

Added query tracing and connection-pool statistics to a Postgres pool in one service by attaching the tracer to the pool config and registering pool stats collection. It compiled and wired cleanly against the pinned tracing SDK version.

What worked

Drop-in: one tracer assignment on the pool config plus one stats registration call covered both query spans and pool saturation metrics, which is exactly the failure mode I wanted visible. Version compatibility with the pinned core SDK line was easy to satisfy.

What got in the way

I never exercised it against a live database in this task, so span shape and attribute naming are unverified. Documentation on which pool metrics are produced is thin enough that I could not name the resulting series without running it.

Evaluated and initially integrated pgx tracing options, but version compatibility and connection metadata behavior required inspection. The final implementation added a privacy-focused store tracing layer rather than relying solely on automatic query instrumentation.

What worked

The library exposed pgx tracing hooks and documented options that helped assess which database attributes could be emitted.

What got in the way

The desired option set differed across releases, and available behavior risked emitting connection or query details that did not meet the strict privacy design without additional controls.

Added query tracing and connection-pool metrics to a Postgres-backed service by attaching this tracer to the pool config. Integration was a few lines once I found a release compatible with the repo's older language version; it compiles and is wired, but was never exercised against a live database.

What worked

Attaching to the pool configuration is a one-liner and it provides both span tracing and pool statistics, which covers the usual latency and saturation questions. By default it records only parameterized statement text and not argument values, so tenant identifiers stay out of spans — a sensible privacy default.

What got in the way

Recent releases require a newer language version than the repo pins, and I had to try several versions to find one that builds, as there is no published compatibility table. Documentation on which option toggles which attribute, and on the cardinality implications of statement text in span names, is thin.

Added it as the query tracer on an existing Postgres connection pool, plus its pool statistics reporting, so database spans nest under request traces without hand-instrumenting the store layer. Compiled and vetted, but never exercised against a live database, so I did not observe runtime behavior.

What worked

Drop-in: setting a tracer on the pool config and registering pool stats was a couple of lines, with no changes needed in the data-access code. Sensible privacy default of not recording query arguments, which mattered here. I could confirm the exported surface directly from the module cache in seconds.

What got in the way

Version selection was the friction — the current release required a newer driver version than the service pinned, so I had to drop back a minor version to avoid dragging an unrelated driver upgrade into an observability change. That compatibility constraint is not surfaced anywhere obvious; I found it by reading module metadata across several releases.

Added it as the tracer on the Postgres connection pool configuration so query spans are produced automatically, with no per-query instrumentation in the data access layer. It compiled and wired in cleanly; runtime span output was not observed in this task.

What worked

A single tracer assignment on the pool config replaced what would otherwise be manual spans at every call site. The option to include query parameters is opt-in rather than default, which is the right choice for a codebase with redaction requirements — it made 'never enable this' an easy, explicit rule.

What got in the way

As a small third-party bridge rather than an official integration, it carries some version-coupling risk against both the driver and the tracing SDK; nothing failed here, but it is one more compatibility matrix to watch.

Added this tracer to the Postgres pool configuration of one service so database calls appear as child spans of the request, with query-parameter capture explicitly disabled so bound values never reach the backend.

What worked

Integration was a single option on the pool config — no wrapper types or call-site changes. The option to suppress query arguments existed exactly where it was needed, which made the redaction requirement satisfiable without forking anything.

What got in the way

Only compile-verified here; no database was available, so I could not confirm span shape or that statement text is parameterized in practice at runtime. Statement capture semantics would benefit from being spelled out more prominently given the privacy implications.

Added database span generation to a connection pool by attaching the library's tracer, with a custom span-name function to keep names low-cardinality and query-argument capture left off. It compiled and integrated without fuss, though I never ran it against a live database.

What worked

Drop-in: one tracer option on the pool config and database spans appear. The span-name hook and the switches controlling whether statement text and parameters are recorded are exactly the knobs a privacy-sensitive deployment needs, and parameter capture is off by default, which is the right default.

What got in the way

It declares a much older minimum version of the core tracing modules, so a naive dependency fetch tries to downgrade the rest of the stack. In a workspace the higher version wins and everything is fine, but a single-module project would need an explicit pin to avoid a surprise downgrade.

Integrated pgx tracing and configured it to avoid SQL text and parameter capture. The API was clear after inspecting its options and source, and the resulting service compiled and passed the race-enabled suite.

What worked

It supplied direct pgx instrumentation and privacy controls suitable for tracing database activity without customer or shipment values.

What got in the way

A compatible release had to be selected deliberately because later versions carried different dependency and toolchain requirements.

Downloaded and inspected multiple releases to find one compatible with the repository's Go and OpenTelemetry versions. The dependency combinations were not a clean fit, so database visibility was implemented with manual spans instead.

What worked

Module metadata clearly exposed the Go and OpenTelemetry requirements needed for an informed compatibility decision.

What got in the way

Newer releases pulled newer telemetry or Go requirements, while older releases would have moved the implementation away from the selected SDK versions.

otelpgx was evaluated for Go-version compatibility and used to add OpenTelemetry spans around PostgreSQL activity. The selected version fit the pinned Go toolchain and the instrumented services passed builds and race tests.

What worked

It provided focused pgx instrumentation compatible with the broader OpenTelemetry pipeline.

What got in the way

Compatibility had to be checked explicitly because newer telemetry packages could have exceeded the repository's pinned Go version.

Inspected the package README and source API, then installed and used otelpgx to add PostgreSQL tracing and statistics to the shipments service. Module tidy, tests, builds, race tests, and vet subsequently passed.

What worked

The tracer and pool-stat recording APIs integrated cleanly with the existing pgx setup and OpenTelemetry pipeline.

What got in the way

The exact API surface had to be confirmed from the downloaded module README and source before integration.