go: github.com/uber-go/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.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/github.com/uber-go/zap#section-documentation
• Licenses: MIT
• Latest release: v1.27.0 (published 9 months ago)
• Last Synced: 2024-11-09T00:09:45.454Z (1 day ago)
• Versions: 38
• Dependent Packages: 25
• Dependent Repositories: 49
• Docker Downloads: 53
• Rankings:
  • Stargazers count: 0.452%
  • Forks count: 0.7%
  • Average: 0.725%
  • Dependent repos count: 0.823%
  • Dependent packages count: 0.924%

go: go.uber.org/zap/internal/exit

Package exit provides stubs so that unit tests can exercise code that calls os.Exit(1).

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/internal/exit#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T21:04:48.005Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Docker Downloads: 9
• Rankings:
  • Stargazers count: 0.071%
  • Forks count: 0.626%
  • Average: 3.353%
  • Dependent packages count: 6.151%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/zapcore

Package zapcore defines and implements the low-level interfaces upon which zap is built. By providing alternate implementations of these interfaces, external packages can extend zap's capabilities.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/zapcore#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T19:13:18.641Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Docker Downloads: 9
• Rankings:
  • Stargazers count: 0.071%
  • Forks count: 0.626%
  • Average: 3.353%
  • Dependent packages count: 6.151%
  • Dependent repos count: 6.563%

go: github.com/uber-go/zap/benchmarks

Package benchmarks contains only benchmarks comparing zap to other structured logging libraries.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/github.com/uber-go/zap/benchmarks#section-documentation
• Licenses: MIT
• Latest release: v1.11.0 (published almost 2 years ago)
• Last Synced: 2024-10-30T19:33:50.975Z (10 days ago)
• Versions: 17
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 0.386%
  • Forks count: 0.495%
  • Average: 4.306%
  • Dependent packages count: 6.999%
  • Dependent repos count: 9.346%

go: go.uber.org/zap/zapgrpc/internal/test

Package grpc tests Zap's zapgrpc package without requiring a dependency on grpc from Zap itself.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/zapgrpc/internal/test#section-documentation
• Licenses: MIT
• Latest release: v0.0.0-20231214234619-d27427d23f81 (published 11 months ago)
• Last Synced: 2024-10-30T19:33:52.874Z (10 days ago)
• Versions: 15
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 0.386%
  • Forks count: 0.495%
  • Average: 4.306%
  • Dependent packages count: 6.999%
  • Dependent repos count: 9.346%

go: github.com/Uber-go/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.

• Homepage: https://github.com/Uber-go/zap
• Documentation: https://pkg.go.dev/github.com/Uber-go/zap#section-documentation
• Licenses: MIT
• Latest release: v1.27.0 (published 9 months ago)
• Last Synced: 2024-11-09T00:09:44.896Z (1 day ago)
• Versions: 38
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 0.234%
  • Forks count: 0.661%
  • Average: 5.09%
  • Dependent packages count: 8.899%
  • Dependent repos count: 10.567%

go: github.com/uber-go/zap/exp

• Homepage:
• Documentation: https://pkg.go.dev/github.com/uber-go/zap/exp#section-documentation
• Licenses: mit
• Latest release: v0.2.0 (published about 1 year ago)
• Last Synced: 2024-11-09T00:09:49.438Z (1 day ago)
• Versions: 3
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 0.234%
  • Forks count: 0.661%
  • Average: 5.09%
  • Dependent packages count: 8.899%
  • Dependent repos count: 10.567%

go: go.uber.org/zap/buffer

Package buffer provides a thin wrapper around a byte slice. Unlike the standard library's bytes.Buffer, it supports a portion of the strconv package's zero-allocation formatters.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/buffer#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-11-09T00:09:48.686Z (1 day ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Docker Downloads: 9
• Rankings:
  • Dependent packages count: 6.151%
  • Average: 6.357%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/internal/pool

Package pool provides internal pool utilities.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/internal/pool#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T21:04:45.626Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 6.151%
  • Average: 6.357%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/internal/bufferpool

Package bufferpool houses zap's shared internal buffer pool. Third-party packages can recreate the same functionality with buffers.NewPool.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/internal/bufferpool#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T21:04:46.798Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Docker Downloads: 9
• Rankings:
  • Dependent packages count: 6.151%
  • Average: 6.357%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/internal/color

Package color adds coloring functionality for TTY output.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/internal/color#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T21:04:46.069Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Docker Downloads: 9
• Rankings:
  • Dependent packages count: 6.151%
  • Average: 6.357%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/internal

Package internal and its subpackages hold types and functionality that are not part of Zap's public API.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/internal#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T21:04:46.251Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 6.151%
  • Average: 6.357%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/internal/stacktrace

Package stacktrace provides support for gathering stack traces efficiently.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/internal/stacktrace#section-documentation
• Licenses: MIT
• Latest release:
• Last Synced: 2024-10-29T21:04:45.792Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 6.151%
  • Average: 6.357%
  • Dependent repos count: 6.563%

go: go.uber.org/zap/benchmarks

Package benchmarks contains only benchmarks comparing zap to other structured logging libraries.

• Homepage: https://github.com/uber-go/zap
• Documentation: https://pkg.go.dev/go.uber.org/zap/benchmarks#section-documentation
• Licenses: MIT
• Latest release: (published 6 months ago)
• Last Synced: 2024-10-29T21:04:47.762Z (11 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 6.999%
  • Average: 8.173%
  • Dependent repos count: 9.346%

go: github.com/uber-Go/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.

• Homepage: https://github.com/uber-Go/zap
• Documentation: https://pkg.go.dev/github.com/uber-Go/zap#section-documentation
• Licenses: MIT
• Latest release: v1.27.0 (published 9 months ago)
• Last Synced: 2024-11-09T00:09:59.778Z (1 day ago)
• Versions: 38
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 6.999%
  • Average: 8.173%
  • Dependent repos count: 9.346%