Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to log - the 12 factor application way

Tags:

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.

like image 207
alaboudi Avatar asked May 14 '17 20:05

alaboudi


People also ask

What is 12 Factor app process?

The 12 Factor App is a set of principles that describes a way of making software that, when followed, enables companies to create code that can be released reliably, scaled quickly, and maintained in a consistent and predictable manner.

Is 12 Factor app still relevant?

The Relevance of the Factors in 2021In general, these twelve factors are still highly relevant today, particularly for building microservices-based and cloud-native applications. Modern programming languages, development environments and frameworks enable easy adoption of these factors.

What is 12 Factor methodology in microservices?

What Is the Twelve-Factor Methodology? The twelve-factor methodology is a set of twelve best practices to develop applications developed to run as a service. This was originally drafted by Heroku for applications deployed as services on their cloud platform, back in 2011.


1 Answers

Is there an application that scoops up whatever is sent to stdout?

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.

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.

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.

like image 176
Brian Ecker Avatar answered Sep 23 '22 17:09

Brian Ecker