Skip to content

[Bug]: Traffic logging and analytics stop silently when router.access_logs.enabled = false #3207

Description

@Tharsanan1

Please select the area the issue is related to

Gateway

Please select the aspect the issue is related to

Aspect/Logging (Log formats, instrumentation, improvements), Aspect/Configuration (Config files, settings, env vars, defaults)

Description

Setting router.access_logs.enabled = false silently disables traffic logging and analytics, even though both are enabled in configuration. No error or warning is logged anywhere — traffic logs simply stop appearing.

Disabling the router access log is a reasonable thing to want: it halves log volume under heavy traffic while traffic logging continues to provide the per-request record. Today the two are coupled, so that combination is impossible.

Root cause. gateway-controller/pkg/xds/translator.go gates all access-log sink creation on the stdout access-log toggle:

// Add access logs if enabled
if t.routerConfig.AccessLogs.Enabled {
    accessLogs, err := t.createAccessLogConfig()
    ...

createAccessLogConfig is the only place the gRPC ALS sink is built, and that ALS stream is the sole data source feeding the policy engine's collector — the policy engine publishes a traffic-log line (and an analytics event) only on receipt of an ALS entry. So an operator-facing log-formatting toggle also switches off the data path for two unrelated features.

Confirmed against the live Envoy config dump:

router.access_logs.enabled = true  → sinks attached: ['envoy.access_loggers.file', 'envoy.access_loggers.http_grpc']
router.access_logs.enabled = false → sinks attached: NONE

With the sink absent, five successful 200 invocations produced zero traffic-log lines.

Note the failure is entirely silent: traffic_logging.enabled = true and analytics.enabled = true are both accepted and validated, the collector starts, and nothing reports that it will never receive an event.

Steps to Reproduce

  1. Enable traffic logging and disable the router access log in gateway/configs/config.toml:

    [traffic_logging]
    enabled = true
    
    [router.access_logs]
    enabled = false
  2. Start the gateway and deploy any API.

  3. Invoke the API several times — all return 200.

  4. Check the runtime log:

    docker compose logs --since 10s gateway-runtime | grep -c correlationId
    # → 0
  5. Confirm no sink reached Envoy:

    curl -s http://localhost:9901/config_dump | \
      jq '[.configs[] | select(."@type"|test("ListenersConfigDump")) | .dynamic_listeners[]
           | .active_state.listener.filter_chains[].filters[].typed_config.access_log // []
           | .[].name] | unique'
    # → []
  6. Set enabled = true, restart, and invoke again — traffic logs reappear and both sinks are present.

Proposed fix

A fix is proposed in #3192, which decouples the two sinks: the gate becomes AccessLogs.Enabled || IsCollectorEnabled(), the file sink is created only when the stdout access log is enabled, the gRPC ALS sink only when the collector is enabled, and a failure to build the ALS sink becomes fatal rather than a logged warning that continues silently.

Severity Level of the Issue

Severity/Critical (Core functionality is broken but there is a workaround. Need urgent attention)

Environment Details (with versions)

API Platform 1.2.0 (reproduced on the 1.2.0 gateway images built from source)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions