Structured, pluggable logging for Go.

Logrus :walrus: Build Status GoDoc

Logrus is a structured logger for Go (golang), completely API compatible with the standard library logger.

Logrus is in maintenance-mode. We will not be introducing new features. It's simply too hard to do in a way that won't break many people's projects, which is the last thing you want from your Logging library (again...).

This does not mean Logrus is dead. Logrus will continue to be maintained for security, (backwards compatible) bug fixes, and performance (where we are limited by the interface).

I believe Logrus' biggest contribution is to have played a part in today's widespread use of structured logging in Golang. There doesn't seem to be a reason to do a major, breaking iteration into Logrus V2, since the fantastic Go community has built those independently. Many fantastic alternatives have sprung up. Logrus would look like those, had it been re-designed with what we know about structured logging in Go today. Check out, for example, Zerolog, Zap, and Apex.

Seeing weird case-sensitive problems? It's in the past been possible to import Logrus as both upper- and lower-case. Due to the Go package environment, this caused issues in the community and we needed a standard. Some environments experienced problems with the upper-case variant, so the lower-case was decided. Everything using logrus will need to use the lower-case: github.com/sirupsen/logrus. Any package that isn't, should be changed.

To fix Glide, see these comments. For an in-depth explanation of the casing issue, see this comment.

Nicely color-coded in development (when a TTY is attached, otherwise just plain text):

Colored

With log.SetFormatter(&log.JSONFormatter{}), for easy parsing by logstash or Splunk:

{"animal":"walrus","level":"info","msg":"A group of walrus emerges from the
ocean","size":10,"time":"2014-03-10 19:57:38.562264131 -0400 EDT"}

{"level":"warning","msg":"The group's number increased tremendously!",
"number":122,"omg":true,"time":"2014-03-10 19:57:38.562471297 -0400 EDT"}

{"animal":"walrus","level":"info","msg":"A giant walrus appears!",
"size":10,"time":"2014-03-10 19:57:38.562500591 -0400 EDT"}

{"animal":"walrus","level":"info","msg":"Tremendously sized cow enters the ocean.",
"size":9,"time":"2014-03-10 19:57:38.562527896 -0400 EDT"}

{"level":"fatal","msg":"The ice breaks!","number":100,"omg":true,
"time":"2014-03-10 19:57:38.562543128 -0400 EDT"}

With the default log.SetFormatter(&log.TextFormatter{}) when a TTY is not attached, the output is compatible with the logfmt format:

time="2015-03-26T01:27:38-04:00" level=debug msg="Started observing beach" animal=walrus number=8
time="2015-03-26T01:27:38-04:00" level=info msg="A group of walrus emerges from the ocean" animal=walrus size=10
time="2015-03-26T01:27:38-04:00" level=warning msg="The group's number increased tremendously!" number=122 omg=true
time="2015-03-26T01:27:38-04:00" level=debug msg="Temperature changes" temperature=-4
time="2015-03-26T01:27:38-04:00" level=panic msg="It's over 9000!" animal=orca size=9009
time="2015-03-26T01:27:38-04:00" level=fatal msg="The ice breaks!" err=&{0x2082280c0 map[animal:orca size:9009] 2015-03-26 01:27:38.441574009 -0400 EDT panic It's over 9000!} number=100 omg=true

To ensure this behaviour even if a TTY is attached, set your formatter as follows:

	log.SetFormatter(&log.TextFormatter{
		DisableColors: true,
		FullTimestamp: true,
	})

Logging Method Name

If you wish to add the calling method as a field, instruct the logger via:

log.SetReportCaller(true)

This adds the caller as 'method' like so:

{"animal":"penguin","level":"fatal","method":"github.com/sirupsen/arcticcreatures.migrate","msg":"a penguin swims by",
"time":"2014-03-10 19:57:38.562543129 -0400 EDT"}
time="2015-03-26T01:27:38-04:00" level=fatal method=github.com/sirupsen/arcticcreatures.migrate msg="a penguin swims by" animal=penguin

Note that this does add measurable overhead - the cost will depend on the version of Go, but is between 20 and 40% in recent tests with 1.6 and 1.7. You can validate this in your environment via benchmarks:

go test -bench=.*CallerTracing

Case-sensitivity

The organization's name was changed to lower-case--and this will not be changed back. If you are getting import conflicts due to case sensitivity, please use the lower-case import: github.com/sirupsen/logrus.

Example

The simplest way to use Logrus is simply the package-level exported logger:

package main

import (
  log "github.com/sirupsen/logrus"
)

func main() {
  log.WithFields(log.Fields{
    "animal": "walrus",
  }).Info("A walrus appears")
}

Note that it's completely api-compatible with the stdlib logger, so you can replace your log imports everywhere with log "github.com/sirupsen/logrus" and you'll now have the flexibility of Logrus. You can customize it all you want:

package main

import (
  "os"
  log "github.com/sirupsen/logrus"
)

func init() {
  // Log as JSON instead of the default ASCII formatter.
  log.SetFormatter(&log.JSONFormatter{})

  // Output to stdout instead of the default stderr
  // Can be any io.Writer, see below for File example
  log.SetOutput(os.Stdout)

  // Only log the warning severity or above.
  log.SetLevel(log.WarnLevel)
}

func main() {
  log.WithFields(log.Fields{
    "animal": "walrus",
    "size":   10,
  }).Info("A group of walrus emerges from the ocean")

  log.WithFields(log.Fields{
    "omg":    true,
    "number": 122,
  }).Warn("The group's number increased tremendously!")

  log.WithFields(log.Fields{
    "omg":    true,
    "number": 100,
  }).Fatal("The ice breaks!")

  // A common pattern is to re-use fields between logging statements by re-using
  // the logrus.Entry returned from WithFields()
  contextLogger := log.WithFields(log.Fields{
    "common": "this is a common field",
    "other": "I also should be logged always",
  })

  contextLogger.Info("I'll be logged with common and other field")
  contextLogger.Info("Me too")
}

For more advanced usage such as logging to multiple locations from the same application, you can also create an instance of the logrus Logger:

package main

import (
  "os"
  "github.com/sirupsen/logrus"
)

// Create a new instance of the logger. You can have any number of instances.
var log = logrus.New()

func main() {
  // The API for setting attributes is a little different than the package level
  // exported logger. See Godoc.
  log.Out = os.Stdout

  // You could set this to any `io.Writer` such as a file
  // file, err := os.OpenFile("logrus.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)
  // if err == nil {
  //  log.Out = file
  // } else {
  //  log.Info("Failed to log to file, using default stderr")
  // }

  log.WithFields(logrus.Fields{
    "animal": "walrus",
    "size":   10,
  }).Info("A group of walrus emerges from the ocean")
}

Fields

Logrus encourages careful, structured logging through logging fields instead of long, unparseable error messages. For example, instead of: log.Fatalf("Failed to send event %s to topic %s with key %d"), you should log the much more discoverable:

log.WithFields(log.Fields{
  "event": event,
  "topic": topic,
  "key": key,
}).Fatal("Failed to send event")

We've found this API forces you to think about logging in a way that produces much more useful logging messages. We've been in countless situations where just a single added field to a log statement that was already there would've saved us hours. The WithFields call is optional.

In general, with Logrus using any of the printf-family functions should be seen as a hint you should add a field, however, you can still use the printf-family functions with Logrus.

Default Fields

Often it's helpful to have fields always attached to log statements in an application or parts of one. For example, you may want to always log the request_id and user_ip in the context of a request. Instead of writing log.WithFields(log.Fields{"request_id": request_id, "user_ip": user_ip}) on every line, you can create a logrus.Entry to pass around instead:

requestLogger := log.WithFields(log.Fields{"request_id": request_id, "user_ip": user_ip})
requestLogger.Info("something happened on that request") # will log request_id and user_ip
requestLogger.Warn("something not great happened")

Hooks

You can add hooks for logging levels. For example to send errors to an exception tracking service on Error, Fatal and Panic, info to StatsD or log to multiple places simultaneously, e.g. syslog.

Logrus comes with built-in hooks. Add those, or your custom hook, in init:

import (
  log "github.com/sirupsen/logrus"
  "gopkg.in/gemnasium/logrus-airbrake-hook.v2" // the package is named "airbrake"
  logrus_syslog "github.com/sirupsen/logrus/hooks/syslog"
  "log/syslog"
)

func init() {

  // Use the Airbrake hook to report errors that have Error severity or above to
  // an exception tracker. You can create custom hooks, see the Hooks section.
  log.AddHook(airbrake.NewHook(123, "xyz", "production"))

  hook, err := logrus_syslog.NewSyslogHook("udp", "localhost:514", syslog.LOG_INFO, "")
  if err != nil {
    log.Error("Unable to connect to local syslog daemon")
  } else {
    log.AddHook(hook)
  }
}

Note: Syslog hook also support connecting to local syslog (Ex. "/dev/log" or "/var/run/syslog" or "/var/run/log"). For the detail, please check the syslog hook README.

A list of currently known service hooks can be found in this wiki page

Level logging

Logrus has seven logging levels: Trace, Debug, Info, Warning, Error, Fatal and Panic.

log.Trace("Something very low level.")
log.Debug("Useful debugging information.")
log.Info("Something noteworthy happened!")
log.Warn("You should probably take a look at this.")
log.Error("Something failed but I'm not quitting.")
// Calls os.Exit(1) after logging
log.Fatal("Bye.")
// Calls panic() after logging
log.Panic("I'm bailing.")

You can set the logging level on a Logger, then it will only log entries with that severity or anything above it:

// Will log anything that is info or above (warn, error, fatal, panic). Default.
log.SetLevel(log.InfoLevel)

It may be useful to set log.Level = logrus.DebugLevel in a debug or verbose environment if your application has that.

Entries

Besides the fields added with WithField or WithFields some fields are automatically added to all logging events:

  1. time. The timestamp when the entry was created.
  2. msg. The logging message passed to {Info,Warn,Error,Fatal,Panic} after the AddFields call. E.g. Failed to send event.
  3. level. The logging level. E.g. info.

Environments

Logrus has no notion of environment.

If you wish for hooks and formatters to only be used in specific environments, you should handle that yourself. For example, if your application has a global variable Environment, which is a string representation of the environment you could do:

import (
  log "github.com/sirupsen/logrus"
)

init() {
  // do something here to set environment depending on an environment variable
  // or command-line flag
  if Environment == "production" {
    log.SetFormatter(&log.JSONFormatter{})
  } else {
    // The TextFormatter is default, you don't actually have to do this.
    log.SetFormatter(&log.TextFormatter{})
  }
}

This configuration is how logrus was intended to be used, but JSON in production is mostly only useful if you do log aggregation with tools like Splunk or Logstash.

Formatters

The built-in logging formatters are:

  • logrus.TextFormatter. Logs the event in colors if stdout is a tty, otherwise without colors.
    • Note: to force colored output when there is no TTY, set the ForceColors field to true. To force no colored output even if there is a TTY set the DisableColors field to true. For Windows, see github.com/mattn/go-colorable.
    • When colors are enabled, levels are truncated to 4 characters by default. To disable truncation set the DisableLevelTruncation field to true.
    • When outputting to a TTY, it's often helpful to visually scan down a column where all the levels are the same width. Setting the PadLevelText field to true enables this behavior, by adding padding to the level text.
    • All options are listed in the generated docs.
  • logrus.JSONFormatter. Logs fields as JSON.

Third party logging formatters:

You can define your formatter by implementing the Formatter interface, requiring a Format method. Format takes an *Entry. entry.Data is a Fields type (map[string]interface{}) with all your fields as well as the default ones (see Entries section above):

type MyJSONFormatter struct {
}

log.SetFormatter(new(MyJSONFormatter))

func (f *MyJSONFormatter) Format(entry *Entry) ([]byte, error) {
  // Note this doesn't include Time, Level and Message which are available on
  // the Entry. Consult `godoc` on information about those fields or read the
  // source of the official loggers.
  serialized, err := json.Marshal(entry.Data)
    if err != nil {
      return nil, fmt.Errorf("Failed to marshal fields to JSON, %w", err)
    }
  return append(serialized, '\n'), nil
}

Logger as an io.Writer

Logrus can be transformed into an io.Writer. That writer is the end of an io.Pipe and it is your responsibility to close it.

w := logger.Writer()
defer w.Close()

srv := http.Server{
    // create a stdlib log.Logger that writes to
    // logrus.Logger.
    ErrorLog: log.New(w, "", 0),
}

Each line written to that writer will be printed the usual way, using formatters and hooks. The level for those entries is info.

This means that we can override the standard library logger easily:

logger := logrus.New()
logger.Formatter = &logrus.JSONFormatter{}

// Use logrus for standard log output
// Note that `log` here references stdlib's log
// Not logrus imported under the name `log`.
log.SetOutput(logger.Writer())

Rotation

Log rotation is not provided with Logrus. Log rotation should be done by an external program (like logrotate(8)) that can compress and delete old log entries. It should not be a feature of the application-level logger.

Tools

Tool Description
Logrus Mate Logrus mate is a tool for Logrus to manage loggers, you can initial logger's level, hook and formatter by config file, the logger will be generated with different configs in different environments.
Logrus Viper Helper An Helper around Logrus to wrap with spf13/Viper to load configuration with fangs! And to simplify Logrus configuration use some behavior of Logrus Mate. sample

Testing

Logrus has a built in facility for asserting the presence of log messages. This is implemented through the test hook and provides:

  • decorators for existing logger (test.NewLocal and test.NewGlobal) which basically just adds the test hook
  • a test logger (test.NewNullLogger) that just records log messages (and does not output any):
import(
  "github.com/sirupsen/logrus"
  "github.com/sirupsen/logrus/hooks/test"
  "github.com/stretchr/testify/assert"
  "testing"
)

func TestSomething(t*testing.T){
  logger, hook := test.NewNullLogger()
  logger.Error("Helloerror")

  assert.Equal(t, 1, len(hook.Entries))
  assert.Equal(t, logrus.ErrorLevel, hook.LastEntry().Level)
  assert.Equal(t, "Helloerror", hook.LastEntry().Message)

  hook.Reset()
  assert.Nil(t, hook.LastEntry())
}

Fatal handlers

Logrus can register one or more functions that will be called when any fatal level message is logged. The registered handlers will be executed before logrus performs an os.Exit(1). This behavior may be helpful if callers need to gracefully shutdown. Unlike a panic("Something went wrong...") call which can be intercepted with a deferred recover a call to os.Exit(1) can not be intercepted.

...
handler := func() {
  // gracefully shutdown something...
}
logrus.RegisterExitHandler(handler)
...

Thread safety

By default, Logger is protected by a mutex for concurrent writes. The mutex is held when calling hooks and writing logs. If you are sure such locking is not needed, you can call logger.SetNoLock() to disable the locking.

Situation when locking is not needed includes:

  • You have no hooks registered, or hooks calling is already thread-safe.

  • Writing to logger.Out is already thread-safe, for example:

    1. logger.Out is protected by locks.

    2. logger.Out is an os.File handler opened with O_APPEND flag, and every write is smaller than 4k. (This allows multi-thread/multi-process writing)

      (Refer to http://www.notthewizard.com/2014/06/17/are-files-appends-really-atomic/)

Owner
Simon Eskildsen
Principal Engineer @Shopify
Simon Eskildsen
Comments
  • Log filename and line number

    Log filename and line number

    Both stdlib package log and many other logging frameworks are supporting this (e.g. https://github.com/inconshreveable/log15). Am I missing how to enable it or is it not supported?

  • Case change breaks builds?

    Case change breaks builds?

    Not sure what's started to happen, but overnight our builds have started to break:

    can't load package: package github.com/TykTechnologies/tyk: case-insensitive import collision: "github.com/Sirupsen/logrus" and "github.com/sirupsen/logrus"

    I wonder if it's the case change from S to s in the github username of the account. Even if we change the import path to use the lowercase version, dependencies that use the uppercase version that are not under our control seem to need updating too.

    Vendoring the lib doesn;t seem to work either, as the log.WithFields seems to self referential, but maybe I was too hasty in dismissing vendoring:

    ./api.go:124: cannot use "github.com/TykTechnologies/tyk/vendor/github.com/Sirupsen/logrus".Fields literal (type "github.com/TykTechnologies/tyk/vendor/github.com/Sirupsen/logrus".Fields) as type "github.com/Sirupsen/logrus".Fields in argument to log.WithFields

    Any tips appreciated.

  • [Maintenance] The Gofrs would like to adopt logrus

    [Maintenance] The Gofrs would like to adopt logrus

    Hi @sirupsen,

    A few of us over in the Go community have started a bit of a working group to share the work of maintaining projects that are extremely important to the Go ecosystem. It goes without saying, logrus is absolutely one of those.

    We've opened up a way for the community to suggest projects to adopt and logrus was one of them (https://github.com/gofrs/help-requests/issues/2).

    I wanted to reach out to see what your preference is for a team like The Gofrs taking over this project. Because this repo is on your personal GitHub account, and not an organization, it seems like we may be fairly limited in the type of shared responsibility we can take on. There are currently 20 members in the organization, so as a first step we could maybe add myself and a few others as collaborators so that we can share the load.

    Beyond that, in the interest of full transparency, we may need to consider migrating the project to an organization to allowed richer management of collaborators. That said we can cross that bridge when we get to it.

    Cheers! -Tim

  • Adding File, Line, Stacktrace

    Adding File, Line, Stacktrace

    This is just an initial approach to get the ball rolling in reference to #63 that I implemented last night really quickly. It needs test, hardening,etc. I am all for a much more permanent solution, but this is at least a start. The two things that need to be addressed are whether or not we are losing context by combining the file & line number like so:

    INFO[0006] Request completed                             file=/bursa/src/bursa.io/kernel/kernel.go:96
    

    and how to format the stack trace. Right now it is pretty gross:

    DEBU[0001]                                               file=/bursa/.godeps/src/github.com/Sirupsen/logrus/logger.go line=100 stack=goroutine 3 [running]:
    bursa.io/middleware/logtext.getTrace(0x756ec0, 0xc2100c8240)
        /bursa/src/bursa.io/middleware/logtext/logtext.go:46 +0x6e
    bursa.io/middleware/logtext.(*Logtext).Format(0xc2100915e0, 0xc2100928c0, 0x43029a, 0x7d9860, 0xc21001ea80, ...)
        /bursa/src/bursa.io/middleware/logtext/logtext.go:36 +0x181
    github.com/Sirupsen/logrus.(*Entry).Reader(0xc2100928c0, 0x376d4605, 0xc2100928c0, 0x0)
        /bursa/.godeps/src/github.com/Sirupsen/logrus/entry.go:41 +0x38
    github.com/Sirupsen/logrus.(*Entry).log(0xc2100928c0, 0x5, 0x0, 0x0)
        /bursa/.godeps/src/github.com/Sirupsen/logrus/entry.go:84 +0x1e9
    github.com/Sirupsen/logrus.(*Entry).Debug(0xc2100928c0, 0x7f64f0934a80, 0x1, 0x1)
        /bursa/.godeps/src/github.com/Sirupsen/logrus/entry.go:109 +0x75
    github.com/Sirupsen/logrus.(*Logger).Debug(0xc21004a180, 0x7f64f0934a80, 0x1, 0x1)
        /bursa/.godeps/src/github.com/Sirupsen/logrus/logger.go:100 +0xa3
    github.com/Sirupsen/logrus.Debug(0x7f64f0934a80, 0x1, 0x1)
        /bursa/.godeps/src/github.com/Sirupsen/logrus/exported.go:61 +0x48
    bursa.io/controller/home.HandleSignup(0x7f64f0ab9ce0, 0xc210092740, 0xc21005e750)
        /bursa/src/bursa.io/controller/home/home.go:36 +0x2f7
    net/http.HandlerFunc.ServeHTTP(0x902f78, 0x7f64f0ab9ce0, 0xc210092740, 0xc21005e750)
        /usr/local/go/src/pkg/net/http/server.go:1220 +0x40
    github.com/gorilla/mux.(*Router).ServeHTTP(0xc21005a4b0, 0x7f64f0ab9ce0, 0xc210092740, 0xc21005e750)
        /bursa/.godeps/src/github.com/gorilla/mux/mux.go:98 +0x21c
    github.com/codegangsta/negroni.func·001(0x7f64f0ab9ce0, 0xc210092740, 0xc21005e750, 0xc210091c40)
        /bursa/.godeps/src/github.com/codegangsta/negroni/negroni.go:41 +0x4c
    github.com/codegangsta/negroni.HandlerFunc.ServeHTTP(0xc210093e60, 0x7f64f0ab9ce0, 0xc210092740, 0xc21005e750, 0xc210091c40)
        /bursa/.godeps/src/github.com/codegangsta/negroni/negroni.go:24 +0x4a
    github.com/codegangsta/negroni.middleware.ServeHTTP(0x7f64f0ab8808, 0xc210093e60, 0xc210091a80, 0x7f64f0ab9ce0, 0xc210092740, ...)
        /bursa/.godeps/src/github.com/codegangsta/negroni/negroni.go:33 +0x82
    

    In this example you add this functionality by:

    log.SetFormatter(logtext.NewLogtext(new(log.TextFormatter), true))
    
  • case-insensitive import collision

    case-insensitive import collision

    Hi,

    My last build today I have this problem.

    can't load package: package github.com/sirupsen/logrus/examples/hook: case-insensitive import collision: "github.com/Sirupsen/logrus" and "github.com/sirupsen/logrus"

    can i help me ?

  • Should I use lowercase or uppercase for the package name?

    Should I use lowercase or uppercase for the package name?

    Hi,

    I am using two hooks, https://github.com/rogierlommers/logrus-redis-hook and https://github.com/bshuster-repo/logrus-logstash-hook, one is using upper case while the other one is using lowercase. Therefore I got this annoying error can't load package: package github.com/sirupsen/logrus/examples/hook: case-insensitive import collision: "github.com/Sirupsen/logrus" and "github.com/sirupsen/logrus"

    How can I solve this issue? As there is a thread mentioned that the change has been reverted, so should I use uppercase or lowercase package name?

    I am very confused!

    Thanks

  • New lines are escaped now

    New lines are escaped now

    Hi! With a recent update I've noticed that my debug data dumps in logs get fully escaped. Previously, I had nicely formatted data structs in output (using spew.Sdump), so I could actually read them.

    Code:

    • data is a complex data structure with arrays, pointers, many custom types, optional fields etc. log.Debug(spew.Sdump(data))

    And now I get: (*pkg.Data)(0xc423e8cb00)({\n UUID: (string) \"\",\n Property:...

    I've browsed through recent updates, but can't find a way to turn this off other then fixing version of logrus to some previous one. Please advise. The data dumps are unreadable now.

  • Need caller skip

    Need caller skip

    	if entry.Logger.ReportCaller {
    //  		entry.Caller = getCaller()
    		entry.Caller = getCaller(entry.Logger.CallerSkip)
    	}
    
    func getCaller(skip int) *runtime.Frame {
    ...
    		if pkg != logrusPackage {
    			if skip!=0 {
    				skip--
    				continue
    			}
    			return &f
    		}
    }
    

    I can skip custom deep.

  • Renaming upper-case 'Sirupsen' to 'sirupsen'

    Renaming upper-case 'Sirupsen' to 'sirupsen'

    The reason for this is that most other packages use lower-case naming conventions.

    The vendoring tool I use (GB) is case sensitive, and can become a massive pain in the :peach: when Logrus is the only package with an upper-case name (as most other packages are in lower case, following https://blog.golang.org/package-names) - this often leads to build failures.

    Why don't you just vendor it in lower case?

    Because Logrus has itself as an internal dependency, it vendors two folders, Sirupsen/logrus and sirupsen/logrus.

  • Provide Output method to Entry

    Provide Output method to Entry

    Standar log pakcage have the Output method for Logger http://golang.org/pkg/log/#Logger.Output Maybe Entry should have that method so it interface exactly with std Logger.

  • Configuration file support

    Configuration file support

    I'd like to have logging configuration files built-in logrus. The goal is to be able to configure logging without having to recompile.

    Action Items

    • Strike a balance between configurability and simplicity. The extreme configurablity case would probably be log4j's and seelog's. But we don't have to go that far. i.e. prefer yaml or json file formats instead of xml, and offer only a part of the above's options.
    • The options I would personally like are:
      • Control the outputs e.g. stdout, a single file, several files, etc.
      • Control each output's format e.g. json, logstash, plain text, etc.
      • Control which log levels are printed to each output
    • Have a default simple and sane configuration without having to do anything.
  • Provide a http.Handler, http.HandlerFunc to alter log level during runtime

    Provide a http.Handler, http.HandlerFunc to alter log level during runtime

    The user program can implement such logic independently, but a bundled one could be convenient. And share a common API.

    Then the user program can serve this handler like the pprof, promhttp.Handler do.

    If so, we could run with info or warning level in production, and turn to debug if something goes wrong. Something like:

    curl -XPOST 127.0.0.1:8080/logging -d '{"level":"debug"}'
    

    We can also do some more with Fields, turning log level to debug only if the log entry has specific fields.

  • Incorrect comment on `Log()` method on Logger and Entry

    Incorrect comment on `Log()` method on Logger and Entry

    Currently comment on these method states:

    // Warning: using Log at Panic or Fatal level will not respectively Panic nor Exit.
    // For this behaviour Entry.Panic or Entry.Fatal should be used instead.
    

    This is really a half truth. Panics are handled inside Entry.log() which should affect all calls to Panic or log, but only because the level can't be set lower than PanicLevel, so they can never be ignored. Fatal log messages are handled as this comment specifies, because Fatal logs messages can be ignored, the call to Logger.Exit() must be duplicated everywhere it is filtered out. (Recommend only filtering out Fatal and Panic messages only at point of dispatch to Hooks and point of write.)

  • Fix data race in hooks.test package

    Fix data race in hooks.test package

    Prior fix:

    go test -race -timeout 30s -run ^TestNewLocal$ github.com/sirupsen/logrus/hooks/test
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    ==================
    WARNING: DATA RACE
    Write at 0x00c00009f4d0 by goroutine 7:
      runtime.mapaccess2_fast32()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/runtime/map_fast32.go:53 +0x1cc
      github.com/sirupsen/logrus.LevelHooks.Add()
          /Users/wfrancoi/Downloads/logrus/hooks.go:20 +0x170
      github.com/sirupsen/logrus/hooks/test.NewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test.go:35 +0x38
      github.com/sirupsen/logrus/hooks/test.TestNewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:102 +0x3b8
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.(*T).Run.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x44
    
    Previous read at 0x00c00009f4d0 by goroutine 8:
      github.com/sirupsen/logrus.(*Entry).fireHooks()
          /Users/wfrancoi/Downloads/logrus/entry.go:274 +0x98
      github.com/sirupsen/logrus.(*Entry).log()
          /Users/wfrancoi/Downloads/logrus/entry.go:242 +0x624
      github.com/sirupsen/logrus.(*Entry).Log()
          /Users/wfrancoi/Downloads/logrus/entry.go:304 +0x84
    time="2022-12-22T10:57:57+01:00" level=info msg=info
      github.com/sirupsen/logrus.(*Logger).Log()
          /Users/wfrancoi/Downloads/logrus/logger.go:204 +0x70
      github.com/sirupsen/logrus.(*Logger).Info()
          /Users/wfrancoi/Downloads/logrus/logger.go:226 +0x64
      github.com/sirupsen/logrus/hooks/test.TestNewLocal.func1()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:97 +0x34
      github.com/sirupsen/logrus/hooks/test.TestNewLocal.func3()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:99 +0x48
    
    Goroutine 7 (running) created at:
      testing.(*T).Run()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x560
      testing.runTests.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1839 +0x94
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.runTests()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1837 +0x6c8
      testing.(*M).Run()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1719 +0x878
      main.main()
          _testmain.go:53 +0x2fc
    
    Goroutine 8 (running) created at:
      github.com/sirupsen/logrus/hooks/test.TestNewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:96 +0x2a0
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.(*T).Run.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x44
    ==================
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    ==================
    WARNING: DATA RACE
    Read at 0x00c0001340a0 by goroutine 13:
      github.com/sirupsen/logrus.(*Entry).fireHooks()
          /Users/wfrancoi/Downloads/logrus/entry.go:275 +0x170
      github.com/sirupsen/logrus.(*Entry).log()
          /Users/wfrancoi/Downloads/logrus/entry.go:242 +0x624
      github.com/sirupsen/logrus.(*Entry).Log()
          /Users/wfrancoi/Downloads/logrus/entry.go:304 +0x84
      github.com/sirupsen/logrus.(*Logger).Log()
          /Users/wfrancoi/Downloads/logrus/logger.go:204 +0x70
      github.com/sirupsen/logrus.(*Logger).Info()
          /Users/wfrancoi/Downloads/logrus/logger.go:226 +0x64
      github.com/sirupsen/logrus/hooks/test.TestNewLocal.func1()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:97 +0x34
      github.com/sirupsen/logrus/hooks/test.TestNewLocal.func3()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:99 +0x48
    
    Previous write at 0x00c0001340a0 by goroutine 7:
      github.com/sirupsen/logrus.LevelHooks.Add()
          /Users/wfrancoi/Downloads/logrus/hooks.go:20 +0x17c
      github.com/sirupsen/logrus/hooks/test.NewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test.go:35 +0x38
      github.com/sirupsen/logrus/hooks/test.TestNewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:102 +0x3b8
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.(*T).Run.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x44
    
    Goroutine 13 (running) created at:
      github.com/sirupsen/logrus/hooks/test.TestNewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:96 +0x2a0
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.(*T).Run.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x44
    
    Goroutine 7 (running) created at:
      testing.(*T).Run()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x560
      testing.runTests.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1839 +0x94
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.runTests()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1837 +0x6c8
      testing.(*M).Run()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1719 +0x878
      main.main()
          _testmain.go:53 +0x2fc
    ==================
    ==================
    WARNING: DATA RACE
    Read at 0x00c00009b0c0 by goroutine 13:
      github.com/sirupsen/logrus.LevelHooks.Fire()
          /Users/wfrancoi/Downloads/logrus/hooks.go:27 +0x9c
      github.com/sirupsen/logrus.(*Entry).fireHooks()
          /Users/wfrancoi/Downloads/logrus/entry.go:280 +0x238
      github.com/sirupsen/logrus.(*Entry).log()
          /Users/wfrancoi/Downloads/logrus/entry.go:242 +0x624
      github.com/sirupsen/logrus.(*Entry).Log()
          /Users/wfrancoi/Downloads/logrus/entry.go:304 +0x84
      github.com/sirupsen/logrus.(*Logger).Log()
          /Users/wfrancoi/Downloads/logrus/logger.go:204 +0x70
      github.com/sirupsen/logrus.(*Logger).Info()
          /Users/wfrancoi/Downloads/logrus/logger.go:226 +0x64
      github.com/sirupsen/logrus/hooks/test.TestNewLocal.func1()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:97 +0x34
      github.com/sirupsen/logrus/hooks/test.TestNewLocal.func3()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:99 +0x48
    
    Previous write at 0x00c00009b0c0 by goroutine 7:
      github.com/sirupsen/logrus.LevelHooks.Add()
          /Users/wfrancoi/Downloads/logrus/hooks.go:20 +0x110
      github.com/sirupsen/logrus/hooks/test.NewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test.go:35 +0x38
    time="2022-12-22T10:57:57+01:00" level=info msg=info
      github.com/sirupsen/logrus/hooks/test.TestNewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:102 +0x3b8
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.(*T).Run.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x44
    
    Goroutine 13 (running) created at:
      github.com/sirupsen/logrus/hooks/test.TestNewLocal()
          /Users/wfrancoi/Downloads/logrus/hooks/test/test_test.go:96 +0x2a0
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.(*T).Run.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x44
    
    Goroutine 7 (running) created at:
      testing.(*T).Run()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1486 +0x560
      testing.runTests.func1()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1839 +0x94
      testing.tRunner()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1439 +0x18c
      testing.runTests()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1837 +0x6c8
      testing.(*M).Run()
          /opt/homebrew/Cellar/go/1.18.4/libexec/src/testing/testing.go:1719 +0x878
      main.main()
          _testmain.go:53 +0x2fc
    ==================
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    time="2022-12-22T10:57:57+01:00" level=info msg=info
    --- FAIL: TestNewLocal (0.00s)
        testing.go:1312: race detected during execution of test
    FAIL
    FAIL    github.com/sirupsen/logrus/hooks/test   0.274s
    FAIL
    

    After fix:

    go test -race -timeout 30s -run ^TestNewLocal$ github.com/sirupsen/logrus/hooks/test
    ok      github.com/sirupsen/logrus/hooks/test   0.240s
    
  • entry.Log at Fatal does not exit

    entry.Log at Fatal does not exit

    As described in the README, log.Fatal calls os.Exit(1) and log.Panic calls panic(). However, using entry.Log calls panic() at Panic level, but does nothing other than emitting the entry at Fatal level.

    This is documented in the code here:

    // Warning: using Log at Panic or Fatal level will not respectively Panic nor Exit.
    // For this behaviour Entry.Panic or Entry.Fatal should be used instead.
    

    It's not clear whether the code documentation is correct or if the behavior of the code is correct. Either way, it should be consistent and possibly documented at a more visible level, such as in the README.

  • How do I use report correctly to get the correct method name when I wrap logrus?

    How do I use report correctly to get the correct method name when I wrap logrus?

    When I wrap logrus, I can't get the right call method.

    Like the following code a.go

    ...
      func Test(){
          b.Info(ctx,logMsg)
      }
    ...
    

    b.go

    ...
        type BusinessLog struct {
    	*logrus.Logger
        }
       var std = NewBusinessLog()
       func NewBusinessLog() *BusinessLog {
    	ln := logrus.New()
    	ln.SetReportCaller(true)
            ...
            return &BusinessLog{Logger: ln}
        }
        
        func Info(ctx context.Context, v interface{}){
             traceId:=trace.GetId(ctx)
             std.Logger.WithField("traceId", traceId).Info(v)  
        }
    ...
    

    expectation Method name Test in the file a.go

    practical Method name Info int the file b.go

    question How do I get the method name Test in file a.go?

    Thank you

Logrus is a structured, pluggable logging for Go.
Logrus is a structured, pluggable logging for Go.

Logrus is a structured logger for Go (golang), completely API compatible with the standard library logger.

May 25, 2021
Fully asynchronous, structured, pluggable logging for Go.

logr Logr is a fully asynchronous, contextual logger for Go. It is very much inspired by Logrus but addresses two issues: Logr is fully asynchronous,

Dec 28, 2022
Gomol is a library for structured, multiple-output logging for Go with extensible logging outputs

gomol Gomol (Go Multi-Output Logger) is an MIT-licensed structured logging library for Go. Gomol grew from a desire to have a structured logging libra

Sep 26, 2022
Structured logging package for Go.
Structured logging package for Go.

Package log implements a simple structured logging API inspired by Logrus, designed with centralization in mind. Read more on Medium. Handlers apexlog

Dec 24, 2022
Simple, configurable and scalable Structured Logging for Go.

log Log is a simple, highly configurable, Structured Logging library Why another logging library? There's allot of great stuff out there, but also tho

Sep 26, 2022
Structured, composable logging for Go
Structured, composable logging for Go

log15 Package log15 provides an opinionated, simple toolkit for best-practice logging in Go (golang) that is both human and machine readable. It is mo

Dec 18, 2022
Structured Logging Made Easy
Structured Logging Made Easy

Structured Logging Made Easy Features Dependency Free Simple and Clean Interface Consistent Writer IOWriter, io.Writer wrapper FileWriter, rotating &

Jan 3, 2023
Blazing fast, structured, leveled logging in Go.

⚡ zap Blazing fast, structured, leveled logging in Go. Installation go get -u go.uber.org/zap Note that zap only supports the two most recent minor ve

Jan 7, 2023
Hierarchical, leveled, and structured logging library for Go

spacelog Please see http://godoc.org/github.com/spacemonkeygo/spacelog for info License Copyright (C) 2014 Space Monkey, Inc. Licensed under the Apach

Apr 27, 2021
Minimal structured logging library for Go
Minimal structured logging library for Go

slog slog is a minimal structured logging library for Go. Install go get cdr.dev/slog Features Minimal API First class context.Context support First c

Dec 29, 2022
structured logging helper

Logart Logart is a structured logging tool that aims to simplify logging to a database It is not yet in stable state, but is used in production and ac

Apr 24, 2021
Go-metalog - Standard API for structured logging

Metalog is a standard API for structured logging and adapters for its implementa

Jan 20, 2022
A simple logging module for go, with a rotating file feature and console logging.

A simple logging module for go, with a rotating file feature and console logging. Installation go get github.com/jbrodriguez/mlog Usage Sample usage W

Dec 14, 2022
FactorLog is a logging infrastructure for Go that provides numerous logging functions for whatever your style may be
FactorLog is a logging infrastructure for Go that provides numerous logging functions for whatever your style may be

FactorLog FactorLog is a fast logging infrastructure for Go that provides numerous logging functions for whatever your style may be. It could easily b

Aug 3, 2022
Package logging implements a logging infrastructure for Go
Package logging implements a logging infrastructure for Go

Golang logging library Package logging implements a logging infrastructure for Go. Its output format is customizable and supports different logging ba

Nov 10, 2021
Structured log interface

Structured log interface Package log provides the separation of the logging interface from its implementation and decouples the logger backend from yo

Sep 26, 2022
A minimal and extensible structured logger

⚠️ PRE-RELEASE ⚠️ DO NOT IMPORT THIS MODULE YOUR PROJECT WILL BREAK package log package log provides a minimal interface for structured logging in ser

Jan 7, 2023
Search and analysis tooling for structured logs

Zed The Zed system provides an open-source, cloud-native, and searchable data lake for semi-structured and structured data. Zed lakes utilize a supers

Jan 5, 2023
Log-structured virtual disk in Ceph
Log-structured virtual disk in Ceph

lsd_ceph Log-structured virtual disk in Ceph 1. Vision and Goals of the Project Implement the basic librbd API to work with the research block device

Dec 13, 2021