logging – 为什么要在因子12中记录日志？

2023年9月17日 208次阅读

我最近发现了
https://12factor.net/ – 生产环境的一套要求,除了记录要求外,看起来很合理.

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

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

为何打破常规？

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

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

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

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

最佳答案 请记住,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或单独记录,除了让日志完整而没有时间戳的情况下是结构化日志,以后可以使用弹性搜索或任何其他工具,例如：

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/

点赞