Feature request: Open Telemetry tracing supporting database Semantic Conventions + GCP conventions

[michaelsafyan]

Feature Description

For users of Cloud SQL Auth Proxy who also use trace observability with or without Cloud Trace, it would be ideal if Cloud SQL Auth Proxy were instrumented in such a way as to:

• Emit client spans in OTLP format that conform to OTel DB Semantic Conventions
• Support wiring to telemetry.googleapis.com (or regionalized endpoints thereof)
• Support wiring to 3rd party or user-supplied OTel Collectors via standard OTel environment variables or OTel declarative config
• Include resource attributes aligned with GCP resource detectors
• Propagate W3C TraceContext
• Include GCP-specific span attributes as appropriate such as the gcp.resource.name attribute identifying the canonical resource name of the destination database being operated on

See also:

• https://opentelemetry.io/docs/specs/semconv/database/database-spans/
• https://opentelemetry.io/docs/specs/semconv/database/mysql/
• https://cloud.google.com/stackdriver/docs/reference/telemetry/overview
• https://cloud.google.com/trace/docs/migrate-to-otlp-endpoints
• https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/
• https://opentelemetry.io/docs/languages/sdk-configuration/general/
• https://github.com/open-telemetry/opentelemetry-configuration
• https://opentelemetry.io/blog/2023/sunsetting-opencensus/

Sample code

No response

Alternatives Considered

No response

Additional Details

Happy to discuss more privately over GVC regarding the context and motivation behind the request.

[enocom]

Drive by comment: we've been working on migrating to OTel for the AlloyDB Proxy. I believe the Cloud SQL team has the same item planned somewhere in their backlog.

Meanwhile, any support for OTel here would purely be for control plane interactions. The actual queries to and from the database are treated as opaque bytes, and unless the Cloud SQL Proxy adds protocol awareness, I'm not sure how useful tracing support would be.

Cf. https://github.com/GoogleCloudPlatform/alloydb-go-connector/pull/664 (which gets pulled into the AlloyDB Auth Proxy). I imagine Cloud SQL will eventually be doing the same.

[michaelsafyan]

Any sense of what the overhead/cost would be of adding protocol awareness to the proxy?

Injecting tracing would be quite handy. But if the cost is high, perhaps done via opt-in?

[enocom]

The cost would be high (especially for Cloud SQL which supports three database engines) and would likely affect performance too. Right now, can clients instrument their Postgres drivers without much work?