Replace Debug function with a Debugger interface to permit trace recording.

[ghost]

Debug is useful for getting additional output, but in some environments it would be more powerful to have information on the actual trace spans.

Replace the current function with an interface that supports Begin/End/Print.

[tv42]

I'm very much open to doing something better with logging, probably along the lines of https://github.com/codahale/lunk but I'm not quite sure what your motivation here is. You do realize you can already pair up request/response by the ID, right? Do you have a concrete example of how you want to use this?

[ghost]

Not an example I can share directly, but the purpose of this is my log file format is structured.

I record timing as well as memory and CPU stats per log point and intend to support HAR file output for visual examination.

I can do that via parsing but this feels less brittle. Ideally I'd also like the trace span identifier in the Context to generate child traces.

Nick. On 26 Feb 2015 3:28 pm, "Tv" [email protected] wrote:

I'm very much open to doing something better with logging, probably along the lines of https://github.com/codahale/lunk but I'm not quite sure what your motivation here is. You do realize you can already pair up request/response by the ID, right? Do you have a concrete example of how you want to use this?

— Reply to this email directly or view it on GitHub https://github.com/bazillion/fuse/pull/65#issuecomment-76120564.

[tv42]

Thank you. That's enough information that I think you'd be served well enough by having a trace ID in the messages and a good built-in "end processing" message, and that's what I wanted to do anyway. Most likely using http://godoc.org/github.com/codahale/lunk

The elapsed time logging I would probably perform in fuse itself, much like http://godoc.org/github.com/codahale/lunk/web

The one big thing I don't like about lunk is that it's concept of properties forces a flat structure, but that seems to be a common line of thinking among structured logging advocated, so I guess I'll just go ahead with that.

Can you look into lunk and see if it matches what you want?

[ghost]

Lunk would work- but I think we should not use it here. FUSE is in theory one component of a system where the logging structure is across the entire structure.

As such minimal proscription of logging hooks such that it can be used with any logging system feels preferable, it is the approach I took here.

You could readily use lunk with this structure, or just log.

Thoughts? Not tied to my particular choices but making it flexible feels desirable.

Nick. On 27 Feb 2015 2:02 am, "Tv" [email protected] wrote:

Thank you. That's enough information that I think you'd be served well enough by having a trace ID in the messages and a good built-in "end processing" message, and that's what I wanted to do anyway. Most likely using http://godoc.org/github.com/codahale/lunk

The elapsed time logging I would probably perform in fuse itself, much like http://godoc.org/github.com/codahale/lunk/web

The one big thing I don't like about lunk is that it's concept of properties forces a flat structure, but that seems to be a common line of thinking among structured logging advocated, so I guess I'll just go ahead with that.

Can you look into lunk and see if it matches what you want?

— Reply to this email directly or view it on GitHub https://github.com/bazillion/fuse/pull/65#issuecomment-76192735.

[tv42]

I'd love to have an interface that's sufficient for lunk but not tied to it.

[ghost]

So, basically the current pull req is sufficient; the only change to further be lunk-y would be instead of a opaque msg interface{} I would report a key-value map?

On Fri Feb 27 2015 at 9:57:18 AM Tv [email protected] wrote:

I'd love to have an interface that's sufficient for lunk but not tied to it.

— Reply to this email directly or view it on GitHub https://github.com/bazillion/fuse/pull/65#issuecomment-76293557.

[tv42]

Definitely something more explicit than interface{}. I can't tell at this moment whether the proposed change is otherwise enough to support lunk. Rest assured this is within my own interests, I'll come back to it.

[ghost]

Well, to use this with Lunk is your logger would create Events in Begin/Print; end then End would use the EventID from Begin as a 'parent event'

Properties would be solely {msg, msg.String()}

On Fri Feb 27 2015 at 11:06:54 AM Tv [email protected] wrote:

Definitely something more explicit than interface{}. I can't tell at this moment whether the proposed change is otherwise enough to support lunk. Rest assured this is within my own interests, I'll come back to it.

— Reply to this email directly or view it on GitHub https://github.com/bazillion/fuse/pull/65#issuecomment-76303260.