Logs, Stats & Inspect

Introduction

Observability starts with three commands. logs shows stdout/stderr, stats shows live CPU/memory, inspect dumps the full JSON config of any container or image.

Purpose of this lesson

This lesson teaches Logs, Stats & Inspect as an engineering decision: what problem it solves, when to use it, how to implement it safely, and what signals tell you it is failing.

Understanding the topic

Use this in day-to-day container operations: pulling images, running processes, inspecting failures, publishing artifacts, and keeping the Docker host clean and predictable.

Core concepts to understand:

• docker logs -f --tail 100 web follows the last 100 lines.
• docker stats = top-like live view of all running containers.
• docker inspect web returns JSON — pipe to jq for queries.
• Log drivers: json-file (default), journald, syslog, gelf, fluentd, awslogs.

Visual explanation

Architecture or command flow to keep in mind:

docker logs -f --tail 50 api
docker stats               # live CPU/mem/net/io
docker inspect api | jq '.[0].State'
docker inspect api | jq '.[0].NetworkSettings.IPAddress'

Step-by-step explanation

1. Run the command or manifest exactly once on a clean Docker host and read the output carefully.
2. Inspect the object Docker created: image, container, network, volume, port mapping, process, or registry tag.
3. Break one realistic assumption such as a missing port, bad tag, stopped daemon, wrong network, or deleted volume.
4. Use docker ps, logs, inspect, stats, and system df to locate the failure.
5. Write the final command or configuration into a repeatable script, Compose file, or CI job.

Informative example

Use the example below as a working baseline, then verify the runtime behavior instead of assuming the command or file is correct.

docker logs -f --tail 50 api
docker stats               # live CPU/mem/net/io
docker inspect api | jq '.[0].State'
docker inspect api | jq '.[0].NetworkSettings.IPAddress'

A production-minded check usually includes docker ps, docker logs, docker inspect, and one validation from outside the container such as curl, a database connection, or a registry pull.

# Verification loop for Logs, Stats & Inspect
docker ps -a
docker logs --tail=100 <container-name>
docker inspect <container-or-image-name>
docker system df

Real-world use

In prod, logs ship to a central system (Loki, ELK, Datadog) via the daemon's log driver. Locally, docker logs is your first stop.

Enterprise use cases

In a mature engineering organization, Logs, Stats & Inspect is documented as a repeatable pattern with approved base images, ownership labels, CI checks, security expectations, rollback notes, and troubleshooting commands. The difference between a tutorial and production practice is that every container decision must be observable, reviewable, and reversible.

Best practices

• Always log to stdout/stderr from your app — let Docker handle the rest.
• Cap log size with --log-opt max-size=10m max-file=3.

Common mistakes

• Unbounded json-file logs filling the disk.
• Writing logs to a file inside the container — invisible to docker logs.

Debugging tips

• Inspect effective runtime settings with docker inspect; do not assume the Dockerfile or Compose file applied as expected.
• For resource incidents, compare docker stats, exit codes, OOMKilled state, and host memory pressure.
• For supply-chain issues, trace the exact image digest from build logs to registry to deployment.

Optimization strategies

• Prefer explicit names, labels, tags, and networks so cleanup and debugging stay predictable.
• Pin versions for repeatability, then update intentionally through a scheduled base-image refresh.
• Use docker system df and targeted prune commands to control local and CI disk growth.

Advanced interview questions

Hands-on exercise

Create a small lab for Logs, Stats & Inspect: run the example, inspect the created Docker object, intentionally introduce one mistake, and record the command that reveals the failure. The goal is not just to make the happy path work; it is to build operational reflexes.

# Hands-on lab scaffold
mkdir -p docker-logs-stats-inspect-lab
cd docker-logs-stats-inspect-lab

# Add the Dockerfile, compose.yml, or command from this lesson.
# Then run one happy-path test and one broken-path test.
docker version
docker info
docker system df

Summary

Logs, Stats & Inspect matters because Docker is not only a packaging tool; it is a runtime, build, networking, storage, and delivery workflow. Treat each lesson as a production habit: make it repeatable, inspectable, secure, and easy to debug.