Hello, I'm currently testing things, related to this LP: https://bugs.launchpad.net/tripleo/+bug/1814897 We might hit some issues: - With docker, json-file log driver doesn't support any "path" options, and it outputs the files inside the container namespace (/var/lib/docker/container/ID/ID-json.log) - With podman, we actually have a "path" option, and it works nice. But the json-file isn't a JSON at all. - Docker supports journald and some other outputs - Podman doesn't support anything else than json-file Apparently, Docker seems to support a failing "journald" backend. So we might end with two ways of logging, if we're to keep docker in place. Cheers, C. On 2/5/19 11:11 AM, Cédric Jeanneret wrote:
Hello there!
small thoughts: - we might already push the stdout logging, in parallel of the current existing one
- that would already point some weakness and issues, without making the whole thing crash, since there aren't that many logs in stdout for now
- that would already allow to check what's the best way to do it, and what's the best format for re-usability (thinking: sending logs to some (k)elk and the like)
This would also allow devs to actually test that for their services. And thus going forward on this topic.
Any thoughts?
Cheers,
C.
On 1/30/19 11:49 AM, Juan Antonio Osorio Robles wrote:
Hello!
In Queens, the a spec to provide the option to make containers log to standard output was proposed [1] [2]. Some work was done on that side, but due to the lack of traction, it wasn't completed. With the Train release coming, I think it would be a good idea to revive this effort, but make logging to stdout the default in that release.
This would allow several benefits:
* All logging from the containers would en up in journald; this would make it easier for us to forward the logs, instead of having to keep track of the different directories in /var/log/containers
* The journald driver would add metadata to the logs about the container (we would automatically get what container ID issued the logs).
* This wouldo also simplify the stacks (removing the Logging nested stack which is present in several templates).
* Finally... if at some point we move towards kubernetes (or something in between), managing our containers, it would work with their logging tooling as well.
Any thoughts?
[1] https://specs.openstack.org/openstack/tripleo-specs/specs/queens/logging-std...
[2] https://blueprints.launchpad.net/tripleo/+spec/logging-stdout-rsyslog
-- Cédric Jeanneret Software Engineer DFG:DF