Why Your Web Server Should Log to Stdout (Especially with Docker)
In this video, we'll go over both the why and how to set up a number of web app servers to log to stdout.
Quick Jump: Demo Video
Since changes in a running container will get wiped out after a container stops, it’s typically a good idea to configure any Dockerized service to log to stdout and then configure the Docker daemon however you see fit to store your logs. This is recommended by Docker and it’s considered a best practice.
There’s many other advantages that aren’t specific to Docker for logging to stdout instead of a specific log file too, such as being able to collect and query them on 1 server with journald / journalctl or ship them to a centralized logging server / service.
You also only need to worry about rotating your journald logs instead of every service’s individual log files. You can also easily archive and export your logs to standard formats such as json if you go the stdout -> syslog -> journald route.
In this video we’ll cover a few reasons and wrap things up by seeing how to configure a few different web app servers to log to stdout.
Here’s a couple of examples shown on video:
# Configuring gunicorn to log to stdout. accesslog = '-'
# Configuring Rails to log to stdout. config.logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
- 0:46 – Why would you want to log to stdout?
- 4:29 – Configuring gunicorn to log to stdout
- 6:21 – How logging to a specific file with Docker can get you in trouble
- 8:08 – Configuring Rails and Laravel to log to stdout
- Build a SAAS App with Flask course
Is your web server logging to stdout? Let me know below.