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.shahbaz...@gmail.com> 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+unsubscr...@googlegroups.com. > 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.
