Building a reliable self-hosted stack can feel amazing, especially when you start deploying FOSS tools that surpass their paid cloud-based alternatives. But as your arsenal of containers starts to pile up, you’ll want to look into tools designed specifically to monitor, organize, and troubleshoot other containerized environments. Take Dozzle, for example.

Although it doesn’t provide the same management facilities as Portainer, Komodo, or Cockpit, it lets me keep track of Docker logs on my server nodes. And as someone who often needs to check container logs to troubleshoot broken services, audit unusual activity, or copy random tokens generated at the time of the app’s creation, Dozzle has quickly become an essential part of my management stack.

Dozzle provides real-time log monitoring for my container stack

It can also track resource consumption stats

Rather than throwing a bunch of container organization services into a convoluted interface, Dozzle simply offers an uncluttered web UI featuring all the QoL facilities I need to monitor my Docker logs. For starters, it displays all the commands, errors, warnings, and output streams of my container collection inside color-coded logs. Being able to identify the different levels (or rather, types of streams) just by looking at the color appended to a message simplifies the process of sifting through hundreds of entries – and it makes everything easier on the eyes, too.

Dozzle lets me view each log entry in great detail, which is quite helpful when I need to go through the raw JSON code for an error. By default, Dozzle only shows the operational containers, but it can display the logs from failed, broken, or stopped environments. I often work with multiple containers at once, and Dozzle lets me pin deployment logs as separate columns, so I don’t have to constantly switch back and forth between different tabs. Since it connects directly with the underlying Docker socket, Dozzle can even pull the CPU and RAM usage metrics as well as the network speed for my containers, though I wish there was a way to track the persistent storage statistics.

The built-in SQL engine and filters are pretty handy for troubleshooting

Troubleshooting a failed Docker container is somewhat easier for recently-deployed containers, as there are only a few dozen entries in their log file. However, the situation is entirely different if I need to diagnose errors in old containers that broke out of nowhere. Even with Dozzle’s simple UI and compact layout, reading thousands of log entries would be quite painful.

Fortunately, Dozzle supports powerful filtering mechanisms to help me narrow down the search results. For example, there’s the regex search utility that pulls all entries with the same text patterns as my query, making it seem more like a fuzzy finder. I can also filter messages that belong to the STDERR and STDOUT streams, and I often use the former to narrow down error messages. But the real star of the show is the built-in SQL engine, which lets me use a declarative query language to filter precise results. Having dealt with a lot of databases during my uni days, being able to run SQL commands makes looking for specific Docker log entries child’s play.

It can even pull container logs from remote hosts

I’ve got multiple Docker hubs in my home lab, some virtual, others bare-metal. Deploying multiple instances of Dozzle for each system and using separate web UIs to track my logs would be a royal pain, as I’d constantly have to juggle different interfaces – even more so considering that I use certain Docker VMs to test (and break) containers.

Luckily for me, Dozzle can connect to the Docker sockets on multiple nodes and display the entries from each host into a centralized UI. There are a couple of ways to go about doing this, including methods that rely on certificates and TCP connections to pair different nodes together. But I prefer going down the agent route, which involves deploying a container that reports the logs to my primary Dozzle instance.

Dozzle is just as easy to deploy

I use the Dozzle agent when connecting multiple nodes to the web UI

While we’re on this subject, Dozzle has a pretty straightforward deployment process. If you’ve got a single Docker hub, you can run the docker run -d -v /var/run/docker.sock:/var/run/docker.sock -p 8080:8080 amir20/dozzle:latest command within the terminal app to get Dozzle up and running. Then, you can just enter the IP address of the host machine followed by a colon (:) and port number 8080.

But if you’re planning to connect multiple instances, you can use the docker run -v /var/run/docker.sock:/var/run/docker.sock -p 7007:7007 amir20/dozzle:latest agent to spin up the agent container on the remote machines that you wish to monitor from the main Dozzle instance. Since I’ve got different Docker nodes that I like to experiment with, I’ve used the compose.yml file for the main Dozzle container, as it lets me add the DOZZLE_REMOTE_AGENT environment variable.

It pairs well with other server-centric tools

The best part about Dozzle is that you can use it in tandem with other container monitoring utilities. For example, you can have a Pulse dashboard that tracks the uptime of your self-hosted arsenal and sends a Gotify notification as soon as something goes down. Then you can use the timestamp from Gotify to narrow down the log entries collected by Dozzle when diagnosing the error.