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

Logging drivers #10568

Merged
merged 4 commits into from Mar 17, 2015

Conversation

Projects
None yet
@LK4D4
Contributor

LK4D4 commented Feb 4, 2015

Initial try to implement logging driver interface. I skipped fetching logs part from #7195 because it makes sense only for docker logs and actually docker logs is not very actively used.
It is pretty easy to implement logging driver with this, I have syslog and remote in mind. Remote will just send serialized logger.Messages to tcp socket.
Awaiting your comments.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Feb 4, 2015

Member

--log-driver=none! 😍

Member

tianon commented Feb 4, 2015

--log-driver=none! 😍

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Feb 4, 2015

Member

"docker logs is not very actively used" << I think you're going to need to backup this statement with some stats or some facts, because I actively use docker logs -f and docker logs -f --tail=... every single day 😉

(but I don't need fetch+truncate)

Member

tianon commented Feb 4, 2015

"docker logs is not very actively used" << I think you're going to need to backup this statement with some stats or some facts, because I actively use docker logs -f and docker logs -f --tail=... every single day 😉

(but I don't need fetch+truncate)

@paultag

This comment has been minimized.

Show comment
Hide comment
@paultag

paultag Feb 4, 2015

❤️ --log-driver=none ❤️

paultag commented Feb 4, 2015

❤️ --log-driver=none ❤️

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 4, 2015

Contributor

@tianon How didn't you notice #10424 ? :) Maybe for debugging docker logs is very cool, but for production system pretty useless.

Contributor

LK4D4 commented Feb 4, 2015

@tianon How didn't you notice #10424 ? :) Maybe for debugging docker logs is very cool, but for production system pretty useless.

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Feb 4, 2015

Contributor

@paultag will be excited :D

On Wed, Feb 4, 2015 at 3:03 PM, Alexander Morozov notifications@github.com
wrote:

@tianon https://github.com/tianon How didn't you notice #10424
#10424 ? :) Maybe for debugging docker
logs is very cool, but for production system pretty useless.


Reply to this email directly or view it on GitHub
#10568 (comment).

Contributor

jessfraz commented Feb 4, 2015

@paultag will be excited :D

On Wed, Feb 4, 2015 at 3:03 PM, Alexander Morozov notifications@github.com
wrote:

@tianon https://github.com/tianon How didn't you notice #10424
#10424 ? :) Maybe for debugging docker
logs is very cool, but for production system pretty useless.


Reply to this email directly or view it on GitHub
#10568 (comment).

@paultag

This comment has been minimized.

Show comment
Hide comment
@paultag

paultag Feb 4, 2015

I AM SO EXCITED

🎊 🎊 🎊
💃 💃 💃

paultag commented Feb 4, 2015

I AM SO EXCITED

🎊 🎊 🎊
💃 💃 💃

@cpuguy83

View changes

Show outdated Hide outdated docs/sources/reference/commandline/cli.md
@cpuguy83

View changes

Show outdated Hide outdated docs/sources/reference/commandline/cli.md
@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 5, 2015

Contributor

I'm pretty sure that there is some race :) Also whole test TestImagesFilterWhiteSpaceTrimmingAndLowerCasingWorking is pretty suspicious.

Contributor

LK4D4 commented Feb 5, 2015

I'm pretty sure that there is some race :) Also whole test TestImagesFilterWhiteSpaceTrimmingAndLowerCasingWorking is pretty suspicious.

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 5, 2015

Contributor

Omg, it's green

Contributor

LK4D4 commented Feb 5, 2015

Omg, it's green

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Feb 5, 2015

Contributor

\o/

On Thu, Feb 5, 2015 at 2:04 PM, Alexander Morozov notifications@github.com
wrote:

Omg, it's green


Reply to this email directly or view it on GitHub
#10568 (comment).

Contributor

jessfraz commented Feb 5, 2015

\o/

On Thu, Feb 5, 2015 at 2:04 PM, Alexander Morozov notifications@github.com
wrote:

Omg, it's green


Reply to this email directly or view it on GitHub
#10568 (comment).

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Feb 5, 2015

Member

@LK4D4 yeah, I noticed it, but formatting doesn't bother me -- the information is all there, and there's absolutely no possible chance that a stray "Ctrl+C" kills my production process with docker logs 😉

Member

tianon commented Feb 5, 2015

@LK4D4 yeah, I noticed it, but formatting doesn't bother me -- the information is all there, and there's absolutely no possible chance that a stray "Ctrl+C" kills my production process with docker logs 😉

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 5, 2015

Contributor

Also, question: should we throw an error for logs if driver is not default?

Contributor

LK4D4 commented Feb 5, 2015

Also, question: should we throw an error for logs if driver is not default?

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Feb 5, 2015

Member
Member

tianon commented Feb 5, 2015

@unclejack

This comment has been minimized.

Show comment
Hide comment
@unclejack

unclejack Feb 6, 2015

Contributor

--log-driver=none is very useful.

LGTM

Contributor

unclejack commented Feb 6, 2015

--log-driver=none is very useful.

LGTM

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Feb 7, 2015

Contributor

LGTM

Contributor

jessfraz commented Feb 7, 2015

LGTM

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 7, 2015

Contributor

@fredlf @SvenDowideit @jamtur01 Could you look at docs please?

Contributor

LK4D4 commented Feb 7, 2015

@fredlf @SvenDowideit @jamtur01 Could you look at docs please?

@jamtur01

View changes

Show outdated Hide outdated docs/sources/reference/commandline/cli.md
@jamtur01

View changes

Show outdated Hide outdated docs/sources/reference/run.md
@jamtur01

View changes

Show outdated Hide outdated docs/sources/reference/run.md
@jamtur01

View changes

Show outdated Hide outdated docs/sources/reference/run.md
@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 9, 2015

Contributor

@jamtur01 fixed, thanks. PTAL

Contributor

LK4D4 commented Feb 9, 2015

@jamtur01 fixed, thanks. PTAL

@jamtur01

View changes

Show outdated Hide outdated api/client/commands.go
@jamtur01

This comment has been minimized.

Show comment
Hide comment
@jamtur01

jamtur01 Feb 9, 2015

Contributor

Minor comment - otherwise LGTM.

Contributor

jamtur01 commented Feb 9, 2015

Minor comment - otherwise LGTM.

@fredlf

View changes

Show outdated Hide outdated docs/sources/reference/commandline/cli.md
@fredlf

View changes

Show outdated Hide outdated docs/sources/reference/run.md
@fredlf

This comment has been minimized.

Show comment
Hide comment
@fredlf

fredlf Feb 9, 2015

Contributor

Just a couple of copy edits. LGTM otherwise.

Contributor

fredlf commented Feb 9, 2015

Just a couple of copy edits. LGTM otherwise.

@SvenDowideit

View changes

Show outdated Hide outdated docs/sources/reference/run.md
@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 11, 2015

Contributor

@SvenDowideit I've added info about logs command and endpoint.

Contributor

LK4D4 commented Feb 11, 2015

@SvenDowideit I've added info about logs command and endpoint.

@SvenDowideit

View changes

Show outdated Hide outdated docs/sources/reference/run.md
@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Feb 12, 2015

Contributor

needs info on the man pages too (as I'm here)

Contributor

SvenDowideit commented Feb 12, 2015

needs info on the man pages too (as I'm here)

@cpuguy83 cpuguy83 referenced this pull request Feb 13, 2015

Closed

Fetch truncate logs #9753

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 13, 2015

Contributor

I like this. It makes sense that we not bother trying to implement readers for log drivers since the whole point of alternative drivers is to get the logs out of docker, we can recommend the default logger only for dev environments.

Contributor

cpuguy83 commented Feb 13, 2015

I like this. It makes sense that we not bother trying to implement readers for log drivers since the whole point of alternative drivers is to get the logs out of docker, we can recommend the default logger only for dev environments.

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Feb 13, 2015

Contributor

@SvenDowideit I tried to fix :) not sure that found all places.

Contributor

LK4D4 commented Feb 13, 2015

@SvenDowideit I tried to fix :) not sure that found all places.

@x1022as

This comment has been minimized.

Show comment
Hide comment
@x1022as

x1022as Feb 15, 2015

Contributor

How about adding a signal handler to reopen log file for logrotate?

Contributor

x1022as commented Feb 15, 2015

How about adding a signal handler to reopen log file for logrotate?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 15, 2015

Contributor

@x1022as This doesn't work all that well since the signal would need to be sent to the docker daemon, which may be handling hundreds/thousands of containers... it's just weird, and also could cause a lot of problems.

If you want to use logrotate to truncate the container's default logs, I'd recommend just pausing the container, do copy-truncate, unpause.

Contributor

cpuguy83 commented Feb 15, 2015

@x1022as This doesn't work all that well since the signal would need to be sent to the docker daemon, which may be handling hundreds/thousands of containers... it's just weird, and also could cause a lot of problems.

If you want to use logrotate to truncate the container's default logs, I'd recommend just pausing the container, do copy-truncate, unpause.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Feb 15, 2015

Contributor

@x1022as Also, once there are additional drivers (like syslog) added, I suspect the default logger would be recommended only for development purposes.

Contributor

cpuguy83 commented Feb 15, 2015

@x1022as Also, once there are additional drivers (like syslog) added, I suspect the default logger would be recommended only for development purposes.

@wuub

This comment has been minimized.

Show comment
Hide comment
@wuub

wuub Feb 15, 2015

@cpuguy83: do you know which drivers can we expect in the initial release? syslog is probably easy to implement (in golang's stdlib). have you considered journal/systemd? with more and more Linux distros choosing systemd it can be a good second choice.

wuub commented Feb 15, 2015

@cpuguy83: do you know which drivers can we expect in the initial release? syslog is probably easy to implement (in golang's stdlib). have you considered journal/systemd? with more and more Linux distros choosing systemd it can be a good second choice.

@@ -1929,6 +1929,10 @@ func (cli *DockerCli) CmdLogs(args ...string) error {
return err
}
if env.GetSubEnv("HostConfig").GetSubEnv("LogConfig").Get("Type") != "json-file" {

This comment has been minimized.

@calavera

calavera Mar 13, 2015

Contributor

It looks like this is returning an nil reference on windows. Maybe it would be safer to check the returned values instead of chaining them all together:

https://jenkins.dockerproject.com/job/Windows-PRs/307/console

@calavera

calavera Mar 13, 2015

Contributor

It looks like this is returning an nil reference on windows. Maybe it would be safer to check the returned values instead of chaining them all together:

https://jenkins.dockerproject.com/job/Windows-PRs/307/console

This comment has been minimized.

@LK4D4

LK4D4 Mar 13, 2015

Contributor

That's weird :/

@LK4D4

LK4D4 Mar 13, 2015

Contributor

That's weird :/

This comment has been minimized.

@LK4D4

LK4D4 Mar 13, 2015

Contributor

It shouldn't be like this. All logs tests failing too. ping @ahmetalpbalkan

@LK4D4

LK4D4 Mar 13, 2015

Contributor

It shouldn't be like this. All logs tests failing too. ping @ahmetalpbalkan

This comment has been minimized.

@ahmetb

ahmetb Mar 13, 2015

Contributor

@LK4D4 hmm it's happening because daemon doesn't have your changes yet. we use another Docker daemon we periodically update. @jfrazelle

you might want to spin up a windows VM, follow @jfrazelle's docs to get the env ready on windows and configure tests to talk to the daemon you just built with this PR.

@ahmetb

ahmetb Mar 13, 2015

Contributor

@LK4D4 hmm it's happening because daemon doesn't have your changes yet. we use another Docker daemon we periodically update. @jfrazelle

you might want to spin up a windows VM, follow @jfrazelle's docs to get the env ready on windows and configure tests to talk to the daemon you just built with this PR.

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 14, 2015

Contributor

cool! Thanks @jfrazelle , you're the best.

Contributor

LK4D4 commented Mar 14, 2015

cool! Thanks @jfrazelle , you're the best.

@sirupsen

This comment has been minimized.

Show comment
Hide comment
@sirupsen

sirupsen Mar 14, 2015

Contributor

This is really exciting work @LK4D4, something we've looked forward to for a long time for our deployment. I'm going to take a closer look at this over the weekend

Contributor

sirupsen commented Mar 14, 2015

This is really exciting work @LK4D4, something we've looked forward to for a long time for our deployment. I'm going to take a closer look at this over the weekend

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 14, 2015

Contributor

@sirupsen thanks a lot. Your opinion about logging would be really great.

Contributor

LK4D4 commented Mar 14, 2015

@sirupsen thanks a lot. Your opinion about logging would be really great.

if err := c.dst.Log(&Message{ContainerID: c.cid, Line: scanner.Bytes(), Source: name, Timestamp: time.Now().UTC()}); err != nil {
logrus.Errorf("Failed to log msg %q for logger %s: %s", scanner.Bytes(), c.dst.Name(), err)
}
}

This comment has been minimized.

@dqminh

dqminh Mar 16, 2015

Contributor

I dont think splitting of log output should be a common step that is applied to all loggers. I think it's much better to let the logger handle its own framing/splitting chunks of data into individual messages. For example:

  1. line-based splitting for json
  2. custom splitting because the application outputs binary-format log.
  3. regex-based splitting etc..
@dqminh

dqminh Mar 16, 2015

Contributor

I dont think splitting of log output should be a common step that is applied to all loggers. I think it's much better to let the logger handle its own framing/splitting chunks of data into individual messages. For example:

  1. line-based splitting for json
  2. custom splitting because the application outputs binary-format log.
  3. regex-based splitting etc..

This comment has been minimized.

@LK4D4

LK4D4 Mar 16, 2015

Contributor

Hmm, maybe you're right. But this copier is okay for 90% cases. When there will be need - we can move copier to drivers.

@LK4D4

LK4D4 Mar 16, 2015

Contributor

Hmm, maybe you're right. But this copier is okay for 90% cases. When there will be need - we can move copier to drivers.

@gdm85

This comment has been minimized.

Show comment
Hide comment
@gdm85

gdm85 Mar 16, 2015

Contributor

A companion tool that I use to log containers: https://github.com/mozilla-services/heka

Hopefully it's not going to be rewritten for all the possible log output plugins :)

Contributor

gdm85 commented Mar 16, 2015

A companion tool that I use to log containers: https://github.com/mozilla-services/heka

Hopefully it's not going to be rewritten for all the possible log output plugins :)

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 16, 2015

Contributor

@gdm85 I would be glad to hear how to avoid that :)

Contributor

LK4D4 commented Mar 16, 2015

@gdm85 I would be glad to hear how to avoid that :)

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Mar 16, 2015

Contributor

LGTM

Contributor

jessfraz commented Mar 16, 2015

LGTM

@gdm85

This comment has been minimized.

Show comment
Hide comment
@gdm85

gdm85 Mar 17, 2015

Contributor

@LK4D4 I think this work of yours is really a great (and necessary) addition! My comment was more along the lines: logging can easily become a complex beast. For example:

  • reliability: what happens when there is a failure at delivering log information via network? Dropping it would not cover all use-cases, as an user might desire/require to have no logging information lost over time, under different system conditions.
  • systems interaction: what happens if application needs to log synchronously and there is a delay in delivering the log? Applications are hardly using synchronized writes to stdout/stderr (or flushes, for that matter), but still it needs to be addressed what happens in case the logging plugin itself is delivering logging information synchronously/asynchronously and the "sink" is somehow slow/unresponsive. (This is more about the involved buffers and who is the responsible actor).

So these are concerns to consider when extending the functionality (even in officially provided Docker logging plugins, if any), and generally my philosophy is: either do it right, or make a simple interface so that more complex tools (right for the job (™)) can be used :)

Contributor

gdm85 commented Mar 17, 2015

@LK4D4 I think this work of yours is really a great (and necessary) addition! My comment was more along the lines: logging can easily become a complex beast. For example:

  • reliability: what happens when there is a failure at delivering log information via network? Dropping it would not cover all use-cases, as an user might desire/require to have no logging information lost over time, under different system conditions.
  • systems interaction: what happens if application needs to log synchronously and there is a delay in delivering the log? Applications are hardly using synchronized writes to stdout/stderr (or flushes, for that matter), but still it needs to be addressed what happens in case the logging plugin itself is delivering logging information synchronously/asynchronously and the "sink" is somehow slow/unresponsive. (This is more about the involved buffers and who is the responsible actor).

So these are concerns to consider when extending the functionality (even in officially provided Docker logging plugins, if any), and generally my philosophy is: either do it right, or make a simple interface so that more complex tools (right for the job (™)) can be used :)

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 17, 2015

