Parsing Docker Compose Multi-Service Logs
Parse combined Docker Compose logs from multiple services with service name prefixes, mixed formats, and interleaved output streams.
Detailed Explanation
Docker Compose Multi-Service Logs
When running docker compose logs for a multi-service stack, the output interleaves log lines from all services, each prefixed with the service name and a color code.
Typical Multi-Service Output
api-1 | 2024-01-15T10:30:00.000Z INFO Starting API server
api-1 | 2024-01-15T10:30:00.500Z INFO Listening on :8080
db-1 | 2024-01-15 10:30:00.000 UTC [1] LOG: database system is ready to accept connections
redis-1 | 1:M 15 Jan 2024 10:30:00.001 * Ready to accept connections
worker-1 | {"timestamp":"2024-01-15T10:30:01Z","level":"info","msg":"Worker started","queue":"default"}
api-1 | 2024-01-15T10:30:05.123Z ERROR Failed to connect to database
db-1 | 2024-01-15 10:30:05.123 UTC [45] ERROR: too many connections for role "app"
Mixed Formats
Notice how each service uses its own log format:
- api — timestamp + level + message
- db (PostgreSQL) — PostgreSQL native log format
- redis — Redis native log format
- worker — JSON structured logs
Parsing Strategy
The parser handles mixed-format logs through auto-detect mode, which tries each parser per line. For Docker Compose output:
- Service name prefixes are recognized as part of the source field
- Each line's content is independently parsed against all supported formats
- The resulting table shows a clear picture of which service produced each log, at what severity, and in what format
Filtering Tips
After parsing, use the search box to filter by service name (e.g., type "api" to see only API service logs) or by severity to find errors across all services. The statistics panel shows which services generate the most log volume and at what severity levels.
Use Case
Debugging multi-service Docker Compose stacks, correlating errors across dependent services (e.g., API server and database), identifying which service is generating the most errors, and analyzing startup sequences across all services in a stack.