I know this thread is old... But for people that are looking for some
simple logging by level functionality I have added basic logging levels to
the default Go log package. You can find my changes here:
https://github.com/gologme/log
In addition to adding Info, Warn, and Debug, users can also
Thx Chris, that's unfortunate it was many years until the Java world
settled on something that worked in spite of having a built-in log
package.
This is truly an area where we seem to repeat the mistakes of the past.
On Thu, 17 Aug 2017, 18:11 Chris Hines wrote:
> On Thursday, August 17, 2017
On Thursday, August 17, 2017 at 3:14:09 AM UTC-4, Henrik Johansson wrote:
>
> Sorry to but in but what happened to the whole logging initiative that was
> on going?
> Did I miss something about that? It seems very related to this.
>
That discussion took place in this thread:
https://groups.googl
Christian,
By where I mean package/file.go:lineNumber which I have a helper method for
that:
//-
var (
errNotAvailable = errors.New("N/A")
)
// Here .
func Here(skip ...int) (funcName, fileName string, fileLine in
On Thursday, August 17, 2017 at 11:40:08 AM UTC+2, dc0d wrote:
>
> That's a nice package with good design (and I've used it for a while). But
> I loose the info about where the error is happening.
>
What do you mean by where the error is happening?
Have you checked
out
http://godoc.org/github.
That's a nice package with good design (and I've used it for a while). But
I loose the info about where the error is happening.
On Thursday, August 17, 2017 at 11:59:10 AM UTC+4:30, Peter Mogensen wrote:
>
>
>
> On 2017-08-17 09:24, dc0d wrote:
> > Logging from a specific place in code helps wit
On 2017-08-17 09:24, dc0d wrote:
> Logging from a specific place in code helps with finding out /where/ the
> error happened. And doing that manually is cumbersome. I for one can not
> give-up on this because it makes fixing things super fast.
github.com/pkg/errors
...solves many of those probl
Henrik,
Here I've tried to put a sample (other than the built-in log package) for
cases that global stuff makes things more clear and pragmatic (IMHO).
On Thursday, August 17, 2017 at 11:44:09 AM UTC+4:30, Henrik Johansson
wrote:
>
> Sorry to but in but what happened to the whole logging initia
Logging from a specific place in code helps with finding out *where* the
error happened. And doing that manually is cumbersome. I for one can not
give-up on this because it makes fixing things super fast.
Fortunately current logging packages (like zap) take care of that case by
providing the op
Sorry to but in but what happened to the whole logging initiative that was
on going?
Did I miss something about that? It seems very related to this.
tors 17 aug. 2017 kl 09:10 skrev dc0d :
> As they say global variables/things are bad. But I even use a global
> Context and WaitGroup for signaling
As they say global variables/things are bad. But I even use a global
Context and WaitGroup for signaling the termination of the whole program.
On exit the context will get canceled and the program waits for the
WaitGroup with a timeout. I would like to have those inside another
built-in package
On 2017-08-15 21:34, Tamás Gulácsi wrote:
> Even better: my libraries expose only the LogFunc: i.e.
> var Log = func(keyvals ...interface{}) error { return nil}
>
> Which is easy to override with any logger, is not tied to go-kit/log, but
> provides structured logging!
... or exposing some li
>
> Even better: my libraries expose only the LogFunc: i.e.
>
I am currently doing something similar; exposing an interface with four
methods Error, Info, Errorf, Infof with a default logger that uses the
built-in log, setup at init.
Yet IMHO there is a need for a built-in package that allows
Even better: my libraries expose only the LogFunc: i.e.
var Log = func(keyvals ...interface{}) error { return nil}
Which is easy to override with any logger, is not tied to go-kit/log, but
provides structured logging!
--
You received this message because you are subscribed to the Google Groups
Thanks for your thoughtful response. I agree with many of your points,
especially the benefits of structured logging, both on the usefulness of
the logs and the flow of the code as it builds the logging context. I have
a few comments on some of your points:
> Of these, I lean towards the zap st
On 8/15/17 7:14 AM, Chris Hines wrote:
I would be curious what you think of github.com/go-kit/kit/log (and
related "sub"-packages). See my talk about it's design here:
Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw
Slides: https://speakerdeck.com/chrishines/go-kit-log-package
I would be curious what you think of github.com/go-kit/kit/log (and related
"sub"-packages). See my talk about it's design here:
Video: https://youtu.be/ojhFQNgyZO4?list=FLcxNiie7-UD8znndwDn7PFw
Slides: https://speakerdeck.com/chrishines/go-kit-log-package
Chris
On Monday, August 14, 2017 at 2:
On 2017-08-14 18:36, dc0d wrote:
> Another question that I failed to answer properly (by myself) is: are
> metrics same as logs? Or they are a higher level concept (which also can
> be logged)? And should logging be in charge of delivering metrics (seems
> it can be)?
Depends... I guess.
I imple
The main problem with the Printf-style interface is that it's not worth
building real applications with. For anything with non-trivial logging
needs, you need:
* tagging of log lines with identifiers such as PID, host, request ID, etc
* structured for easier downstream analysis by tools like the
Some packages tried that approach, adding levels as prefixes (which I
prefer to defining methods). But did not get enough attention.
Whatever approach that may get chosen for a logging package, the logger
struct should implement some Logger interface and should accept an instance
of another obj
On 2017-08-14 11:04, dc0d wrote:
> That may be (still IMH-Experience in the majority of cases, this is the
> proper default to go).
>
> But the main concern to express here is, the default logger should
> accept an interface like /Output/ instead of /io.Writer/.
I would agree, if not for the fa
That may be (still IMH-Experience in the majority of cases, this is the
proper default to go).
But the main concern to express here is, the default logger should accept
an interface like *Output* instead of *io.Writer*. That way any necessary
mechanism can be added without touching the log pack
I'd consider it quite sensible to log an error *and* handle it (e.g. by
retrying). In that case, I wouldn't want it to appear with error-severity
in my log - it might be an error string, but it's not an error condition.
Only after bailing on handling an error should it stand out in an error
log. So
Many packages use the built-in log package. It could log data with help
from it's type. If we could set the output of the logger to something other
than *io.Writer*, like:
type Output interface {
Printf(format string, vset ...interface{})
Flags() (flag int)
Prefix() (prefix string)
24 matches
Mail list logo
