Logging packages for Go

Alexandre Cesaro

Last update: Sep 26, 2022

Related tags

Logging and Monitoring log

Overview

This repository contains logging packages for Go:

stdlog is the main package of this repository, it is a simple and fast logger to the standard output.
buflog and golog are customizable logging class which can be used as a standalone or as a building block for other loggers. stdlog is built upon them.
log just provides a common interface for logging libraries.

You are more than welcome to ask questions on the Go mailing-list and open issues here if you find bugs.

stdlog

Documentation

Package stdlog provides simple and fast logging to the standard output (stdout) and is optimized for programs launched via a shell or cron. It can also be used to log to a file by redirecting the standard output to a file. This package is thread-safe.

Basic examples:

logger := stdlog.GetFromFlags()
logger.Info("Connecting to the server...")
logger.Errorf("Connection failed: %q", err)

Will output:

2014-04-02 18:09:15.862 INFO Connecting to the API...
2014-04-02 18:10:14.347 ERROR Connection failed (Server is unavailable).

Log*() functions can be used to avoid evaluating arguments when it is expensive and unnecessary:

logger.Debug("Memory usage: %s", getMemoryUsage())
if LogDebug() { logger.Debug("Memory usage: %s", getMemoryUsage()) }

If debug logging is off the getMemoryUsage() will be executed on the first line while it will not be executed on the second line.

List of command-line arguments:

-log=info
    Log events at or above this level are logged.
-stderr=false
    Logs are written to standard error (stderr) instead of standard
    output.
-flushlog=none
    Until this level is reached nothing is output and logs are stored
    in the memory. Once a log event is at or above this level, it
    outputs all logs in memory as well as the future log events. This
    feature should not be used with long-running processes.

The available levels are the eight ones described in RFC 5424 (debug, info, notice, warning, error, critical, alert, emergency) and none.

Some use cases:

By default, all logs except debug ones are output to the stdout. Which is useful to follow the execution of a program launched via a shell.
A program launched by a crontab where the variable MAILTO is set with -debug -flushlog=error will send all logs generated by the program only if an error happens. When there is no error the email will not be sent.
my_program > /var/log/my_program/my_program-$(date+%Y-%m-%d-%H%M%S).log will create a log file in /var/log/my_program each time it is run.

buflog

Documentation

Package buflog provides a buffered logging class that accumulates logs in memory until the flush threshold is reached which release stored logs, the buffered logger then act as a normal logger.

Basic example:

logger := buflog.New(os.Stdout, log.Info, log.Error)
logger.Info("Connecting to the server...")   // Outputs nothing
logger.Error("Connection failed")            // Outputs both lines

golog

Documentation

Package golog provides a customizable logging class which can be used as a standalone or as a building block for other loggers.

Basic example:

logger := golog.New(os.Stdout, log.Info)
logger.Info("Connecting to the server...")
logger.Errorf("Connection failed: %q", err)

Will output:

2014-04-02 18:09:15.862 INFO Connecting to the API...
2014-04-02 18:10:14.347 ERROR Connection failed (Server is unavailable).

Log*() functions can be used to avoid evaluating arguments when it is expensive and unnecessary:

logger.Debug("Memory usage: %s", getMemoryUsage())
if logger.LogDebug() { logger.Debug("Memory usage: %s", getMemoryUsage()) }

If debug logging is off getMemoryUsage() will be executed on the first line while it will not be executed on the second line.

log

Documentation

Package log provides a common interface for logging libraries.

Comments

log: Add NullLogger instance, no-op impl of Logger.

Fixes #6.

Here's how it shows up on godoc: https://godoc.org/github.com/shazow/log

~~Think it's worth moving NullLogger to the top of log.go so that it's not buried at the bottom?~~

opened by shazow 4
proposal: Add log.NullLogger
I'd like to propose adding a NullLogger instance to the log package which implements a no-op version of log.Logger.

This is obviously a minor improvement, but I run into it often enough that I figure it's worth asking. :) I'd be happy to do a PR for this if you'd like.

Use case

In all of my subpackages, I like to use a package-global log.Logger instance, it typically looks like this:

