如何记录-12要素申请方式 [英] How to log - the 12 factor application way

问题描述

我想知道记录节点应用程序背后的最佳实践.我在 https://12factor.net/logs 上阅读了12要素应用指南，其中指出日志应始终被发送到stdout.很酷，但是有人会如何管理生产日志?是否有一个应用程序可以收集发送到stdout的所有内容?另外，是否建议我仅登录到stdout而不登录到stderr?我希望对此事有一个看法.

I want to know the best practice behind logging my node application. I was reading the 12 factor app guidelines at https://12factor.net/logs and it states that logs should always be sent to the stdout. Cool, but then how would someone manage logs in production? Is there an application that scoops up whatever is sent to stdout? In addition, is it recommended that I only be logging to stdout and not stderr? I would appreciate a perspective on this matter.

推荐答案

是否有一个应用程序可以监视发送到stdout的所有内容?

您链接到的页面提供了一些日志管理工具的示例，但是最简单的版本是将应用程序的输出重定向到文件.所以在bash node app.js > app.out中.您也可以像node app.js 2> app.err 1> app.out一样拆分stdout和stderr.

The page you linked to provides some examples of log management tools, but the simplest version of this would be just redirecting the output of your application to a file. So in bash node app.js > app.out. You could also split your stdout and stderr like node app.js 2> app.err 1> app.out.

您还可以使用某种服务，从该文件收集日志，然后将它们编入索引以便在其他地方搜索.

You could additionally have some sort of service that collects the logs from this file, and then puts them indexes them for searching somewhere else.

仅登录到stdout的建议背后的想法是让环境控制如何处理日志，因为应用程序不一定知道最终将在其中运行的环境.此外，通过将所有日志视为事件流，您可以选择如何处理该流，直到环境.例如，您可能希望将日志流直接发送到日志聚合服务，或者可能要先对其进行预处理，然后再将结果流传输到其他地方.如果您要求特定的输出(例如记录到文件)，则会降低服务的可移植性.

The idea behind the suggestion to only log to stdout is to let the environment control what to do with the logs because the application doesn't necessarily know the environment that it will eventually run within. Furthermore, by treating all logs as an event stream, you leave the choice of what to do with this stream up to the environment. You may want to send the log stream directly to a log aggregation service for instance, or you may want to first preprocess it, and then stream the result somewhere else. If you mandate a specific output such as logging to a file, you reduce the portability of your service.

这12个要素指南的两个主要目标是适合在现代云平台上进行部署"并提供执行环境之间的最大可移植性".在您的实例上可能具有临时存储或许多运行相同服务的实例的云平台上，您希望将日志聚合到某个中央存储中.通过提供日志流，您可以将其留给环境来协调如何进行.如果将它们直接放入文件中，则必须将环境调整为适合每个应用程序决定将日志放入的位置，然后将它们重定向到中央存储.因此，将stdout用于日志主要是一个有用的约定.

Two of the primary goals of the 12 factor guidelines are to be "suitable for deployment on modern cloud platforms" and to offer "maximum portability between execution environments". On a cloud platform where you might have ephemeral storage on your instance, or many instances running the same service, you'd want to aggregate your logs into some central store. By providing a log stream, you leave it up to the environment to coordinate how to do this. If you put them directly into a file, then you would have to tailor your environment to wherever each application has decided to put the logs in order to then redirect them to the central store. Using stdout for logs is thus primarily a useful convention.

这篇关于如何记录-12要素申请方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！