logspout
logspout copied to clipboard
gliderlabs
include syslog server to listen on udp/socket
Would be great to include a small go based syslog server library ( https://github.com/ziutek/syslog ) and allow via options to have logspout listen on udp syslog or unix socket.
this would allow pointing syslog in a container to logspout via udp or a volume mounted syslog socket. This would help apps that only support syslog logging run better in a container.
figured you might be, I was going to try and solve it myself before I realized it would be a perfect fit for logspout.
Actually I haven't been able to make much progress if any of you guys wanted to take a shot with the new module system. I was looking at this library: https://github.com/mcuadros/go-syslog
I ended up doing an alpine linux based container running socat to listen to syslog port/socket and print to stdout - https://registry.hub.docker.com/u/factorish/syslog/
that running on same host as logspout container seems to be working ok for me, Although I haven't really tested it for robustness.
FYI, docker v1.6 is adding logging drivers, which includes a syslog driver. Would be fun to use logspout for this and bypass all of the event sniffing, but not sure you'd be able to run logspout in a container then
The log drivers are for output of what Docker already has as logs, whereas this was about providing a syslog input for containers to collect more than just stdout/err.
But I'm not sure I follow the rest. You mean use logspout as a log driver? That would require a custom build of Docker. However, eventually the work I'm doing with Docker on plugins could mean you could add dynamic log drivers. At that point, Logspout would likely become one.
You'll be able to configure docker to use syslog as an output for stdout/stderr (rather than the current json files). This issue is about adding a syslog server built into logspout. Given this, we could supply a logspout server as the syslog endpoint for the docker logging driver (without requiring a custom build). Alas, this would mean that logspout would likely have to run outside/before docker.
Ah ok. That's true. And it may not mean running before/outside Docker. But in the end, I'm not sure there is a real benefit for the downsides of configuring the log driver, etc. We still need to hit the API to collect information about containers for filters and such.
The point of this issue is to have a syslog server containers can talk to directly for non stdout/err logs.
+1, just one more use-case we'd get "for free" that would be fun to consider (and may open up more valuable scenarios in the future).
Any log driver other than the old default json-file will disable the /logs API in Docker 1.6. because of this, even while there's a none log driver now, running "disk-less" logging via Logspout is not yet possible, which is unfortunate. Then there is the mentioned syslog driver. If Logspout was able to consume local syslog, it would open the door for logging-with-out-disk. It seems like a possible tactical solution. Longer term, ideally Docker would provide a way to get a log stream independently of the driver via the API but that's a discussion for a different place.
@raychaser disabling the /logs API with the none driver seems like a big oversight. Is there a ticket for fixing this in the Docker project?
@packetcollision this is an expected side-effect of the none driver. It's intended to use when you don't want Docker to store your logs and plan to handle logging yourself (e.g. mounted volume, or the application sending logs itself).
There's more discussion on #94 about a possible alternative log driver that would work well with Logspout.
