Context-based logging with request ID #6899
Conversation
…equest_id package)
|
https://docs.aws.amazon.com/AmazonS3/latest/API/get-request-ids.html Should it be x-amz-request-id? |
I’m concerned that AWS uses short request IDs, such as "79104EXAMPLEB723", whereas currently we use generated UUIDs or accept request_id from external sources, for example x-amz-request-id from the minio-gateway. As for the format — UUIDs shouldn’t cause issues, but if we plan to use request_id exclusively in the x-amz format, we should consider implementing validation for incoming requests that include a request_id. |
|
Introduced the x-amz-request-id header and reused it across both HTTP and gRPC requests. This reduces confusion by unifying the request identifier across protocols. The change does not affect HTTP behavior, as header names are case-insensitive, but it's important for gRPC, which requires all metadata keys to be lowercase. |
What problem are we solving?
#6787
How are we solving the problem?
Introduce a requestid package:
Moved request ID constants and helpers (Get, Set, HTTP header) into a dedicated package to avoid circular imports and centralize logic.
Add context-aware logging methods:
Implemented InfoCtx, WarningCtx, ErrorCtx, FatalCtx, and related *fCtx, *lnCtx, *DepthCtx functions that automatically include request_id from context.
Non-breaking: existing logs remain unchanged:
All existing glog usage stays valid — migration to context-aware logging is optional and incremental.
No overhead if request ID is absent:
If the context doesn't contain a request_id, the log message is processed normally, without allocations or formatting overhead.
How is the PR tested?
Checks