lfn-cnti / bestpractices

📞📱☎️📡🌐 The focus of the Cloud Native Telecom Initiative (CNTI) Best Practices community is to define cloud native networking best practices
https://wiki.lfnetworking.org/display/LN/Best+Practices
Other
104 stars 54 forks source link

[Best Practice Proposal]: Resource output logs should be sent to STDOUT/STDERR #253

Open taylor opened 1 year ago

taylor commented 1 year ago

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

taylor commented 1 year ago

Google doc draft https://docs.google.com/document/d/11V_mbvKfrCUFQu339HEtMpYxNme1NXGrLiRO-RZp350/edit

taylor commented 7 months ago

well-documented best practice. good first issue. draft started

martin-mat commented 6 months ago

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

lixuna commented 6 months ago

References: