Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

spanner_v1/trace: allow option for extended tracing which will allow recording the SQL statement if provided #1171

Open
odeke-em opened this issue Jul 24, 2024 · 0 comments · May be fixed by #1172
Open

spanner_v1/trace: allow option for extended tracing which will allow recording the SQL statement if provided #1171

odeke-em opened this issue Jul 24, 2024 · 0 comments · May be fixed by #1172
Assignees
@ankiaga
Labels
api: spanner Issues related to the googleapis/python-spanner API.

Comments

@odeke-em
Copy link

Part of modernized tracing is that it becomes pretty useful for customers to investigate slow queries when observing traces; customers would like to opt-in to ensure that this library records their SQL statements in their traces where applicable e.g. if they've explicitly opted into having their spans annotated with the SQL statement; explicitly because some SQL statement might have personally identifiable information (PII) and leak sensitive data out.

I am going to work on this issue myself.
@product-auto-label product-auto-label bot added the api: spanner Issues related to the googleapis/python-spanner API. label Jul 24, 2024
@odeke-em odeke-em linked a pull request Jul 26, 2024 that will close this issue
Open
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Jul 26, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
b83a4df 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Jul 26, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
13f4dbf 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Jul 29, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
7ab3add 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Jul 30, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
8454eae 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Jul 31, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
9a315b9 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Aug 9, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
a62ee3e 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Aug 19, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
e69bccf 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
odeke-em added a commit to odeke-em/python-spanner that referenced this issue Sep 10, 2024
@odeke-em
fix: use modernized and standardized OpenTelemetry when tracing
51caf4e 
This change modernizes trace span attributes by using OpenTelemetry's
semantic conventions that are standardized and allow for much
better common ground adoption by broader systems, even more as
Google Cloud Tracing & Monitoring pushes towards OpenTelemetry more.

With this change we've made the replacement of these fields, directly
with imports from `opentelemetry.semconv.trace.SpanAttributes`, as:

* "db.type"       => DB_SYSTEM aka "db.system"
* "db.url"        => DB_CONNECTION_STRING aka "db.connection_string"
* "db.instance"   => DB_NAME aka "db.name"
* "net.host.name" => NET_HOST_NAME aka "net.host.name"

While here, also updated opentelemetry-(api, sdk) dependencies to use
versions "1.25.0", then opentelemetry-(instrumentation) to "0.46b0"

Also added in an option toggled by environment variable

    ENABLE_EXTENDED_TRACING=true

which allows spans to be annotated with the SQL statement keyed by

    "db.statement"

Fixes googleapis#1170
Fixes googleapis#1171
Fixes googleapis#1173
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ankiaga ankiaga

Labels
api: spanner Issues related to the googleapis/python-spanner API.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: use modernized and standardized OpenTelemetry when tracing odeke-em/python-spanner
2 participants
@odeke-em @ankiaga