You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Proposal: gRPC / RPC conventions based on cross-SDK review
We recently did a cross-SDK review of all existing gRPC integrations (internal notes) and found significant divergence in span ops, attribute names, and span naming. Proposing we settle conventions here, using the Go SDK as the reference since it already aligns closely with OTel.
rpc.client for outgoing calls, rpc.server for incoming. The rpc.* namespace keeps it generic enough to cover other RPC systems in the future (Twirp, Connect, etc.).
Span origin
auto.rpc.grpc — category rpc, subsystem grpc.
Span name
pkg.Service/Method — stripped of leading slash, no call-type prefix. Matches OTel convention and is consistent with how gRPC itself formats method names.
Trace propagation
Inject/extract sentry-trace and baggage via gRPC metadata (the gRPC equivalent of HTTP headers).
Method name parsing
Full gRPC method strings have the format /pkg.Service/Method. Parse into:
rpc.service = pkg.Service
rpc.method = Method
Span name = pkg.Service/Method (strip leading slash only)
sentry-python: span op, origin, span name, and attribute keys all need updating. Changing span op is potentially breaking for dashboards/queries — needs migration strategy (dual-emit or major version).
sentry-javascript: GCP integration uses service-specific ops; minor scope, but should align if expanded.
sentry-dotnet: no tracing yet, so nothing to migrate — new implementation can start clean.
Open questions for this issue to resolve
Do we formally adopt OTel RPC semconv attributes or define our own?
Should non-OK gRPC status codes always produce a Sentry error event, or only annotate the span? (Currently varies per SDK.)
What streaming call types are required to claim gRPC support? (sentry-go covers all 4; sentry-python sync only covers unary-unary.)
Do these conventions extend to other RPC systems (Twirp, Connect RPC, gRPC-web)?
Go SDK is a good working reference — happy to pull its implementation into a formal spec here if that's the right format.
Should we use rpc.grpc.* for anything related to grpc? that way we could group anything related to grpc, while following some bits from open telemetry
If we do grpc.* we will end up with two data groups, the ones starting with rpc.* and another group as grpc.*
Activity
linear commentedon Jul 31, 2025
CON-56 RPC
sentry-junior commentedon May 29, 2026
Proposal: gRPC / RPC conventions based on cross-SDK review
We recently did a cross-SDK review of all existing gRPC integrations (internal notes) and found significant divergence in span ops, attribute names, and span naming. Proposing we settle conventions here, using the Go SDK as the reference since it already aligns closely with OTel.
Current state across SDKs
rpc.client/rpc.serverrpc.grpc.status_code(int)auto.rpc.grpcpkg.Service/Methodgrpc.client/grpc.serverrpc.response.status_codeauto.grpc.grpcunary unary call to /pkg.Svc/Methodgrpc.{service}auto.grpc.serverlessProposed conventions (OTel-aligned)
Based on OTel RPC semantic conventions:
Span attributes
rpc.system"grpc"rpc.service"pkg.Service"rpc.method"Method"rpc.grpc.status_code0for OK,2for UnknownSpan op
rpc.clientfor outgoing calls,rpc.serverfor incoming. Therpc.*namespace keeps it generic enough to cover other RPC systems in the future (Twirp, Connect, etc.).Span origin
auto.rpc.grpc— categoryrpc, subsystemgrpc.Span name
pkg.Service/Method— stripped of leading slash, no call-type prefix. Matches OTel convention and is consistent with how gRPC itself formats method names.Trace propagation
Inject/extract
sentry-traceandbaggagevia gRPC metadata (the gRPC equivalent of HTTP headers).Method name parsing
Full gRPC method strings have the format
/pkg.Service/Method. Parse into:rpc.service=pkg.Servicerpc.method=Methodpkg.Service/Method(strip leading slash only)Go reference:
parseGRPCMethodMigration impact for existing SDKs
Open questions for this issue to resolve
Go SDK is a good working reference — happy to pull its implementation into a formal spec here if that's the right format.
lucas-zimerman commentedon Jun 3, 2026
Should we use
rpc.grpc.*for anything related to grpc? that way we could group anything related to grpc, while following some bits from open telemetryIf we do
grpc.*we will end up with two data groups, the ones starting withrpc.*and another group asgrpc.*cleptric commentedon Jun 3, 2026
We use whatever Otel does, https://opentelemetry.io/docs/specs/semconv/rpc/grpc/.