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

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)

Start in gateway-controller/pkg/xds/translator.go, focusing on the access-log gate and createAccessLogConfig, then trace IsCollectorEnabled and the policy engine collector. Verify the Envoy config and reproduction steps with router access logs disabled; done means traffic logging and analytics still receive events while the stdout sink remains disabled, with ALS creation failures surfaced appropriately.