New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

include syslog server to listen on udp/socket #48

Open
paulczar opened this Issue Feb 26, 2015 · 15 comments

Comments

Projects
None yet
7 participants
@paulczar
Copy link

paulczar commented Feb 26, 2015

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.

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Feb 26, 2015

Already working on it

@paulczar

This comment has been minimized.

Copy link

paulczar commented Feb 26, 2015

figured you might be, I was going to try and solve it myself before I realized it would be a perfect fit for logspout.

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Feb 26, 2015

word

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Apr 1, 2015

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

@paulczar

This comment has been minimized.

Copy link

paulczar commented Apr 4, 2015

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.

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Apr 4, 2015

Cool. Still would be nice to have.

@shazow

This comment has been minimized.

Copy link
Contributor

shazow commented Apr 11, 2015

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

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Apr 12, 2015

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.

@shazow

This comment has been minimized.

Copy link
Contributor

shazow commented Apr 12, 2015

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.

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Apr 12, 2015

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.

@shazow

This comment has been minimized.

Copy link
Contributor

shazow commented Apr 12, 2015

+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).

@progrium

This comment has been minimized.

Copy link
Contributor

progrium commented Apr 12, 2015

For sure

@raychaser

This comment has been minimized.

Copy link
Contributor

raychaser commented Apr 21, 2015

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.

@dnelson

This comment has been minimized.

Copy link

dnelson commented May 6, 2015

@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?

@mgood

This comment has been minimized.

Copy link

mgood commented May 6, 2015

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment