How to start working with Docker logs

Source – techrepublic.com

Chances are you’ve run into issues with a Docker container or two. When that happens, what do you do? As with any piece of mission-critical software, any IT pro worth their weight in Cat5 will say the first thing you do is check the log files. The same holds true with Docker. But how do you check a log file for a container that doesn’t contain a complete operating system? Fortunately, the developers of Docker have thought of just that.

I want to walk you through the process of working with Docker logs. Once you know how to start using this tool, it’ll make troubleshooting Docker containers significantly easier.

You’ll be surprised how easy it is to view your container’s log file. It should be noted, however, that logs are only written for running containers (you can view log files from stopped containers as well).

With that said, let’s take a look at the best method of viewing your container’s log file.

Gathering the necessary information

In order to view a container’s logs, you must know the name of the container in question. There are two “names” you can use for logging purposes: the container ID or the image name. For demonstration purposes, I will use Shipyard as my container. To find out the name and ID, I’ll issue the command:

docker ps

The above command will output something similar to that in Figure A.

Figure A

In my case, I’m looking for the names associated with Shipyard. The docker ps command shows me those names are:

• e7565ec8e16d
• shipyard

I use Shipyard for a specific purpose (one I’ll mention in a moment).

Viewing the logs

Viewing the Docker logs for a container is handled with the command:

docker logs CONTAINER

Where CONTAINER is the name of the container you want to use. Say you want to view the Shipyard logs; you could issue the command:

docker logs shipyard

The above command would produce an error indicating no container named “shipyard” exists (whereas, issuing the same command for a running nginx container would actually work). If, on the other hand, you issue the following command, you’ll get results.

docker logs e7565ec8e16d

As you can see (Figure B), there are logs to be viewed for the Shipyard container.

Figure B

When you’re attempting to troubleshoot a container, that command isn’t going to help you all that much. You can, however, make use of the tail command, such that you can view the log files being written as they happen. To do this (again, sticking with our Shipyard example), the command would then look like:

docker logs --tail=10 -f e7565ec8e16d

At this point, tail would follow the log file and present the last 10 lines of output as it is written (Figure C).

Figure C

Using this method will make it significantly easier for you to troubleshoot your containers. And don’t think this method works with only web-based containers. I spun up a Debian container, with the command:

docker run -it debian /bin/bash

On another terminal, I issued the command:

docker logs --tail=10 -f 692a

Where 692a was the first four characters in the Debian container ID. The results of the command can be seen in Figure D.

Figure D

Now we can see it’s possible to get plenty of information regarding a container — enough information to troubleshoot what may be going on.