What's the user value of this feature request?
A single CLI command may result in multiple CAPI API requests. A unique id (vcap-request-id) is generated by go-router per api request that allows tracing issues through the system.
However, if you want to trace ALL requests for a particular CF CLI command you cannot, since there is no trace id that is per command and not per API call. This makes it hard to debug issues with the CLI, or to understand all the requests made for a single command (e.g. cf push).
The CLI should generate a unique ID per command and utilise the distributed b3 trace headers, see here.
This means if there is an issue, a developer can run CF_TRACE=true and see the generated b3 trace headers which can then be correlated to logs in the CF system by opeators.
Headers to set:
X-B3-Traceid - 128-bit in length and indicates the overall ID of the trace. Every span in a trace shares this ID. The X-B3-TraceId header is encoded as 32 lower-hex characters.
X-B3-Spanid - 64-bit in length and indicates the position of the current operation in the trace tree. The X-B3-SpanId header is encoded as 16 lower-hex characters.
These then will be logged in different CF components, including CAPI, e.g. capi log
Who is the functionality for?
Operators debugging CF issues.
Who else is affected by the change?
Currently b3 headers are generated by go-router, this would mean that CLI requests no longer contain unique b3 headers per request but rather per command.
What's the user value of this feature request? A single CLI command may result in multiple CAPI API requests. A unique id (vcap-request-id) is generated by go-router per api request that allows tracing issues through the system.
However, if you want to trace ALL requests for a particular CF CLI command you cannot, since there is no trace id that is per command and not per API call. This makes it hard to debug issues with the CLI, or to understand all the requests made for a single command (e.g. cf push).
The CLI should generate a unique ID per command and utilise the distributed b3 trace headers, see here.
This means if there is an issue, a developer can run
CF_TRACE=true
and see the generated b3 trace headers which can then be correlated to logs in the CF system by opeators.Headers to set:
These then will be logged in different CF components, including CAPI, e.g. capi log
Who is the functionality for? Operators debugging CF issues.
Who else is affected by the change? Currently b3 headers are generated by go-router, this would mean that CLI requests no longer contain unique b3 headers per request but rather per command.