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
-
Enable traffic logging and disable the router access log in gateway/configs/config.toml:
[traffic_logging]
enabled = true
[router.access_logs]
enabled = false
-
Start the gateway and deploy any API.
-
Invoke the API several times — all return 200.
-
Check the runtime log:
docker compose logs --since 10s gateway-runtime | grep -c correlationId
# → 0
-
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'
# → []
-
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)
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 = falsesilently 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.gogates all access-log sink creation on the stdout access-log toggle:createAccessLogConfigis 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:
With the sink absent, five successful
200invocations produced zero traffic-log lines.Note the failure is entirely silent:
traffic_logging.enabled = trueandanalytics.enabled = trueare both accepted and validated, the collector starts, and nothing reports that it will never receive an event.Steps to Reproduce
Enable traffic logging and disable the router access log in
gateway/configs/config.toml:Start the gateway and deploy any API.
Invoke the API several times — all return
200.Check the runtime log:
Confirm no sink reached Envoy:
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)