Today, we’re introducing Cloudflare Traces in open beta, extending automatic tracing beyond Workers to the rest of the request path. In one trace, you can see supported security rules, transformations, cache decisions, routing, Worker execution, and origin handling, then continue that trace through services running on Cloudflare, at your origin, or elsewhere in your stack.
This is a long-term investment in OpenTelemetry and in making Cloudflare the most observable part of your stack. You can now: Automatically trace requests across Cloudflare : Capture supported platform operations in one request-level timeline, no additional set up required. Control which requests are traced : Set a baseline sampling rate, then use Trace Rules to override it for matching traffic.
End-to-end trace context propagation: Accept and forward W3C traceparent headers Investigate traces in Cloudflare : View request timelines and span details directly in the Cloudflare dashboard. Export traces with OpenTelemetry : Send your spans to any destination with a compatible Open Telemetry Protocol (OTLP) endpoint . You can enable tracing in the Cloudflare dashboard on any domain or let your agent set up for you: Copy prompt Using the Cloudflare cf CLI, configure Tracing for my zone with a 10% sampling rate and persist traces in Cloudflare.
If I have multiple zones, ask me which one to use. Giving you the visibility we use to debug Cloudflare When our own teams investigate, we use our own internal traces, which often include thousands of spans for a single trace, generated by dozens of services and features. This lets us dig deep into every detail of a given request.
We don’t think that visibility should stop at our internal systems. Workers Tracing was our first step toward exposing what happens on our platform. Last year, we launched automatic instrumentation for Worker invocations, including outbound fetches and calls to KV, R2, D1, Durable Objects, and other Workers .
It shows the work performed inside the Workers runtime without requiring tracing code for every operation. The goal of Cloudflare Traces is to bring the same level of visibility to everyone using Cloudflare, whether you’re building on Cloudflare or just have Cloudflare in front of an origin. You get to see how your traffic moved through our platform, and connect the dots between how you’ve configured Cloudflare, and how this influences request processing time, routing decisions, and more.
Follow one request end to end A request’s path through Cloudflare can be complicated! It might pass through security rules, transformations, routing, caching, or proxied to another service entirely. Cloudflare Traces records each supported step as a span , including its timing, outcome, and relevant attributes.
Instead of reconstructing the request from separate logs and configuration, you can see the request’s path through our system in one place. You can answer questions like: Why was the request blocked or challenged, and which security rule took action? See when custom or managed rules evaluated the request, how long evaluation took, and the resulting action.
Identify the rule responsible for a block or challenge through its span events. Was the URL rewritten by a Transform Rule before it reached the application? You can open the http_request_transform span to see each change, the request component it affected, and the rule responsible.
You can also see where the transformation occurred relative to routing and origin handling. Which Page Rules, Snippets, or Workers handled or changed the request? The workers_routing span shows whether a route matched, which routing type was used, and the matching route pattern.
Was the response served from cache, and where was time spent between Cloudflare, the origin connection, and the application? You can expand nested cache, upstream, and origin spans to see where the request spent its time. Here, you can see there was a cache miss that went to origin and spent 527ms of the 539ms getting a response.
Configure your tracing There is no special instrumentation, config, or plugins required. Once tracing is enabled for a domain, Cloudflare generates these spans automatically. This lets you extend the trace through third-party services and back again by adhering to open standards .
From there, you can control which requests are traced using a baseline sampling rate and Trace Rules . Set a baseline sampling rate You can enable tracing on any domain and set a baseline sampling rate to balance visibility, data volume, and cost. You might trace 1% of requests during normal operation, giving you a continuous view of request behavior without collecting a trace for every request.
Configure Trace Rules Trace Rules let you keep a low baseline sampling rate while capturing complete traces for a specific investigation. If one customer reports a problem, you can trace 100% of traffic for their hostname, source IP, or identifying request header while leaving everyone else at 1%. Or during an investigation, you could trace 100% of requests carrying a temporary debug header, while leaving all other traffic at the baseline.
This lets you reproduce an issue without increasing tracing across the entire domain. Trace Rules use the same Cloudflare Rules language , so you can target paths, methods, headers, IP addresses, geographies, or combinations of those properties. Accept and propagate trace context One of the most common requests we hear is for true distributed tracing: a single trace that follows a request into Cloudflare, through our platform, and onward through the rest of your stack.
Cloudflare Traces can accept a W3C traceparent header from an incoming request, allowing Cloudflare spans to join a trace that began before the request reached our platform. An incoming propagation policy controls whether Cloudflare accepts that context. Cloudflare can also forward a new traceparent header to your origin .
Originally published at blog.cloudflare.com
