HAProxy Ingress Controller v3.1.14: Internal /healthz check logs cannot be suppressed via dontlog on specific backend #757
Description
The HAProxy Ingress Controller's internal health check traffic to the /healthz endpoint on its own default backend service is persistently flooding the logs, and all standard and highly specific HAProxy configuration directives have failed to suppress them.
This creates excessive log volume, particularly when running multiple replicas and external health checks (like a cloud LoadBalancer health check on /healthz via the service).
Environment
HAProxy Ingress Controller Version: v3.1.14
HAProxy Version: 3.1.9-38cc406
Kubernetes Version: v1.32.6
Installation Method: Helm (using the official chart)
Expected Behavior
Logs generated by requests routed to the controller's internal default backend service for the path /healthz should be suppressed using HAProxy configuration directives (e.g., option dontlog).
Actual Behavior
The log entries for the internal health checks persist despite highly specific configuration.
Log Evidence
The following log lines (or similar variations, indicating controller-to-controller checks hitting the internal default service) are continuously generated:
<Timestamp> <IP_Address> [16/Dec/2025:18:35:39.794] https~ haproxy-controller_svc_default-local-service_http/SRV_1 0/0/0/0/0 200 117 ... "GET 10.112.80.53:30166/healthz HTTP/2.0"
Troubleshooting Steps Taken (All Failed)
I have tested every available configuration method, including the use of an auxiliary ConfigMap (--aux-config-maps=...) for targeted injection:
- Standard HAProxy Directives (ConfigMap)
| Directive | Location | Result |
|---|---|---|
monitor-uri /healthz |
configDefaults |
Failed to suppress the internal controller checks. |
acl is_health ... http-request set-log-level silent if is_health |
configFrontend |
Failed to suppress final access log entry. |
option dontlog-normal |
Auxiliary ConfigMap (http-frontend & https-frontend) |
Failed to suppress final access log entry. |
- Specific Backend Log Suppression (Most Targeted Attempt)
Based on the log showing the traffic hitting the specific internal backend: haproxy-controller_svc_default-local-service_http, the most specific solution was attempted.
Auxiliary ConfigMap Snippet: - haproxy-aux.yaml
ConfigMap data:
backend-haproxy-controller_svc_default-local-service_http: |
option dontlog
Helm Configuration: The controller was started with the argument: --aux-config-maps=haproxy-controller/haproxy-aux-config
Result: Failed. Logs continued to appear.
- Controller Verbosity (extraArgs)
- Flag: --v=0 and --v=1
- Result: Failed. Did not suppress the HAProxy process-level logs.
Request
Please investigate why the option dontlog directive applied via the backend- auxiliary configuration is being ignored or overridden specifically for the generated HAProxy configuration block that defines the haproxy-controller_svc_default-local-service_http backend. This appears to be a bug in the configuration templating for internal service logs in v3.1.14.