Contributor

@gdm85 The weak point is copier now, but if we wanted structured logging then we need it. Maybe we can somehow improve it later. Apart from this any solution can be implemented based on Logger interface.

Contributor

LK4D4 commented Mar 17, 2015

@gdm85 The weak point is copier now, but if we wanted structured logging then we need it. Maybe we can somehow improve it later. Apart from this any solution can be implemented based on Logger interface.

@calavera

This comment has been minimized.

Show comment
Hide comment
@calavera

calavera Mar 17, 2015

Contributor

@gdm85 addresses really good concerns, but I feel like they're something that can be tackled after shipping this first implementation. There is never going to be a perfect solution, specially if we want to enter the network partitions space.

My vote(if it's any valuable) would be to merge this, gather more feedback with real use cases and keep iterating.

Contributor

calavera commented Mar 17, 2015

@gdm85 addresses really good concerns, but I feel like they're something that can be tackled after shipping this first implementation. There is never going to be a perfect solution, specially if we want to enter the network partitions space.

My vote(if it's any valuable) would be to merge this, gather more feedback with real use cases and keep iterating.

defer func() {
container.hostConfig.LogConfig = runconfig.LogConfig{}
}()
}

This comment has been minimized.

@icecrime

icecrime Mar 17, 2015

Contributor

I don't really understand the need for this. In all cases, shouldn't we better copy the hostConfig structure and modifying the copy instead of altering the container config in place?

@icecrime

icecrime Mar 17, 2015

Contributor

I don't really understand the need for this. In all cases, shouldn't we better copy the hostConfig structure and modifying the copy instead of altering the container config in place?

This comment has been minimized.

@LK4D4

LK4D4 Mar 17, 2015

Contributor

Maybe, I just copied behavior of links. Want me to fix that in this PR?

@LK4D4

LK4D4 Mar 17, 2015

Contributor

Maybe, I just copied behavior of links. Want me to fix that in this PR?

This comment has been minimized.

@icecrime

icecrime Mar 17, 2015

Contributor

I didn't see the Links code above. Let's keep this as it is, I'll change both in a later PR.

@icecrime

icecrime Mar 17, 2015

Contributor

I didn't see the Links code above. Let's keep this as it is, I'll change both in a later PR.

@gdm85

This comment has been minimized.

Show comment
Hide comment
@gdm85

gdm85 Mar 17, 2015

Contributor

@LK4D4 that's already fair enough for me :)

Contributor

gdm85 commented Mar 17, 2015

@LK4D4 that's already fair enough for me :)

@icecrime

This comment has been minimized.

Show comment
Hide comment
@icecrime

icecrime Mar 17, 2015

Contributor

LGTM 👍

Contributor

icecrime commented Mar 17, 2015

LGTM 👍

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 17, 2015

Contributor

@icecrime It have three LGTMS from docs team btw :)

