我最近发现了
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/