logging - 为什么要对 Factor12 中的日志进行标准输出？

Question

我最近发现https://12factor.net/ — 对生产环境的一组要求，看起来很合理，但日志记录要求除外。

https://12factor.net/logs说日志应该转到 STDOUT .哇？为什么？

在过去的 7 年里，我主要从事管理工作，一定错过了一些东西。但我清楚地记得STDERR旨在满足这一确切目的 - 成为诊断信息的单独流。它已经被使用了几十年。

为什么要打破约定？

我记得默认情况下所有 HTTP 服务器都配置为将 STDOUT 发送到浏览器(客户端)并将 STDERR 发送到日志文件。它无处不在。对于大多数环境来说，这是显而易见的和默认的。我的第一个想法是他们 12 因素标准的作者犯了一个错误。

我错过了什么？为什么将日志发送到 STDOUT？

请不要告诉我现代网络应用程序没有“正常输出”。首先，他们确实这样做了，其次，这不能作为打破已运行了数十年但仍然完全符合目的的惯例的理由。

我很感激你的想法。谢谢你。

Answer 1

请记住，12factor 主要适用于您的应用程序，或者我们称其为您的“微服务”，而不是您的服务器，如 Nginx、Apache、Cherokee 等，它们可以像往常一样登录，但您的应用程序可能是您想要的规模并将部署在分布式环境中，因此需要不同的处理方式。

关于日志记录，主要思想是避免应用程序写入磁盘而只写入 STDOUT或 STDERR ，通常日志采用“结构化日志”格式，然后由 elastiksearch 等工具收集/分析。这些简化了检查日志的过程，因此如果出现问题，您无需登录到每个服务器并检查发生了什么。

很多情况下，应用程序将日志写入磁盘时，如果日志轮换机制配置不当，可能会导致服务器磁盘已满，导致服务中断。

如果您正在寻找与 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.

查询 immortal它既可以结合 STDOUT 和 STDERR 也可以单独记录日志，此外还可以在没有时间戳的情况下让日志完整无缺，如果是结构化日志，以后可能会被 Elasticsearch 或任何其他工具使用，例如:

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

相同的服务，但 STDOUT 和 STDERR 日志分开:

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

更多关于 run.yml可以在这里找到: https://immortal.run/post/run.yml/