Traceparent header for troubleshooting
Overview
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.
Info
Currently, we only pass on the tracestate request header, which is also part of the same specification, without changing it.
How it works
Request header
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.
Response header
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.
Traceparent in raw logs
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:
In this case:
d5fe1dc9035165ce36952daf29686b6c
represents the 16-byte array (trace-id)14330be33197dd1a
denotes the 8-byte array (parent-id)