-
Notifications
You must be signed in to change notification settings - Fork 879
NG: Logging #635
Comments
On Thu, Oct 16, 2014 at 10:22:05AM -0700, Derek McGowan wrote:
If we use a reverse-proxy for serious deployments (see #623), we can |
I believe, that this approach looks good: |
While log routing doesn't need to dictate the topics above, some possible routers we may want to integrate and ensure our format works nicely with. |
We do want access logs from the registry - this is the only way you are going to be able to tell if your proxy is actually sending the request back We also want exhaustive application logging (including context, etc). This is absolutely needed at least to debug. The default behavior should be to have these to stdout. |
On Wed, Oct 22, 2014 at 11:25:45AM -0700, Olivier Gambier wrote:
Won't you get timeout errors in the reverse-proxy logs if the registry
I don't think there will be much going on in the registry itself.
That would probably be fine, since I expect only registry devs will |
@wking arguing about technical points (and agreeing, or disagreeing on them) is perfectly fine. On the other hand, discarding valid use-cases is not :-) I do want access logs on the registry, since the registry is a standalone product, and not everyone is willing to run it behind nginx. This is a standard feature of about every standalone web application, and just because it's possible to do otherwise with proxy monkeying (that I'm advising against) doesn't mean we should ignore it altogether. Still, to keep addressing these:
Why would a timeout be the only case? What about hitting the wrong backend?
Well, there is a lot :-).
Read my lips:
Proxy support in registry v1 has been a terrible train wreck, and a liability for anyone who tried that in high-scale production. I don't expect things to go very differently with v2, and I intend in making sure we don't bind ourselves to such a design - although I genuinely want people to be able to rope themselves with it if they would want that :-)
So, what happens then? Developers don't have a clean way to log thing, they start using various libraries. I refuse to merge that because it's messy, and they will switch to no log at all, or printf, and we end-up with a poorly debuggable project failing to properly log information about its behavior. Since it's so crappy, it's not picked-up by ISV who want to build on it or ship it as a product, it's hard to post-mortem errors in it, and ultimately I'm not happy :)
Having auditable logs, and a robust logging infrastructure is IMHO a standard feature of any serious software. I want this to be designed and dogfed from the start since it will be harder to get right down the road. |
On Wed, Oct 22, 2014 at 04:09:28PM -0700, Olivier Gambier wrote:
Agreed. I'm just pushing to try and see what those use-cases are.
Assuming we get the proxy bits sorted (and with Nginx's ticket 251,
For storage? I'm not sure how the multi-backend storage works. How
I'm hoping we can just provide HTTP notification for our actions, and
Sure. I'm happy if folks want to write a reverse-proxy layer in Go
I just didn't have a clear idea of how it was going wrong before 1.
Whenever we get a report from someone that things are buggy, we ask
I agree. I'm just not convinced that the registry is the place for
Maybe I'm just arguing that we should punt here until we actually have |
On Wed, Oct 22, 2014 at 04:58:36PM -0700, W. Trevor King wrote:
And for what it's worth, Go seems to have a logger 1 with an |
On Wed, Oct 22, 2014 at 05:16:49PM -0700, W. Trevor King wrote:
And if the Docker client isn't using that ‘log’ package now, it was |
@wking said:
So in my case I might actually terminate SSL with an F5 BIG-IP Local Traffic Manager and then run the registry behind that. For instance, use a WIP for routing to the nearest region, a VIP per region, and then put a registry or cluster of registries behind a few HAProxies per region. I'm definitely interested in having these registries used a distributed shared storage. But I think @dmp42 has a point in wanting the registries to do the logging. I don't think we should require the proxy to generate the access/error logs. |
@wking said:
That's super interesting. Looking at the diff didnt make it obvious to me what the interaction was with /dev/me Flannel is using https://github.com/golang/glog which looked nice (which I now see was mentioned in the original post). @dmcgowan said:
Maybe we take a page out of the Elliptics playbook and let the user configure the log output format and wiring. Then we punt and provide sane defaults to stdout/stderr and test that we provide enough flexibility to customize the output to be compatible with those other utilities. |
On Fri, Oct 24, 2014 at 09:36:32PM -0700, Raymond Barbiero wrote:
You can log to syslog with HAProxy too 1. And obviously, FWIW, Go's built-in server uses the built-in log framework for errors |
Docker has just switched over to using logrus as of moby/moby#8770, so I propose that we use this for consistent formatting and hooks across the entire product. As for log rotation, we can use lumberjack as our log output writer. This package supports max file size and age for rotation and claims to be compatible with the standard go logging semantics, the same as logrus, so these should theoretically work together. |
+1 on both logrus and lumberjack, logrus supports pretty tty output, default logfmt output for non-tty and optional json output. Also for tracing and contextual logging, this golang blog post is a few months old but it is relevant to creating a standard. https://blog.golang.org/context
|
Summing things up:
What needs to be done:
|
On Tue, Oct 28, 2014 at 01:37:10PM -0700, Olivier Gambier wrote:
I'm still pushing for extensions and storage drivers to be separate |
That should not be the default (and not what we encourage people to do) - but then I don't see a reason to prevent it if someone wants to go crazy with that :) |
Superseded by distribution/distribution#86. |
Define a standard way to log across in the registry in a uniform and easy to process manner. Some topics to decide on...
The main concern is balancing a uniform method and format with something that is flexible. Flexibility meaning customization can be done on top of what is decided, and questions about whether to use volumes, which agent forwarder, or pipe logs through log rotation script X don't need to be discussed here.
The text was updated successfully, but these errors were encountered: