Feedback from the mailing list:

A "stack trace" can be useful sometimes. What about adding a special "stack" key to the log functions (or better, a logger.XxxStack functions) which store the callers in the context.'

It's a difficult API design problem:

• Adding new XxxStack functions is too onerous on the API.
• A simple handler can't just add them because it would end up generating the stack from within the handler tree.
• Maybe a handler could add them but it would have to do something smart where it walks up the captured stack frames and removes each frame until it reaches the caller of a Logger interface method.

Most likely, the best option is that this should be a new top-level function that you would use as a context value that we would know how to format nicely for you:

logger.Error("something went horribly wrong", "stack", log.Stack())

Note that it wouldn't work well with log.Lazy though (you'd end up with frames from the handler tree in the traceback).

How is it formatted as output? Newline escaping will produce an unreadable mess when looking at log files or on the terminal. grohl does something interesting where it splits the stack into multiple log messages which is interesting to consider:

t=12412323 lvl=error stack=First line of stack trace
t=12412323 lvl=error stack=Second line of stack trace
t=12412323 lvl=error stack=Third line of stack trace

Maybe this format could just be used for the TerminalFormat.

$ GOPATH=$GOPATH:/tmp /usr/bin/go test gopkg.in/inconshreveable/log15.v2/...
ok      gopkg.in/inconshreveable/log15.v2   0.091s
ok      gopkg.in/inconshreveable/log15.v2/ext   0.041s
--- FAIL: TestCallFormat (0.00s)
    stack_test.go:80: fmt.Sprintf("%+s", Call(func)) = gopkg.in/inconshreveable/log15.v2/stack/stack_test.go, want ../../../gopath/src/gopkg.in/inconshreveable/log15.v2/stack/stack_test.go
    stack_test.go:80: fmt.Sprintf("%+v", Call(func)) = gopkg.in/inconshreveable/log15.v2/stack/stack_test.go:24, want ../../../gopath/src/gopkg.in/inconshreveable/log15.v2/stack/stack_test.go:24
    stack_test.go:80: fmt.Sprintf("%+s", Call(meth)) = gopkg.in/inconshreveable/log15.v2/stack/stack_test.go, want ../../../gopath/src/gopkg.in/inconshreveable/log15.v2/stack/stack_test.go
    stack_test.go:80: fmt.Sprintf("%+v", Call(meth)) = gopkg.in/inconshreveable/log15.v2/stack/stack_test.go:18, want ../../../gopath/src/gopkg.in/inconshreveable/log15.v2/stack/stack_test.go:18
FAIL
FAIL    gopkg.in/inconshreveable/log15.v2/stack 0.002s
?       gopkg.in/inconshreveable/log15.v2/term  [no test files]

This turns out to be more tricky than one would hope. Best options that I can think of are:

1. Change the Handler interface to pass calldepth through and require every implementing handler to appropriately increment it as it goes through the handler tree.
2. Add another implementation of the Logger interface which includes these parameters in the context. Basically adding a NewSourceInfoLogger call (or something similar).
3. Change the default logger implementation to always take the performance hit (I haven't measured this yet) of doing runtime.Callers and adding those values as fields in the log.Record. An optional handler could be used to inject them into the context.

Relevant thread on go-nuts: https://groups.google.com/forum/#!topic/golang-nuts/_EdGGCwY1AI

If you pass a typed nil pointer to the context,

Example:

if player is nil

    log.Warn("Remove issue", log.Ctx{"tier": tier, "player": player, "reason": "player does not exist in cache"})

You will get a panic when the struct's auto generated .String is called using a nil pointer.

This will happen here:

format.go:178

func formatShared(value interface{}) interface{} {
        switch v := value.(type) {
    case time.Time:
        return v.Format(timeFormat)

    case error:
        return v.Error()

    case fmt.Stringer:
        return v.String()

    default:
        return v
    }
}

This may be a known issue, but I could see accidentally having nil's sent in. From what I have read, to address this, reflect may be needed which would incur an overhead and may not be desired. I thought I'd open this issue to find out if this is deemed an issue. If not, what the best practices are to work around this.

This should probably be mentioned in the Docs. This might also affect users who run on Google App Engine, which AFAIK still runs on Go 1.2.

Alternatively we could add a build tag to the go files. Speaking of which, I will create a PR ;)

Hi. Are there any plans for providing a shortcut for printf, style formatting or is it idiomatic to write:

log.Info(fmt.Sprintf("some text: %d > %d", max, min), "someCtx", 42)

It seems sort of verbose, but I could live with it.

Then another thing, which I tried to look up in the README and the docs but couldn't find. I assume logging error (the Go error type) values happens quite a lot. What is the usual way to deal with this? I have two options, both of which don't really feel that good:

// #1
log.Info(err.Error())

// #2
log.Info("while processing XXX", "error", err)

The first probably doesn't give enough information. The second one feels a bit better but I'm not sure about the key. Should I use "error"?

Seems like appengine golang currently fails the build because this !appengine isn't being parsed properly. I believe comma-separating the fields is the correct fix there? It functions after this change locally.

