Why stdout for logs in Factor12?

Question

I have recently discovered https://12factor.net/ — a set of requirements for production environment that look quite sensible, except for logging requirements.

https://12factor.net/logs says that logs should go to STDOUT. WAT? WHY?

I've been mostly managing for last 7 years and must have missed something. But I do clearly remember that STDERR was design to serve this exact purpose — be a separate stream for diagnostic information. And it's been used as such for decades.

Why breaking the convention?

I do remember that all HTTP servers by default were configured to send STDOUT to a browser (client) and send STDERR to log files. It was everywhere. It's obvious and default for most of environments. My first thought is that they authors of the 12-factor standard have made a mistake.

What am I missing? Why sending logs to STDOUT?

Please don't tell me that modern web-applications don't have "normal output". Firstly they do, secondly, this doesn't qualify as a justification to break the convention that worked for decades and is still perfectly fit for purpose.

I'd appreciate your thoughts. Thank you.

Answer 1

Keep in mind that the 12factor applies mainly to your applications or let's call it your "micro services", not to your servers like Nginx, Apache, Cherokee, etc that they can log as always, but your application is the one you may want to scale and will be deployed in distributed environments, therefore, needs to be handled differently.

Regarding the logging, the main idea is to avoid the application write to disk and just write to STDOUT or STDERR, normally the logs are in a "structured logging" format, and later collected/analyzed by tools like elastiksearch. These simplify the process of checking logs so that if something is wrong, you don't need to login to each server and check what is happening.

In many cases when applications write log to disk, if a log rotate mechanism is not properly configured, the server disk may become full and service will be interrupted.

In case you are looking for a supervisor that plays well with 12factor.

Twelve-factor app processes should never daemonize or write PID files. Instead, rely on the operating system’s process manager (such as Upstart, a distributed process manager on a cloud platform, or a tool like Foreman in development) to manage output streams, respond to crashed processes, and handle user-initiated restarts and shutdowns.

Check immortal it can either combine STDOUT and STDERR or log separately besides also letting the log intact without timestamp in the case is a structured log that later may be used by elastic search, or any other tool, example:

cmd: microservice
env:
  DEBUG: 1
  ENVIRONMENT: production
log:
  file: /var/log/app-1.log
  age: 86400 # seconds
  num: 7     # int
  size: 1    # MegaBytes
  timestamp: true # will add timesamp to log

Same service but with STDOUT and STDERR logs separated:

cmd: microservice
env:
  DEBUG: 1
  ENVIRONMENT: production
log:
  file: /var/log/app-1.log
  age: 86400 # seconds
  num: 7     # int
  size: 1    # MegaBytes
stderr:
  file: /var/log/app-error.log
  age: 86400 # seconds
  num: 7     # int
  size: 1    # MegaBytes
  timestamp: true # will add timesamp to log

More about the run.yml can be found here: https://immortal.run/post/run.yml/