8

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

https://12factor.net/logs说日志应该去STDOUT. 笏？为什么？

在过去的 7 年里，我大部分时间都在管理，一定错过了一些东西。但我清楚地记得，STDERR它的设计正是为了达到这个目的——成为诊断信息的单独流。它已经被使用了几十年。

为什么要打破约定？

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

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

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

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

4

2 回答 2

3

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

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

在很多情况下，应用程序将日志写入磁盘时，如果没有正确配置日志轮转机制，可能会导致服务器磁盘已满，从而导致服务中断。

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

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

Check 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/

于 2017-09-07T19:52:46.743 回答
0

这是因为 12 要素应用程序预计将在某些流程管理器（例如或其他东西）的控制下作为单独的流程supervisord运行，以管理将应用程序输出路由到它们实际所属的位置。

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

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

更新

我认为 12-factor 推荐了守护进程，但由于原因（pids 和所有这些），它们实际上并没有。进一步证明 12 因素的流程管理器部分至关重要。

于 2017-08-28T20:47:27.530 回答