Contributor

LK4D4 commented Mar 17, 2015

@icecrime It have three LGTMS from docs team btw :)

@icecrime

This comment has been minimized.

Show comment
Hide comment
@icecrime

icecrime Mar 17, 2015

Contributor

:facepalm:

Contributor

icecrime commented Mar 17, 2015

:facepalm:

icecrime pushed a commit that referenced this pull request Mar 17, 2015

@icecrime icecrime merged commit 1ff5a91 into moby:master Mar 17, 2015

2 checks passed

janky Jenkins build Docker-PRs 3284 has succeeded
Details
windows Jenkins build Windows-PRs 338 has succeeded
Details

@vieux vieux removed the status/4-merge label Mar 17, 2015

@LK4D4 LK4D4 deleted the LK4D4:logging_drivers branch Mar 17, 2015

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 17, 2015

Contributor

@ibuildthecloud Waiting for your PRs! We still have chance to merge them to 1.6

Contributor

LK4D4 commented Mar 17, 2015

@ibuildthecloud Waiting for your PRs! We still have chance to merge them to 1.6

@sirupsen

This comment has been minimized.

Show comment
Hide comment
@sirupsen

sirupsen Mar 17, 2015

Contributor

@LK4D4 @ibuildthecloud would be awesome to see syslog in 1.6 for sure.

