A readiness HTTP probe hits /healthz every few seconds, and the app logs every probe as INFO, drowning useful traffic logs. What is the most appropriate application-side response?
Select an answer to reveal the explanation.
Short Explanation
Probe chatter is like a smoke detector chirping every minute—you quiet the chirp, you do not rip out the detector. Tone down logging on the health path. Keep the readiness probe doing its job.
Full Explanation
Readiness HTTP probes that hit /healthz on a short period can flood INFO logs and bury useful fee or permitting traffic signals. The most appropriate application-side response is to keep the probe enabled for Service readiness while lowering verbosity for that path—filter /healthz from noisy INFO logging, log probes at DEBUG, or sample them—so operators retain both healthy traffic logs and a working readiness check. Civic platforms depend on readiness to keep unready Pods out of Endpoints; silencing the symptom by destroying the probe is the wrong trade.
Removing the readiness probe so logging becomes quiet fails because you lose the mechanism that prevents traffic to Pods not ready to serve, which can cause user-facing errors during rollouts. Setting container stdout to /dev/null fails because it discards all application diagnostics, not just probe noise, and cripples incident response. Switching the probe to exec with rm -rf /var/log fails both as a probe (destructive, non-idempotent, dangerous) and as a logging strategy; it does not address structured application logging and can harm the node/container filesystem.
Exam caveat: some meshes or sidecars add their own health noise—filter carefully so you do not hide real readiness failures. Operational check: confirm the probe still returns success via kubectl describe pod (Ready=True), adjust app logging config or access-log exclusions for /healthz, redeploy, and verify INFO logs again show business requests without per-period probe spam.