1
// Copyright (c) 2016 Uber Technologies, Inc.
2
//
3
// Permission is hereby granted, free of charge, to any person obtaining a copy
4
// of this software and associated documentation files (the "Software"), to deal
5
// in the Software without restriction, including without limitation the rights
6
// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
7
// copies of the Software, and to permit persons to whom the Software is
8
// furnished to do so, subject to the following conditions:
9
//
10
// The above copyright notice and this permission notice shall be included in
11
// all copies or substantial portions of the Software.
12
//
13
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
14
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
15
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
16
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
17
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
18
// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
19
// THE SOFTWARE.
20

21
// Package zap provides fast, structured, leveled logging.
22
//
23
// For applications that log in the hot path, reflection-based serialization
24
// and string formatting are prohibitively expensive - they're CPU-intensive
25
// and make many small allocations. Put differently, using json.Marshal and
26
// fmt.Fprintf to log tons of interface{} makes your application slow.
27
//
28
// Zap takes a different approach. It includes a reflection-free,
29
// zero-allocation JSON encoder, and the base Logger strives to avoid
30
// serialization overhead and allocations wherever possible. By building the
31
// high-level SugaredLogger on that foundation, zap lets users choose when
32
// they need to count every allocation and when they'd prefer a more familiar,
33
// loosely typed API.
34
//
35
// # Choosing a Logger
36
//
37
// In contexts where performance is nice, but not critical, use the
38
// SugaredLogger. It's 4-10x faster than other structured logging packages and
39
// supports both structured and printf-style logging. Like log15 and go-kit,
40
// the SugaredLogger's structured logging APIs are loosely typed and accept a
41
// variadic number of key-value pairs. (For more advanced use cases, they also
42
// accept strongly typed fields - see the SugaredLogger.With documentation for
43
// details.)
44
//
45
//	sugar := zap.NewExample().Sugar()
46
//	defer sugar.Sync()
47
//	sugar.Infow("failed to fetch URL",
48
//	  "url", "http://example.com",
49
//	  "attempt", 3,
50
//	  "backoff", time.Second,
51
//	)
52
//	sugar.Infof("failed to fetch URL: %s", "http://example.com")
53
//
54
// By default, loggers are unbuffered. However, since zap's low-level APIs
55
// allow buffering, calling Sync before letting your process exit is a good
56
// habit.
57
//
58
// In the rare contexts where every microsecond and every allocation matter,
59
// use the Logger. It's even faster than the SugaredLogger and allocates far
60
// less, but it only supports strongly-typed, structured logging.
61
//
62
//	logger := zap.NewExample()
63
//	defer logger.Sync()
64
//	logger.Info("failed to fetch URL",
65
//	  zap.String("url", "http://example.com"),
66
//	  zap.Int("attempt", 3),
67
//	  zap.Duration("backoff", time.Second),
68
//	)
69
//
70
// Choosing between the Logger and SugaredLogger doesn't need to be an
71
// application-wide decision: converting between the two is simple and
72
// inexpensive.
73
//
74
//	logger := zap.NewExample()
75
//	defer logger.Sync()
76
//	sugar := logger.Sugar()
77
//	plain := sugar.Desugar()
78
//
79
// # Configuring Zap
80
//
81
// The simplest way to build a Logger is to use zap's opinionated presets:
82
// NewExample, NewProduction, and NewDevelopment. These presets build a logger
83
// with a single function call:
84
//
85
//	logger, err := zap.NewProduction()
86
//	if err != nil {
87
//	  log.Fatalf("can't initialize zap logger: %v", err)
88
//	}
89
//	defer logger.Sync()
90
//
91
// Presets are fine for small projects, but larger projects and organizations
92
// naturally require a bit more customization. For most users, zap's Config
93
// struct strikes the right balance between flexibility and convenience. See
94
// the package-level BasicConfiguration example for sample code.
95
//
96
// More unusual configurations (splitting output between files, sending logs
97
// to a message queue, etc.) are possible, but require direct use of
98
// go.uber.org/zap/zapcore. See the package-level AdvancedConfiguration
99
// example for sample code.
100
//
101
// # Extending Zap
102
//
103
// The zap package itself is a relatively thin wrapper around the interfaces
104
// in go.uber.org/zap/zapcore. Extending zap to support a new encoding (e.g.,
105
// BSON), a new log sink (e.g., Kafka), or something more exotic (perhaps an
106
// exception aggregation service, like Sentry or Rollbar) typically requires
107
// implementing the zapcore.Encoder, zapcore.WriteSyncer, or zapcore.Core
108
// interfaces. See the zapcore documentation for details.
109
//
110
// Similarly, package authors can use the high-performance Encoder and Core
111
// implementations in the zapcore package to build their own loggers.
112
//
113
// # Frequently Asked Questions
114
//
115
// An FAQ covering everything from installation errors to design decisions is
116
// available at https://github.com/uber-go/zap/blob/master/FAQ.md.
117
package zap // import "go.uber.org/zap"
118

119