Contributor

sirupsen commented Mar 17, 2015

@LK4D4 @ibuildthecloud would be awesome to see syslog in 1.6 for sure.

@sirupsen

This comment has been minimized.

Show comment
Hide comment
@sirupsen

sirupsen Mar 17, 2015

Contributor

@LK4D4 my only concern with this is what if I want to write crazy-log-driver-0mg that nobody in upstream Docker has any need for?

That would mean I'd have to fork Docker, and I don't think upstream Docker is interested in e.g. a Kafka driver, msgpack driver, some other logging API over HTTP etc., only major use cases like syslog and systemd I see make it into Docker core. As I see it there's a number of ways to solve this, what are your thoughts on this? Named pipe driver?

Contributor

sirupsen commented Mar 17, 2015

@LK4D4 my only concern with this is what if I want to write crazy-log-driver-0mg that nobody in upstream Docker has any need for?

That would mean I'd have to fork Docker, and I don't think upstream Docker is interested in e.g. a Kafka driver, msgpack driver, some other logging API over HTTP etc., only major use cases like syslog and systemd I see make it into Docker core. As I see it there's a number of ways to solve this, what are your thoughts on this? Named pipe driver?

@ibuildthecloud

This comment has been minimized.

Show comment
Hide comment
@ibuildthecloud