escapeString() is very expensive, and we never need to escape time.Time's that have been formatted with timeFormat, so let's return time.Time's early instead of escaping them.

This saves a lot of allocations:

benchmark                        old ns/op     new ns/op     delta
BenchmarkStreamNoCtx-4           4761          4043          -15.08%
BenchmarkDiscard-4               818           788           -3.67%
BenchmarkCallerFileHandler-4     1892          1861          -1.64%
BenchmarkCallerFuncHandler-4     1690          1647          -2.54%
BenchmarkLogfmtNoCtx-4           3579          2886          -19.36%
BenchmarkJsonNoCtx-4             1650          1649          -0.06%
BenchmarkMultiLevelFilter-4      850           833           -2.00%
BenchmarkDescendant1-4           835           805           -3.59%
BenchmarkDescendant2-4           858           838           -2.33%
BenchmarkDescendant4-4           930           894           -3.87%
BenchmarkDescendant8-4           974           957           -1.75%

It's highly possible there's a better way to do this, maybe have formatShared() return a returnEarly bool or something.

Reported failure here: https://github.com/kevinburke/rest/pull/4#issuecomment-277801954

I've been unable to reproduce it, because you can't specify GOOS=appengine and compile the build. Need to set up the App Engine SDK locally and test using that OS.

If I had to guess, I would guess that App Engine is not a subset of linux and so the terminal_notwindows.go file also compiles there.

In #51 @ChrisHines wrote:

[..] It is mildly annoying that one must import log15.v2 in order to implement a Handler (because of the *log15.Record argument). So Handlers are always coupled to log15.v2. This may cause problems down the road for people that implement custom handlers in a library. Consumers of such Handlers will have a harder time upgrading to a putative log15.v3 because I'm pretty sure that all the Handlers in an application must have the same import path for *Record. I'm not sure what to do about that yet.

Excelent point! Even though the Record structure stays the same, the types will be incompatible because the qualified identifier is different.

inconshreveable/log15.v2/record One solution would be moving Record to it's own package log15.v2/record. Then log15.v3 will still import log15.v2/record, as will everyone that writes a custom handler. If at v6 we want to make a breaking change the Record type, then log15.v6 will import log15.v6/record, and everyone will have to update their Handlers to work with v6.

inconshreveable/log15record.v1 The strange thing about the above log15.v2/record subpackage is that if you modify the Record in a non-breaking way (add a field at the bottom of the struct), then those changes must be made in log15.v2, even if the most recent log15 version is actually at v4. And it's also a bit strange that log15.v{3,4,5}/record are never used.. So another solution might be to create a new repo inconshreveable/log15record (package record) that starts at v1, and when breaking changes are made moves to v2..

In both cases, Lvl and RecordKeyNames must also move to the new package. Ctx doesn't necessarily have to move because on the record the field type for the context is []interface{}, but if log15.Ctx is used by third-party projects (I don't know if that's the case), it might move to record.Ctx as well to solve the same incompatibility problem.

First off, great stuff. I'm glad you put the time in to build such a great log library.

I was wondering, though, would it be possible to make the time, level, and message keys configurable? Does that seem reasonable?

https://github.com/inconshreveable/log15/blob/master/format.go#L77 https://github.com/inconshreveable/log15/blob/master/format.go#L121

I think that would allow for better integration into systems that are expecting different keys for those values.

Thanks!

Currently if logger is passed to another package it would still show only a file name within that package.

This may cause issues with finding correct file (there may be identically named files in different packages).

It can be worked around by chaining CallerFileHandler with CallerFuncHandler. Both are lacking in functionality. CallerFuncHandler will only show function name with package name, but not file line in this function. CallerFileHandler will show file name with line, but not package.

First of all thanks for creating this library with such a beautiful API

My concern is that I don't see any new commits in the past couple of years and important PRs like go module addition is not having much of a discussion and is not being merged

What is the future of this project ?

It appears that go mod does not recognize the current tagging scheme of log15 and always pulls the master. Couls you please use semantic versioning to satisfy it? Changing v2.15 -> v2.15.0 should o the trick. If you could also create v2.15.0 tag in addition to v2.15, that would be great.

Hi Here is my contribution to your code, its working good on powersystems.

Thanks for the code, its working good.

What do these changes do?

Added Architecture "ppc64le"

Are there changes in behavior for the user?

No

This PR replaces the escapeString function with the more stricter quoting done by strconv. Previously, special non-printable characters such as bash escape characters could be allowed through. Such characters can change the terminal colour, break lines, delete previously printed characters etc, and may represent a security vulnerability in the application using this library.

~~This PR does change API a bit, since previously log15 did not quote all messages, if they were deemed to not require quoting. It would be possible to revert that change, but I actually think it's better to be consistent, so I didn't add the extra checks to see if the value should be un-quoted again.~~

This PR now avoids quoting messages that are plain lower range ascii. It does now quote otherwise printable messages with characters like äö, which was not previously quoted.