A containerized civic chatbot that posts to Webex must follow the 12-factor logging tenet. How should the process emit log events?
Select an answer to reveal the explanation.
Short Explanation
Treat logs like a firehose the platform catches—not a binder the app files and rotates itself. stdout/stderr keeps the process disposable; self-managed /var/log files fight the tenet.
Full Explanation
Twelve-factor style logging for containers writes events to stdout and stderr so the platform’s log driver or collector ships and stores the stream. The process stays disposable: no local log files to rotate, no sticky node state, and every replica of the municipal API contributes to one operational picture. Opening /var/log/myapp.log, rotating inside the app, and truncating nightly fights that model—ephemeral filesystems lose history on restart, and operators must chase node-local paths. FTPing a daily zip to an operator laptop as the primary archive is manual, insecure, and incomplete during incidents when you need near-real-time lines. Suppressing all logging because “orchestrators cannot capture process output” is simply wrong; capture of stdout/stderr is a core container platform feature. Exam caveat: unstructured spam on stdout can still overwhelm collectors—pair stream logging with levels and structure, and never log secrets. Operational check: trigger a controlled error in a staging replica, confirm the line appears in the cluster’s central log view within the expected scrape or ship interval, and verify nothing was written only to a container-local file that vanishes on reschedule.