-
Notifications
You must be signed in to change notification settings - Fork 19
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.
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
add a Parent-Request-Id header #1365
Conversation
This provides better observability for RPC call chains by having callers include their own generated requestId (if one exists) on new outbound requests. Receivers can log the `Parent-Request-Id` header value. This should allow for observing the operations that generated a request to an endpoint by following `Parent-Request-Id` pointers backwards, without needing to view observability data for the entire traceId, which may be very large.
Generate changelog in
|
tracing-api/src/main/java/com/palantir/tracing/api/TraceHttpHeaders.java
Show resolved
Hide resolved
* For traces initiated with span type {@link SpanType#SERVER_INCOMING}, | ||
* this header will be set to the requestId generated for that trace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having trouble parsing this sentence. Perhaps something like:
The {@code Parent-Request-Id} header represents the requestId of the caller, if present. This provides a direct causal connection between requests up a call stack. This can be an advantage over traceId which provides a broad set of data without information to understand the call pathing unless spans are sampled.
"defaultTraceId", | ||
Optional.of("forUserAgent"), | ||
"rootOperation", | ||
SpanType.SERVER_INCOMING); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can capture the requestId value here, and assert equality below rather than isNotBlank()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
Released 6.21.0 |
Before this PR
Traces created with a span type of
SERVER_INCOMING
generate a requestId, which is useful for observing operations on a service related to handling a particular inbound request. However, that requestId is local to the service itself, and doesn't allow for easily following RPC call chains in observability data. While the traceId does allow for this, it can sometimes be overly noisy and doesn't allow for easily tracing through RPC calls themselves.After this PR
add a Parent-Request-Id header
This provides better observability for RPC call chains by having callers include their own generated requestId (if one exists) on new outbound requests. Receivers can log the
Parent-Request-Id
header value. This should allow for observing the operations that generated a request to an endpoint by followingParent-Request-Id
pointers backwards, without needing to view observability data for the entire traceId, which may be very large.==COMMIT_MSG==
add a Parent-Request-Id header
==COMMIT_MSG==
Possible downsides?
Extra header means more bytes on the wire, but should be small.