ibuildthecloud Mar 18, 2015

Contributor

@LK4D4 @sirupsen syslog -> #11458, rollover coming hopefully in the next hour or so

Contributor

ibuildthecloud commented Mar 18, 2015

@LK4D4 @sirupsen syslog -> #11458, rollover coming hopefully in the next hour or so

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 18, 2015

Contributor

@sirupsen I thought about generic driver, which just writes serialized messages to tcp socket. Only configuration is host:port and serialization/compress protocol(that makes sense to support I think).

Contributor

LK4D4 commented Mar 18, 2015

@sirupsen I thought about generic driver, which just writes serialized messages to tcp socket. Only configuration is host:port and serialization/compress protocol(that makes sense to support I think).

@tiborvass

This comment has been minimized.

Show comment
Hide comment
@tiborvass

tiborvass Mar 18, 2015

Collaborator

@sirupsen I believe that will be done with docker plugins/extensions. Until then, an alternative once the syslog PR is merged, is to write an adapter that receives syslog messages and forwards them to your custom logging server transforming the message on the fly.

Collaborator

tiborvass commented Mar 18, 2015

@sirupsen I believe that will be done with docker plugins/extensions. Until then, an alternative once the syslog PR is merged, is to write an adapter that receives syslog messages and forwards them to your custom logging server transforming the message on the fly.

