In our ideal world, developers should only access production servers via deployment systems.
This makes it possible to analyze the historical usage of a system and provides a way to get answers to questions about past usage and behavior.Īnother issue with Docker’s logging is that viewing a container’s logs requires access to the Docker socket, which is effectively root access. Ideally, logs should be archived for at least a month, if not longer. If you have 4 instances of a service running under a load balancer, following all their logs requires 4 commands, which may each need to be run on different hosts. Many developers prefer using standard Unix tools and scripting to access log files, and so a solution that allows that is preferred.ĭocker’s default JSON-file style of logging works well for a single container, but there are no great options for watching multiple containers. Ideally, logs should be available in standard formats, so that they are easy to search, filter, and follow. They should be able to follow logs, including logs from multiple containers at the same time. We want our developers to have easy access to current and historical logs. The most common use cases involve looking at logs to determine what happened or what is happening on the system. The primary requirements of a logging system come from the developers. We wanted to find a way to harness the features and flexibility of traditional logging systems, and so we began researching alternate paths that could help meet our needs. As we grew our Docker infrastructure at Simulmedia, we started finding Docker’s default logging to be inadequate.