We have initiated support for the traceparent HTTP header, as outlined in the W3C Trace Context specification. This move is aimed at standardizing the methods of transmitting and modifying tracing information between services.
Currently, we only pass on the tracestate request header, which is also part of the same specification, without changing it.
The traceparent header comprises four fields: version
, trace-id
, parent-id
, and trace-flags
. They are detailed in Augmented Backus-Naur Form (ABNF) notation and identify incoming requests in a tracing system.
We are able to receive traceparent request headers that are sent to us by clients. In the Gcore Edge Network, the only field that can be changed is the parent-id
, while the trace-id
stays the same. We then forward the traceparent header to your original location. So, you can rest assured that the route won't be lost as it moves through the CDN.
If the traceparent request header isn't utilized on your end or is in the wrong format, we will generate it according to the specification.
The traceparent response header is always included in the set of headers for requests processed through our network. You can locate the value using browser debug tools (e.g., Chrome DevTools) or curl.
You can use the traceparent response header to track the request or send it to technical support for troubleshooting.
We have extended the support for the traceparent header to Raw Logs. You can find the sample of the traceparent header in the Raw Logs guide by searching the $http_traceparent
field. In a nutshell:
00-d5fe1dc9035165ce36952daf29686b6c-14330be33197dd1a-01
In this case:
d5fe1dc9035165ce36952daf29686b6c
represents the 16-byte array (trace-id)14330be33197dd1a
denotes the 8-byte array (parent-id)Was this article helpful?
Learn more about our next-gen CDN