The built-in vcl_log subroutine is executed after the response to the client has finished, and therefore has access to data about the final state of the request, and timing information about the response. Because it is not executed within the critical path of the VCL flow, it is the preferred place to transform and output data to a log endpoint using the log statement.

HINT: Logs emitted from VCL are routed to your configured endpoint via a syslog processor. To ensure that the log reaches the right endpoint, the message must be prefixed with your service ID and endpoint name. The service ID is available as a VCL variable, which can be used for convenience. For example:

log "syslog " req.service_id " my-endpoint-name :: ACTUAL LOG TEXT HERE";

When creating a log endpoint, Fastly will automatically generate a log statement for you, which sends a log line to that endpoint for every request. You can disable this behavior by setting the placement property of the log endpoint to "none" when creating the endpoint.

Shielding considerations

If using shielding, i.e. each request normally passes through two Fastly POPs, then the full VCL flow will be executed at both the edge POP and the shield POP. For requests that do not find a hit in the cache at the edge, this may result in double logging. To avoid logging at the shield, consider wrapping the log statement in a check of fastly.ff.visits_this_service:

if (fastly.ff.visits_this_service == 0) {
log "....";

Alternatively, consider generating a random request ID (for example using uuid.version4) at the edge and including it in the log statement at the edge and the shield, allowing for matching and deduplication of the data in later analysis.

State transitions

  • return(deliver)

To see this subroutine in the context of the full VCL flow, see using VCL.

Tokens available in this subroutine

The following limited-scope VCL functions and variables are available for use in this subroutine (those in bold are available only in this subroutine):