Open taylor opened 1 year ago
well-documented best practice. good first issue. draft started
I agree with this best practice, however I think this is one aspect of "observability". Perhaps we should consider more aspects of that:
Platform:
CNFs:
Some additional links https://www.cncf.io/blog/2023/07/03/kubernetes-logging-best-practices/ https://www.papertrail.com/solution/tips/cloud-native-applications-and-log-management-best-practices/ https://newrelic.com/blog/how-to-relic/log-monitoring-for-cloud-native-architectures https://www.mezmo.com/blog/what-the-cloud-native-revolution-means-for-log-management
References:
Summary
All K8s resource output / logs should be sent to STDOUT/STDERR as event streams.
Log output, such as normal standard output as well as application errors should be sent to stdout/stderr (standard out, standard error) instead of a log file or directly to a logging system (other than a proxy/sidecar which streams to stdout/stderr).
Services should not concern themselves with routing or storing logs. Instead, events should be streamed, unbuffered, to STDOUT and STDERR for handling by the whatever observability / debugging process is appropriate.
Motivation
The standard output (STDOUT) and standard error (STDERR) can be easily viewed in development. In a production deployment, the CNF streams can be routed to anything, including a central logging service.
Goals
No response
Non-Goals
No response
Proposal
Send all application logs to stdout and all error logs to stderr rather than implementing or using a custom logging solution. Don't write to a log file, and don't expect log files to be managed. This then requires log rotation and log file maintenance.
Log output being sent to standard out / standard error supports open observability options and a pluggable flexible system.
By sending logs to standard out/standard error "logs will be treated like event streams" as recommended by 12 factor apps principles.
Using a sidecar to collect and stream the output is an option that is appropriate in some circumstances.
Reasons for using stdout:
Workload Context
No response
User Stories
No response
Notes, Caveats, Constraints
Testing should verify that STDOUT/STDERR is configured for logging. For example, running kubectl get logs returns useful information for diagnosing or troubleshooting issues.
References