zap
go.uber.org/zap
go get go.uber.org/zap
zap

go.uber.org/zap

Package zap provides fast, structured, leveled logging. 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 json.Marshal and fmt.Fprintf to log tons of interface{} 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. In contexts where performance is nice, but not critical, use the SugaredLogger. It's 4-10x faster than other structured logging packages and supports both structured and printf-style logging. Like log15 and go-kit, the SugaredLogger's structured logging APIs are loosely typed and accept a variadic number of key-value pairs. (For more advanced use cases, they also accept strongly typed fields - see the SugaredLogger.With documentation for details.) By default, loggers are unbuffered. However, since zap's low-level APIs allow buffering, calling Sync before letting your process exit is a good habit. In the rare contexts where every microsecond and every allocation matter, use the Logger. It's even faster than the SugaredLogger and allocates far less, but it only supports strongly-typed, structured logging. Choosing between the Logger and SugaredLogger doesn't need to be an application-wide decision: converting between the two is simple and inexpensive. The simplest way to build a Logger is to use zap's opinionated presets: NewExample, NewProduction, and NewDevelopment. These presets build a logger with a single function call: Presets are fine for small projects, but larger projects and organizations naturally require a bit more customization. For most users, zap's Config struct strikes the right balance between flexibility and convenience. See the package-level BasicConfiguration example for sample code. More unusual configurations (splitting output between files, sending logs to a message queue, etc.) are possible, but require direct use of go.uber.org/zap/zapcore. See the package-level AdvancedConfiguration example for sample code. The zap package itself is a relatively thin wrapper around the interfaces in go.uber.org/zap/zapcore. Extending zap to support a new encoding (e.g., BSON), a new log sink (e.g., Kafka), or something more exotic (perhaps an exception aggregation service, like Sentry or Rollbar) typically requires implementing the zapcore.Encoder, zapcore.WriteSyncer, or zapcore.Core interfaces. See the zapcore documentation for details. Similarly, package authors can use the high-performance Encoder and Core implementations in the zapcore package to build their own loggers. An FAQ covering everything from installation errors to design decisions is available at https://github.com/uber-go/zap/blob/master/FAQ.md.

by unknownv1.21.0 (see all)License:MIT
go get go.uber.org/zap
Readme

⚡ 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

2900 ns/op

+0%

5 allocs/op

⚡ zap (sugared)

3475 ns/op

+20%

10 allocs/op

zerolog

10639 ns/op

+267%

32 allocs/op

go-kit

14434 ns/op

+398%

59 allocs/op

logrus

17104 ns/op

+490%

81 allocs/op

apex/log

32424 ns/op

+1018%

66 allocs/op

log15

33579 ns/op

+1058%

76 allocs/op

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

Package

Time

Time % to zap

Objects Allocated

⚡ zap

373 ns/op

+0%

0 allocs/op

⚡ zap (sugared)

452 ns/op

+21%

1 allocs/op

zerolog

288 ns/op

-23%

0 allocs/op

go-kit

11785 ns/op

+3060%

58 allocs/op

logrus

19629 ns/op

+5162%

70 allocs/op

log15

21866 ns/op

+5762%

72 allocs/op

apex/log

30890 ns/op

+8182%

55 allocs/op

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

Package

Time

Time % to zap

Objects Allocated

⚡ zap

381 ns/op

+0%

0 allocs/op

⚡ zap (sugared)

410 ns/op

+8%

1 allocs/op

zerolog

369 ns/op

-3%

0 allocs/op

standard library

385 ns/op

+1%

2 allocs/op

go-kit

606 ns/op

+59%

11 allocs/op

logrus

1730 ns/op

+354%

25 allocs/op

apex/log

1998 ns/op

+424%

7 allocs/op

log15

4546 ns/op

+1093%

22 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 oss-conduct@uber.com. 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.

GitHub Stars

0
No data available

LAST COMMIT

NaNyrs ago

MAINTAINERS

0

CONTRIBUTORS

0

OPEN ISSUES

0

OPEN PRs

0
No data available
VersionTagPublished
v1.21.1-0.20220315213927-32a858eb8445
6mos ago
v0.0.0-20170512211322-fab453050a7a
7mos ago
v1.21.0
8mos ago
v1.20.1-0.20220204161416-a7613b2969c3
8mos ago
No alternatives found
No tutorials found
Add a tutorial

Rate & Review

100
No reviews found
Be the first to rate