Question

我最近发现https://12factor.net/ - 除了记录要求外，对生产环境的一系列要求看起来很合理。

https://12factor.net/logs表示日志应转到STDOUT。 WAT？为什么？

我过去7年来一直在管理，但一定是错过了什么。但我确实清楚地记得STDERR的设计是为了达到这个目的 - 是一个单独的诊断信息流。几十年来它一直被用作。

为何违反惯例？

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

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

请不要告诉我现代网络应用程序没有“正常输出”。首先，他们这样做，其次，这不符合打破几十年有效的公约的理由，仍然完全符合目的。

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

Answer 1

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

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

在许多情况下，当应用程序将日志写入磁盘时，如果未正确配置日志轮换机制，则服务器磁盘可能会变满并且服务将被中断。

如果您正在寻找与12factor配合良好的主管。

十二因素应用程序进程永远不应该守护或写入PID文件。相反，依靠操作系统的流程管理器（例如Upstart，云平台上的分布式流程管理器或开发中的Foreman等工具）来管理输出流，响应崩溃的流程，以及处理用户启动的重启和关闭。

检查immortal它可以组合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
  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/

Answer 2

这是因为12个因素的应用程序需要在某个进程管理器的控制下运行作为单独的进程 - 比如supervisord或其他什么 - 来管理路由应用程序输出到它们实际属于的位置

他们的想法是让应用程序尽可能不可知 - 以系统相关的方式处理所有应用程序的所有输出，同时将所有应用程序隐藏在应用程序中。

所以，我希望“12因素”响应是您的应用应该推送到STDOUT，而supervisord应该捕获该输出（以及所有其他STDOUT s来自在同一主机上运行的所有其他应用程序）并按主机重定向到STDERR或syslog或您需要的任何内容。

<强>更新

我认为12因素推荐的守护进程，但because reasons（pids和所有这些）实际上并没有。进一步证明12因素的过程管理者部分是至关重要的。

为什么stdout登录Factor12？

2 个答案: