Blazing fast, structured, leveled logging in Go.

zap GoDoc Build Status Coverage Status

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 versions of Go.

Quick Start

In contexts where performance is nice, but not critical, use the SugaredLogger. It's 4-10x faster than other structured logging packages and includes both structured and printf-style APIs.

logger, _ := zap.NewProduction()
defer logger.Sync() // flushes buffer, if any
sugar := logger.Sugar()
sugar.Infow("failed to fetch URL",
  // Structured context as loosely typed key-value pairs.
  "url", url,
  "attempt", 3,
  "backoff", time.Second,
)
sugar.Infof("Failed to fetch URL: %s", url)

When performance and type safety are critical, use the Logger. It's even faster than the SugaredLogger and allocates far less, but it only supports structured logging.

logger, _ := zap.NewProduction()
defer logger.Sync()
logger.Info("failed to fetch URL",
  // Structured context as strongly typed Field values.
  zap.String("url", url),
  zap.Int("attempt", 3),
  zap.Duration("backoff", time.Second),
)

See the documentation and FAQ for more details.

Performance

For applications that log in the hot path, reflection-based serialization and string formatting are prohibitively expensive — they're CPU-intensive and make many small allocations. Put differently, using encoding/json and fmt.Fprintf to log tons of interface{}s makes your application slow.

Zap takes a different approach. It includes a reflection-free, zero-allocation JSON encoder, and the base Logger strives to avoid serialization overhead and allocations wherever possible. By building the high-level SugaredLogger on that foundation, zap lets users choose when they need to count every allocation and when they'd prefer a more familiar, loosely typed API.

As measured by its own benchmarking suite, not only is zap more performant than comparable structured logging packages — it's also faster than the standard library. Like all benchmarks, take these with a grain of salt.1

Log a message and 10 fields:

Package Time Time % to zap Objects Allocated
zap 862 ns/op +0% 5 allocs/op
zap (sugared) 1250 ns/op +45% 11 allocs/op
zerolog 4021 ns/op +366% 76 allocs/op
go-kit 4542 ns/op +427% 105 allocs/op
apex/log 26785 ns/op +3007% 115 allocs/op
logrus 29501 ns/op +3322% 125 allocs/op
log15 29906 ns/op +3369% 122 allocs/op

Log a message with a logger that already has 10 fields of context:

Package Time Time % to zap Objects Allocated
zap 126 ns/op +0% 0 allocs/op
zap (sugared) 187 ns/op +48% 2 allocs/op
zerolog 88 ns/op -30% 0 allocs/op
go-kit 5087 ns/op +3937% 103 allocs/op
log15 18548 ns/op +14621% 73 allocs/op
apex/log 26012 ns/op +20544% 104 allocs/op
logrus 27236 ns/op +21516% 113 allocs/op

Log a static string, without any context or printf-style templating:

Package Time Time % to zap Objects Allocated
zap 118 ns/op +0% 0 allocs/op
zap (sugared) 191 ns/op +62% 2 allocs/op
zerolog 93 ns/op -21% 0 allocs/op
go-kit 280 ns/op +137% 11 allocs/op
standard library 499 ns/op +323% 2 allocs/op
apex/log 1990 ns/op +1586% 10 allocs/op
logrus 3129 ns/op +2552% 24 allocs/op
log15 3887 ns/op +3194% 23 allocs/op

Development Status: Stable

All APIs are finalized, and no breaking changes will be made in the 1.x series of releases. Users of semver-aware dependency management systems should pin zap to ^1.

Contributing

We encourage and support an active, healthy community of contributors — including you! Details are in the contribution guide and the code of conduct. The zap maintainers keep an eye on issues and pull requests, but you can also report any negative conduct to [email protected]. That email list is a private, safe space; even the zap maintainers don't have access, so don't hesitate to hold us to a high standard.


Released under the MIT License.

1 In particular, keep in mind that we may be benchmarking against slightly older versions of other packages. Versions are pinned in the benchmarks/go.mod file.

Owner
Uber Go
Uber's open source software for Go development
Uber Go
Comments
  • Unable to install

    Unable to install

    I am getting error though installation:

    go get -u go.uber.org/zap    
    package go.uber.org/zap: unrecognized import path "go.uber.org/zap" (parse https://go.uber.org/zap?go-get=1: no go-import meta tags ())
    

    Seems you don't provide meta on go.uber.org/zap

  • Add buffering wrapper around WriteSyncer

    Add buffering wrapper around WriteSyncer

    Fixes #663

    This change adds Buffer, which wraps a WriteSyncer with buffering. This use bufio.Writer to buffer in-memory, and flush changes periodically (or when the buffer is full). The Sync method forces an immediate flush.

    This can improve performance by amortizing any fixed overheads of the underlying WriteSyncer.

    bechmark result

    Running tool: /usr/local/opt/go/libexec/bin/go test -benchmem -run=^$ go.uber.org/zap/zapcore -bench ^(BenchmarkMultiWriteSyncer|BenchmarkWriteSyncer)$
    
    goos: darwin
    goarch: amd64
    pkg: go.uber.org/zap/zapcore
    BenchmarkMultiWriteSyncer/2_discarder-4         	41213204	        66.5 ns/op	      16 B/op	       1 allocs/op
    BenchmarkMultiWriteSyncer/4_discarder-4         	19545279	        72.0 ns/op	      16 B/op	       1 allocs/op
    BenchmarkMultiWriteSyncer/4_discarder_with_buffer-4         	 8759560	       143 ns/op	      16 B/op	       1 allocs/op
    BenchmarkWriteSyncer/write_file_with_no_buffer-4            	  160742	      9367 ns/op	      16 B/op	       1 allocs/op
    BenchmarkWriteSyncer/write_file_with_buffer-4               	 7559112	       198 ns/op	      16 B/op	       1 allocs/op
    PASS
    ok  	go.uber.org/zap/zapcore	12.013s
    Success: Benchmarks passed.
    
  • write error: sync /dev/stdout: invalid argument

    write error: sync /dev/stdout: invalid argument

    Thanks for opensourcing this library!

    Everything is fine during program execution, but when the application shuts down (due to an error) zap logs to stderr: write error: sync /dev/stdout: invalid argument

    Output:

    2017-02-20T17:25:14.708+0100	info	starting
    2017-02-20T17:25:14.708+0100	info	publishing	{"port": 8080}
    2017-02-20T17:45:54.522+0100	fatal	Error publishing the API	{"error": "listen tcp :8080: bind: address already in use"}
    2017-02-20 17:25:14.708574765 +0100 CET write error: sync /dev/stdout: invalid argument
    exit status 1
    

    Relevant set-up code:

    config.FileLoggingEnabled = false
    config.EncodeLogsAsJson = false
    ...
    encCfg := zapcore.EncoderConfig{
    	TimeKey:        "@timestamp",
    	LevelKey:       "level",
    	NameKey:        "logger",
    	CallerKey:      "caller",
    	MessageKey:     "msg",
    	StacktraceKey:  "stacktrace",
    	EncodeLevel:    zapcore.LowercaseLevelEncoder,
    	EncodeTime:     zapcore.ISO8601TimeEncoder,
    	EncodeDuration: zapcore.NanosDurationEncoder,
    }
    ...
    func Configure() {
    	writers := []zapcore.WriteSyncer{os.Stdout}
    	if config.FileLoggingEnabled {
    		writers = append(writers, newRollingFile(....))
    	}
            GlobalLogger = newZapLogger(config.EncodeLogsAsJson, zapcore.NewMultiWriteSyncer(writers...))
    }
    
    func newZapLogger(encodeAsJSON bool, output zapcore.WriteSyncer) *zap.Logger {
    	encoder := zapcore.NewConsoleEncoder(encoderCfg)
    	if encodeAsJSON {
    		encoder = zapcore.NewJSONEncoder(encoderCfg)
    	}
    	return zap.New(zapcore.NewCore(encoder, output, zap.NewAtomicLevel()))
    }
    
  • Import path changed

    Import path changed

    package github.com/uber-go/zap imports go.uber.org/zap/internal/bufferpool: use of internal package not allowed package github.com/uber-go/zap imports go.uber.org/zap/internal/multierror: use of internal package not allowed

    seems github.com/zap has dependent in internal package in go.uber.org . Are you going to move this package to there?

  • Elegant way to filter fields?

    Elegant way to filter fields?

    Hi, I've been working with zap and it's great, but I have a question that I haven't been able to solve in a few days' time.

    How can I filter out certain fields? Preferably by name (and possibly type). For example, I want to mask IP addresses in fields called "remote_addr" or strip fields called "password".

    I've tried making an Encoder and wrapped EncodeEntry() and this works, but not for complex types like objects and arrays. In other words, if a log adds a field with zap.Object("http_request", req), EncodeEntry() has no way to peer inside the object and find offending fields and filter them ... does it?

    I've also tried implementing AddString() and AddObject() on my Encoder type but then the object loses its structure, and all its fields are flatted into the top level of the context.

    Any ideas how this can be done?

    It is important for regulatory/compliance reasons, apparently.

  • Don't panic when a given field value is nil

    Don't panic when a given field value is nil

    Ideally a logging framework doesn't cause a panic for code like this:

    foo, err := getFoo()
    
    if err != nil {
       log.Error("Couldn't acquire foo", zap.Error(err))
    }
    
    // foo could be nil here
    log = log.With(zap.Stringer("foo", foo))
    
    bar, err := getBar()
    
    if err != nil {
      // panics
      log.Error("Couldn't acquire bar", zap.Error(err))
    }
    

    This is probably also fixing #495 and #528

  • Add grpclog.LoggerV2 logger

    Add grpclog.LoggerV2 logger

    Fixed V() implementation based on https://github.com/uber-go/zap/pull/538.

    Official grpclog.LoggerV2 implementation sets verbose level at initialization. So I adopt functional option to set verbose level.

  • provide an easy way to derive a logger that logs at a different level

    provide an easy way to derive a logger that logs at a different level

    When logging HTTP requests, we've found it useful to be able to increase the logging threshold for some requests at particular paths (for example, the trivial endpoint that the Nagios check uses) to avoid overwhelming the logs with noise.

    It's possible to do this oneself with something like the below code, but this isn't particularly obvious and probably isn't that efficient, so perhaps it might be worth adding a WithLevel method to zap.Logger.

    // in the code
    logger = logger.WithOptions(wrapCoreWithLevel(zap.WarnLevel))
    
    func wrapCoreWithLevel(level zapcore.Level) zap.Option {
    	return zap.WrapCore(func(core zapcore.Core) zapcore.Core {
    		return &coreWithLevel{
    			Core:  core,
    			level: level,
    		}
    	})
    }
    
    type coreWithLevel struct {
    	zapcore.Core
    	level zapcore.Level
    }
    
    func (c *coreWithLevel) Enabled(level zapcore.Level) bool {
    	return c.level.Enabled(level) && c.Core.Enabled(level)
    }
    
    func (c *coreWithLevel) Check(e zapcore.Entry, ce *zapcore.CheckedEntry) *zapcore.CheckedEntry {
    	if !c.level.Enabled(e.Level) {
    		return ce
    	}
    	return c.Core.Check(e, ce)
    }
    
    
  • Implementing grpclog.LoggerV2 compatible logger

    Implementing grpclog.LoggerV2 compatible logger

    Currently, go.uber.org/zap/zapgrpc.Logger only provides an implementation for grpclog.Logger. With the release of grpclog.LoggerV2, an updated implementation is needed so that go.uber.org/zap/zapgrpc.Logger implements both grpclog.Logger and grpclog.LoggerV2.

    Fixes #534

  • Support for adding custom encoders

    Support for adding custom encoders

    I would like a way to add custom encoders using the config here. There is an Encoding option here that allows both console and json to be used.

    I had previously made a custom encoder from a previous development version of this library. While I haven't yet updated that library to work with the current release candidate, a hook that would allow me to add something like this into the library would be nice.

    func NewLogfmtEncoder(cfg zapcore.EncoderConfig) zapcore.Encoder
            // instantiate the logfmt encoder here
    }
    
    func init() {
            zap.RegisterEncoder("logfmt", NewLogfmtEncoder)
    }
    

    It doesn't need to be very complicated. It can just be a map protected by a global read/write mutex (or not even that since loggers should be registered in init() functions) that panics whenever there is a duplicate. I'm thinking something similar to how database/sql allows additional database handlers.

  • Skip runtime and some zap frames in stacktraces

    Skip runtime and some zap frames in stacktraces

    Remove runtime.goexit, runtime.main, and some zap frames from our stacktraces. Since we're now formatting our own traces, we also get a big performance win: nearly 5x faster and half the number of bytes allocated!

    Current master:

    BenchmarkStackField-4             200000              9587 ns/op             960 B/op          2 allocs/op
    

    After this PR:

    BenchmarkStackField-4             500000              2149 ns/op             448 B/op          2 allocs/op
    

    Fixes #308.

  • Noticeable slowdown when using Sugar on a no-op logger

    Noticeable slowdown when using Sugar on a no-op logger

    Describe the bug When using the logger normally, my application runs at full speed.

    plainLogger, _ := zap.NewDevelopment()
    app := NewApp(plainLogger.Sugar())
    

    To Reproduce When I change plainLogger into a no-op logger and pass the sugar logger, my entire application slows down.

    plainLogger := zap.NewNop()
    app := NewApp(plainLogger.Sugar())
    

    Expected behavior I expect the same if not a higher performance when I switch to a no-op logger.

  • Incorrect caller when logs originate from modules with a major version suffix

    Incorrect caller when logs originate from modules with a major version suffix

    When using the logger in a Go module with a major version suffix, the package name is omitted, leaving only the version. In this case [email protected]. I would expect this to be go-pkg/[email protected]. go.mod:

    module github.com/me/go-pkg/v2
    
    go 1.19
    
    require go.uber.org/zap v1.24.0
    

    log.go:

    package pkg
    
    import (
    	"go.uber.org/zap"
    )
    
    func LogSomething() {
    	logger, _ := zap.NewProduction(zap.AddCaller())
    	logger.Info("logging from library")
    }
    

    Using the above library in another Go project:

    package main
    
    import "github.com/me/go-pkg/v2"
    
    func main() {
    	pkg.LogSomething()
    }
    

    Results in the following log:

    {"level":"info","ts":1669917064.3370209,"caller":"[email protected]/pkg.go:9","msg":"logging from library"}
    
  • chore: update bench package versions and results

    chore: update bench package versions and results

    The results for the benchmarks in the README haven't been updated in a while, and the package versions are very outdated.

    • Updated the package versions from remote log packages in benchmarks/go.mod
    • Updated benchmarks/go.mod go version to 1.19 (to match zap)
    • Re-ran the benchmarks with go 1.19.2 on an AWS EC2 m5.8xlarge so other people could match their results using similar, easily gettable hardware
    • Updated the README to have the new benchmark results and the machine type
    Raw go test output
    $ go test -bench=kAddingFields -benchtime=10s -benchmem ./...
    goos: linux
    goarch: amd64
    pkg: go.uber.org/zap/benchmarks
    cpu: Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
    BenchmarkAddingFields/Zap-32            15010263               829.5 ns/op           757 B/op          5 allocs/op
    BenchmarkAddingFields/Zap.Check-32      14441172               831.5 ns/op           755 B/op          5 allocs/op
    BenchmarkAddingFields/Zap.CheckSampled-32               100000000              109.1 ns/op            82 B/op          0 allocs/op
    BenchmarkAddingFields/Zap.Sugar-32                       8829618              1377 ns/op            1527 B/op         10 allocs/op
    BenchmarkAddingFields/apex/log-32                         404503             29235 ns/op            4206 B/op         63 allocs/op
    BenchmarkAddingFields/go-kit/kit/log-32                  2787565              4311 ns/op            3370 B/op         57 allocs/op
    BenchmarkAddingFields/inconshreveable/log15-32            386395             31085 ns/op            6440 B/op         74 allocs/op
    BenchmarkAddingFields/sirupsen/logrus-32                  386708             31084 ns/op            6311 B/op         79 allocs/op
    BenchmarkAddingFields/rs/zerolog-32                     30917904               388.9 ns/op            24 B/op          1 allocs/op
    BenchmarkAddingFields/rs/zerolog.Check-32               30727593               389.9 ns/op            24 B/op          1 allocs/op
    PASS
    ok      go.uber.org/zap/benchmarks      128.665s
    
    
    
    
    $ go test -bench=kAccumulatedContext -benchtime=10s -benchmem ./...
    goos: linux
    goarch: amd64
    pkg: go.uber.org/zap/benchmarks
    cpu: Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
    BenchmarkAccumulatedContext/Zap-32              277930179               44.20 ns/op            0 B/op          0 allocs/op
    BenchmarkAccumulatedContext/Zap.Check-32        301587030               41.71 ns/op            0 B/op          0 allocs/op
    BenchmarkAccumulatedContext/Zap.CheckSampled-32                 765221544               14.33 ns/op            0 B/op          0 allocs/op
    BenchmarkAccumulatedContext/Zap.Sugar-32                        169768088               74.04 ns/op           16 B/op          1 allocs/op
    BenchmarkAccumulatedContext/Zap.SugarFormatting-32               4666222              2602 ns/op            2027 B/op         58 allocs/op
    BenchmarkAccumulatedContext/apex/log-32                           422432             28775 ns/op            3315 B/op         53 allocs/op
    BenchmarkAccumulatedContext/go-kit/kit/log-32                    2355148              5072 ns/op            3753 B/op         56 allocs/op
    BenchmarkAccumulatedContext/inconshreveable/log15-32              504453             22634 ns/op            3302 B/op         70 allocs/op
    BenchmarkAccumulatedContext/sirupsen/logrus-32                    404581             29047 ns/op            4762 B/op         68 allocs/op
    BenchmarkAccumulatedContext/rs/zerolog-32                       363663616               31.80 ns/op            0 B/op          0 allocs/op
    BenchmarkAccumulatedContext/rs/zerolog.Check-32                 378858796               31.65 ns/op            0 B/op          0 allocs/op
    BenchmarkAccumulatedContext/rs/zerolog.Formatting-32             5019376              2349 ns/op            1929 B/op         58 allocs/op
    PASS
    ok      go.uber.org/zap/benchmarks      177.842s
    
    
    
    
    $ go test -bench=kWithoutFields -benchtime=10s -benchmem ./...
    goos: linux
    goarch: amd64
    pkg: go.uber.org/zap/benchmarks
    cpu: Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
    BenchmarkWithoutFields/Zap-32           291229839               42.45 ns/op            0 B/op          0 allocs/op
    BenchmarkWithoutFields/Zap.Check-32     301553593               40.80 ns/op            0 B/op          0 allocs/op
    BenchmarkWithoutFields/Zap.CheckSampled-32              804538417               13.78 ns/op            0 B/op          0 allocs/op
    BenchmarkWithoutFields/Zap.Sugar-32                     176594287               67.44 ns/op           16 B/op          1 allocs/op
    BenchmarkWithoutFields/Zap.SugarFormatting-32            4735507              2548 ns/op            1980 B/op         58 allocs/op
    BenchmarkWithoutFields/apex/log-32                       6344678              1892 ns/op             353 B/op          6 allocs/op
    BenchmarkWithoutFields/go-kit/kit/log-32                34029396               353.6 ns/op           522 B/op          9 allocs/op
    BenchmarkWithoutFields/inconshreveable/log15-32          2549732              4744 ns/op            1438 B/op         20 allocs/op
    BenchmarkWithoutFields/sirupsen/logrus-32                3486418              3451 ns/op            1137 B/op         23 allocs/op
    BenchmarkWithoutFields/stdlib.Println-32                1000000000               9.997 ns/op          16 B/op          1 allocs/op
    BenchmarkWithoutFields/stdlib.Printf-32                 154259305               77.85 ns/op          136 B/op          6 allocs/op
    BenchmarkWithoutFields/rs/zerolog-32                    392868822               30.95 ns/op            0 B/op          0 allocs/op
    BenchmarkWithoutFields/rs/zerolog.Formatting-32          5130219              2324 ns/op            1928 B/op         58 allocs/op
    BenchmarkWithoutFields/rs/zerolog.Check-32              390577189               30.74 ns/op            0 B/op          0 allocs/op
    PASS
    ok      go.uber.org/zap/benchmarks      213.078s
    
  • Return logger name

    Return logger name

    Is your feature request related to a problem? Please describe. I am writing an application that overall should have a user specified log level, ie INFO. But they can overwrite the log level for certain "actions" that would be handled on a case by case basis. Since we are unable to change the log level of a cloned logger, I am instantiating a new logger set to the DEBUG level. Currently, this new logger does not have the inherited name for the existing logger. I would like a function such as zapLog.GetName() that would return a string of the current log name that I can then pass on to the new logger.

    Is this a breaking change? I do not believe this would be a breaking change as it would add a function to the current interface.

  • support timeout for write

    support timeout for write

    Is your feature request related to a problem? Please describe. The file that the logger is writing is over a network. Writing a log should not be blocked forever if the network is down.

    Describe the solution you'd like A clear and concise description of what you want to happen. Support a config item write timeout, we can use SetWriteDeadline() provided by golang for the opened filed. If the deadline is reached, the log operation should be returned instead of blocked.

    Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

    Is this a breaking change? We do not accept breaking changes to the existing API. Please consider if your proposed solution is backwards compatible. If not, we can help you make it backwards compatible, but this must be considered when we consider new features.

    Additional context Add any other context or screenshots about the feature request here. https://github.com/pingcap/tidb/issues/35007

  • Does zap have its own log rolling implementation?

    Does zap have its own log rolling implementation?

    Does zap have its own log rolling implementation? Third party libraries will cause zap stable code panic. https://github.com/natefinch/lumberjack/issues/2

Tiny structured logging abstraction or facade for various logging libraries, allowing the end user to plug in the desired logging library in main.go
Tiny structured logging abstraction or facade for various logging libraries, allowing the end user to plug in the desired logging library in main.go

Tiny structured logging abstraction or facade for various logging libraries, allowing the end user to plug in the desired logging library in main.go.

Dec 7, 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
Simple and blazing fast lockfree logging library for golang
Simple and blazing fast lockfree logging library for golang

glg is simple golang logging library Requirement Go 1.11 Installation go get github.com/kpango/glg Example package main import ( "net/http" "time"

Nov 28, 2022
Simple, customizable, leveled and efficient logging in Go

log Simple, customizable, leveled and efficient logging in Go Installation go get -u github.com/ermanimer/log Features log is a simple logging package

Dec 20, 2021
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, pluggable logging for Go.
Structured, pluggable logging for Go.

Logrus Logrus is a structured logger for Go (golang), completely API compatible with the standard library logger. Logrus is in maintenance-mode. We wi

Jan 9, 2023
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
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
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
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
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
Blazing fast syslog parser

A parser for Syslog messages and transports. Blazing fast Syslog parsers By @leodido. To wrap up, this package provides: a RFC5424-compliant parser an

Dec 29, 2022
Golog is a logger which support tracing and other custom behaviors out of the box. Blazing fast and simple to use.

GOLOG Golog is an opinionated Go logger with simple APIs and configurable behavior. Why another logger? Golog is designed to address mainly two issues

Oct 2, 2022
Leveled execution logs for Go

glog ==== Leveled execution logs for Go. This is an efficient pure Go implementation of leveled logs in the manner of the open source C++ package h

Dec 24, 2022
CoLog is a prefix-based leveled execution log for Go
CoLog is a prefix-based leveled execution log for Go

What's CoLog? CoLog is a prefix-based leveled execution log for Go. It's heavily inspired by Logrus and aims to offer similar features by parsing the

Dec 14, 2022
Leveled execution logs for Go.

glog Leveled execution logs for Go. This is an efficient pure Go implementation of leveled logs in the manner of the open source C++ package glog. By

Nov 29, 2021