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:15:17 PM UTC-4, Sam Vilain wrote: > > 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 ELK stack > and common commercial systems like splunk > > What I've had to do to achieve this is to pass an alternate writer to the > "standard log" interface expected by various libraries (eg, Sarama) and add > PID and host tagging to that. Writing things in terms of "prefix" > represents a very limited view of log correlation; it worked for syslog > perhaps but the world has moved on. Log levels are also mostly useless. > > The right API to me is probably somewhere between logrus and Uber's zap. > These systems are in more widespread use with a different set of > priorities, and it would be good to be able to plug into those (and see > also my context suggestion which could let these libraries automatically > connect with a configured logger) > > Sam > > > On Mon, Aug 14, 2017 at 9:36 AM, dc0d <kaveh.sh...@gmail.com <javascript:> > > wrote: > >> 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 object which also implements the Logger interface. >> >> This way it will be possible to not only handle the log entries at lower >> layers but also to have a hierarchy of loggers to the top (where logging is >> happening) which can behave differently based on the (conceptual) context - >> choosing the formatters, the destinations or notifying another system. >> >> And levels could be expanded to tags. A tagged entry can be processed >> based on its tags (including a concept like level) - but it seems (sadly) >> that levels are more wide-spread than just being a tag. >> >> That sort of interface, is what I would like to see. And you are right >> about that there is no conclusive agreement on what it should like. >> >> 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)? >> >> >> On Monday, August 14, 2017 at 6:30:19 PM UTC+4:30, Peter Mogensen wrote: >>> >>> >>> >>> 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 fact that there seem to be very little >>> consensus on exactly what such an interface should look like. >>> >>> systemd support a very simple (but useful) interface for leveled >>> logging. Just prefix what you write to stdout or stderr with "<X>" where >>> X is the syslog log-level. Systemd takes care of anything else. >>> Exactly this is pretty much impossible to do efficiently with many >>> log-packages, including the stdlib "log". >>> >>> /Peter >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
