Red Hat Connectivity Link

Use access logs for request correlation

Access logs give you detailed information about each request processed by the gateway, including timing, response codes, and request identifiers. For example, you can correlate requests across gateways, Authorino, Limitador, and backend services.

You can correlate request information with traces and application logs for a variety of uses. Request correlation uses x-request-id headers. These headers are automatically generated by Envoy for each incoming request. For example:

Access logs show the x-request-id.
Traces include the x-request-id as a span attribute.
Use a dashboard to jump from logs to traces and vice versa.

The following fields are the most important access-log fields for request correlation:

request_id (%REQ(X-REQUEST-ID)%): The unique request identifier generated by Envoy.
start_time** (%START_TIME%): The request start time for time-based correlation.
route_name** (%ROUTE_NAME%): The route that matched the request, which is useful for policy debugging.

Set up access log and tracing correlation

You can use access logs and tracing together to correlate requests. When you correlate request IDs, you can search for an ID once and see the entire journey from the initial access through to an event that you are investigating.

You can see the exact timing of a request as it entered and left each service. If you have configured user or organization-based IDs, you can also find who a problem is effecting so that you can rank your response.

The following configuration example tells WASM filters to log the x-request-id header value and enables request correlation across Envoy, Authorino, Limitador, and WASM logs.

Prerequisites

You installed Connectivity Link.
You have a running OpenShift Container Platform cluster.
You have administrator access to the OpenShift Container Platform cluster.
You enabled access logs and tracing.

Procedure

To enable request correlation across Connectivity Link components, configure the httpHeaderIdentifier in the Kuadrant CR:

apiVersion: kuadrant.io/v1beta1
kind: Kuadrant
metadata:
  name: kuadrant
  namespace: kuadrant-system
spec:
  observability:
    dataPlane:
      httpHeaderIdentifier: x-request-id
    tracing:
      defaultEndpoint: rpc://tempo.tempo.svc.cluster.local:4317
      insecure: true

You can correlate logs across all components using the x-request-id, by using the following examples:

View the following Envoy access log entry:

{
  "start_time": "2026-01-23T15:45:12.345Z",
  "method": "GET",
  "path": "/api/users",
  "response_code": 200,
  "request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "route_name": "toystore-route"
}

Correlate the following Authorino log entry with the Envoy access log:

{"level":"info","ts":"2026-01-23T15:45:12.350Z","request_id":"a1b2c3d4-e5f6-7890-abcd-ef1234567890","msg":"auth check succeeded","identity":"alice"}

Correlate the following Limitador log entry with the Envoy and Authorino logs:

Request received: ... "x-request-id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890" ...

When you combine the three logs, the story of this request_id is:
- At 15:45:12, a user named alice requested the users' API, /api/users. You can also see the request_id of a1b2c3d4-e5f6-7890-abcd-ef1234567890.
- The request hit the toystore-route in Envoy.
- Envoy paused the request and checked authentication with Authorino, see level and info.
- Authorino verified Alice’s identity: auth check succeeded, identity, alice.
- Simultaneously, Limitador noted the request to ensure that Alice did not exceed her allowed limit.
- Finally, Envoy allowed the traffic through, resulting in a 200 response code.