package foo import ( "io/ioutil" "github.com/alexcesaro/log" "github.com/alexcesaro/log/golog" ) var logger log.Logger func SetLogger(l log.Logger) { logger = l } func init() { // Set a default null logger SetLogger(golog.New(ioutil.Discard, log.None)) }

Ideally, I'd like for this boilerplate file to be more like:

package foo import "github.com/alexcesaro/log" var logger log.Logger = log.NullLogger func SetLogger(l log.Logger) { logger = l }
opened by shazow 4

Data race condition warning

Hi there, this may be out of scope for your module but you may like to know that there is a race condition warning for when this module is used with goroutines.

Exhibited by this test case (in go v1.2.2):

package main

import (
    "os"

    "github.com/alexcesaro/log"
    "github.com/alexcesaro/log/golog"
)

var logger *golog.Logger

func main() {
    logger = golog.New(os.Stderr, log.Debug)
    done := make(chan struct{})

    logger.Info("Test.")

    go func() {
        logger.Info("Test.")
        done <- struct{}{}
    }()

    logger.Info("Test.")

    <-done
}

This yields warnings like this...

$ go run -race main.go
2014-05-20 15:43:44.294 INFO Test.
2014-05-20 15:43:44.298 INFO Test.
==================
WARNING: DATA RACE
Write by goroutine 3:
  runtime.copy()
      /usr/local/Cellar/go/1.2.2/libexec/src/pkg/runtime/slice.c:120 +0x0
  bytes.(*Buffer).Write()
      /usr/local/Cellar/go/1.2.2/libexec/src/pkg/bytes/buffer.go:128 +0x11d
  github.com/alexcesaro/log/golog.addTimestamp()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:252 +0x394
  github.com/alexcesaro/log/golog.func·001()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:225 +0x34
  github.com/alexcesaro/log/golog.(*Logger).output()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:215 +0xec
  github.com/alexcesaro/log/golog.(*Logger).Info()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:129 +0x57
  main.func·001()
      /Users/shazow/tmp/go/main.go:19 +0xf1

Previous read by main goroutine:
  syscall.raceReadRange()
      /usr/local/Cellar/go/1.2.2/libexec/src/pkg/syscall/race.go:25 +0x3f
  syscall.Write()
      /usr/local/Cellar/go/1.2.2/libexec/src/pkg/syscall/syscall_unix.go:153 +0xb9
  os.(*File).write()
      /usr/local/Cellar/go/1.2.2/libexec/src/pkg/os/file_unix.go:194 +0x9d
  os.(*File).Write()
      /usr/local/Cellar/go/1.2.2/libexec/src/pkg/os/file.go:139 +0xbb
  github.com/alexcesaro/log/golog.func·002()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:285 +0x58
  github.com/alexcesaro/log/golog.(*Logger).output()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:220 +0x236
  github.com/alexcesaro/log/golog.(*Logger).Info()
      /Users/shazow/local/go/src/github.com/alexcesaro/log/golog/golog.go:129 +0x57
  main.main()
      /Users/shazow/tmp/go/main.go:23 +0x3a5

Goroutine 3 (running) created at:
  main.main()
      /Users/shazow/tmp/go/main.go:21 +0x2dc

For comparison, using the stdlib "log" module works fine:

package main

import (
    "log"
    "os"
)

var logger *log.Logger

func main() {
    logger = log.New(os.Stderr, "", log.LstdFlags)
    done := make(chan struct{})

    logger.Print("Test.")

    go func() {
        logger.Print("Test.")
        done <- struct{}{}
    }()

    logger.Print("Test.")

    <-done
}

$ go run -race main.go
2014/05/20 15:47:27 Test.
2014/05/20 15:47:27 Test.
2014/05/20 15:47:27 Test.

By the way, thank you for building this otherwise-excellent logging module. :) It's exactly what I needed.

opened by shazow 4

Add SetLevel method to the logger interface

I use your package for logging in a command line program. At the beginning it was enough for me to set the log level via command line paramets and initialize the logger via stdlog.GetFromFlags() but now that my program has grown I want to use configuration files as well. Thats why I need to be able to set the level of a logger during program execution. I thought maybe you want to merge that change into your base repo as well, even though I am aware of that this might break some stuff since it adds a new method to the interface

opened by fgrosse 3
Issue/Feature request: setLoggingLevel

I am working on a command line application and am using stdlog. Currently, the only way I can see to set the log level is to use GetFromFlags(). Although this works, by default the logging level is set to "Info". What I would like to be able to do is define my own flag and pass the value of that flag to a function such as setLoggingLevel. This would allow me to have the set the default value for the flag as "none" (or I suppose any other non-info level) and have the logger function otherwise the same.

opened by quintessence 2
Please make a release

Making a proper release helps packaging your software by 3rd-party vendors like linux distros or BSDs.

It's super easy on github, please tag a release.

Many thanks, Alex

opened by alnsn 0