Docker Compose logs: filter and compare service output

docker compose logs presents the output of a Compose project's containers in one interleaved view. Compared with docker logs, which targets a single container, it makes it easier to follow interactions between services.

Use service names to select output, keep timestamps and instance identity when correlating events, and remember that the available history depends on the logging driver and retention configuration.

View and filter logs

docker compose logs
docker compose logs -f
docker compose logs web api
docker compose logs --tail 50 web
docker compose logs --since 10m
docker compose logs --index 1 web

web and api are service keys from the Compose file, not full container names such as myapp-web-1. A service can have multiple replicas; --index selects one. --tail applies to each selected container rather than imposing one overall project-wide line count.

Customize output

docker compose logs --no-log-prefix
docker compose logs -t
docker compose logs --no-color
# Capture both output streams without color or service prefixes:
docker compose logs --no-color --no-log-prefix -t web > web.log 2>&1

Removing prefixes makes copying easier but discards useful source identity. Keep them when comparing replicas unless the application log already carries enough context. CLI diagnostics can also appear in a combined export, so do not assume the resulting file contains only application JSON.

Multiline stack traces and pretty-printed JSON can be interleaved or split by the runtime, driver, or collector. Compose does not itself define a universal stored-event boundary. Single-line structured JSON, with escaped stack traces in a field, simplifies collection; multiline parsers are another option. To pretty-print it with jq, supply raw JSON without Compose timestamps or prefixes, and exclude CLI diagnostics or other non-JSON records. The timestamped export above cannot be fed directly to jq. Validate actual boundaries before assuming context is preserved.

Add a live view with Dozzle

For local evaluation, Dozzle can expose a container log interface:

services:
  dozzle:
    image: amir20/dozzle:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - dozzle_data:/data
    ports:
      - "127.0.0.1:8888:8080"
volumes:
  dozzle_data:

Open http://localhost:8888 after starting this service. The interface can help compare containers side by side; exact controls depend on the release.

This example binds the UI to loopback. Docker socket access is highly privileged, and Dozzle authentication is not enabled by this snippet. Before allowing remote access, configure authentication, TLS, and access restrictions. Pin a reviewed image version or digest for a maintained deployment. The data volume persists Dozzle settings; it should not be mistaken for an independent archive of all container logs.

Know when the CLI is insufficient

Compose logs are useful for immediate investigation of a project on the selected Docker endpoint. They do not provide a unified multi-host historical search, retention policy, or alerting system. Those requirements need additional collection and storage design.

Verify centralized container logs

For Guance, follow the Container integration for the actual runtime and logging setup. Check supported drivers, read permissions, and collection scope. Write a test record from one service and verify the service and container identifiers in the resulting data.

JSON output does not mean the fields have already been parsed. Configure and test a Pipeline for timestamp, level, and request ID. Verify multiline stack boundaries and compare the same test record with local Compose output.

Test alerts with a known failure, and confirm that logs are delivered before local rotation removes them. Choose retention around investigation requirements rather than container lifetime.

Frequently asked questions

How does this differ from docker logs?

Compose selects project services and merges their container output with prefixes and optional color. Both commands depend on Docker's log-reading support, including supported local drivers or dual-logging caches. They are not guaranteed to read a raw file for every driver.

How do I distinguish replicas?

Keep the default prefixes or select --index N. In centralized logs, verify that container/instance identity is actually present before relying on an instance filter.

Can each service use a different logging driver?

Yes. A service's logging section supports a driver and options. Driver-specific settings, such as rotation limits, must be compatible with the selected collector. Recreate affected containers when changing their logging configuration and verify behavior after rotation.

How long is local history retained?

It depends on the driver and options. Docker's local driver defaults to five 20 MB files, about 100 MB of uncompressed log data per container, with compression reducing disk usage. This is a size limit, not a time guarantee. Configure separate retention and recovery procedures for long-term storage.

References

• Compose logs options
• Docker dual logging
• Dozzle setup

Related reading

• The docker logs command
• Heroku logging (Chinese)
• Docker logging practices
• Log aggregation (Chinese)