Skip to content

feat(tracing-spans): add otel.kind = "client" for OpenTelemetry compatibility #2937

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
Open
uuushiro wants to merge 1 commit into
base: master
Choose a base branch
from
Open

feat(tracing-spans): add otel.kind = "client" for OpenTelemetry compatibility #2937

uuushiro wants to merge 1 commit into from
+1 −0

Conversation

@uuushiro
Copy link
Contributor

@uuushiro uuushiro commented Feb 1, 2026 •
edited
Loading

Summary

This PR adds otel.kind = "client" to the db_span! macro, ensuring DB spans are properly recognized as Client spans by OpenTelemetry-compatible APM tools.

Problem

When using tracing-opentelemetry as the bridge between tracing and OpenTelemetry, DB spans created by sea-orm are not recognized as database client calls because:

  • tracing-opentelemetry uses the otel.kind field to determine SpanKind
  • Without this field, spans default to SpanKind::Internal
  • APM tools (Datadog, Jaeger, etc.) use SpanKind::Client + db.system attribute to identify DB operations

Solution

Add otel.kind = "client" to the db_span! macro. This is the documented approach for setting SpanKind via tracing spans.

Changes

::tracing::info_span!(
    $name,
    otel.kind = "client",  // Added
    db.system = ...,
    db.operation = ...,
    ...
)

@uuushiro
Add otel.kind = "client" to db_span! macro for OpenTelemetry compatib…
4f41ab2 
…ility

This ensures DB spans are recognized as Client spans by OpenTelemetry-compatible
APM tools (Datadog, Jaeger, etc.), enabling proper DB span visualization and
SQL query tracking.

The tracing-opentelemetry crate uses the otel.kind field to determine SpanKind.
Without this, spans default to Internal and may not be properly categorized
as database operations by APM backends.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Huliiiiii Huliiiiii Huliiiiii approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@uuushiro @Huliiiiii