@sirupsen

This comment has been minimized.

Show comment
Hide comment
@sirupsen

sirupsen Mar 20, 2015

Contributor

@LK4D4 I was going to start working on the TCP driver, but couple of implementation questions: What should the command line interface be like for configuring the address and serialization? Does TCP really make more sense than UDP here? Fire-and-forget seems somewhat reasonable, given that the client's logging daemon may have crashed. For similar reasons I didn't want to implement a named pipe, because a crashed client could cause the container to hang easily. Of course we can protect against that, but it seems reasonable to use a protocol that handles that entirely. Perhaps we just need both.

Contributor

sirupsen commented Mar 20, 2015

@LK4D4 I was going to start working on the TCP driver, but couple of implementation questions: What should the command line interface be like for configuring the address and serialization? Does TCP really make more sense than UDP here? Fire-and-forget seems somewhat reasonable, given that the client's logging daemon may have crashed. For similar reasons I didn't want to implement a named pipe, because a crashed client could cause the container to hang easily. Of course we can protect against that, but it seems reasonable to use a protocol that handles that entirely. Perhaps we just need both.

@LK4D4

This comment has been minimized.

Show comment
Hide comment
@LK4D4

LK4D4 Mar 20, 2015

Contributor

@sirupsen I'm okay with UDP. Settings for logging were proposed in #11485 and I think design is okay.

Contributor

LK4D4 commented Mar 20, 2015

@sirupsen I'm okay with UDP. Settings for logging were proposed in #11485 and I think design is okay.

@sirupsen

This comment has been minimized.

Show comment
Hide comment
@sirupsen

sirupsen Mar 22, 2015

Contributor

@tiborvass can you tell me more about this planned Docker plugin/extensions API? Curious.

Contributor

sirupsen commented Mar 22, 2015

@tiborvass can you tell me more about this planned Docker plugin/extensions API? Curious.

@rgbkrk

This comment has been minimized.

Show comment
Hide comment
@rgbkrk

rgbkrk Mar 23, 2015

Thank you so much for this @LK4D4 and the Docker team overall for the great review+inclusion. Excited for 1.6 release!

rgbkrk commented Mar 23, 2015

Thank you so much for this @LK4D4 and the Docker team overall for the great review+inclusion. Excited for 1.6 release!

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