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
#65 (comment).

[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
#65 (comment).

[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
#65 (comment).

[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
#65 (comment).