If you're looking for an easy way to troubleshoot your Docker containers, look no further than the docker logs command. Here's how to make it work for you.
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:
The above command will output something similar to that in Figure A.
In my case, I'm looking for the names associated with Shipyard. The docker ps command shows me those names are:
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.
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).
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.
Now we can see it's possible to get plenty of information regarding a container — enough information to troubleshoot what may be going on.
There's more to be had
If you issue the command docker logs —help, you'll see that there are more options available than just tail. Give these options a try and see how you can best customize your log viewing to suit your needs. With this tool at the ready, you can better see what's going on with your containers.
- How to create a Docker swarm (TechRepublic)
- How to use Docker tags to add version control to images (TechRepublic)
- How to get Docker Shipyard up and running with a single command (TechRepublic)
- How to create a docker image and push it to Docker Hub (TechRepublic)
- What is Docker and why is it so darn popular? (ZDNet)