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//  sugar := zap.NewExample().Sugar()
45//  defer sugar.Sync()
46//  sugar.Infow("failed to fetch URL",
47//    "url", "http://example.com",
48//    "attempt", 3,
49//    "backoff", time.Second,
50//  )
51//  sugar.Infof("failed to fetch URL: %s", "http://example.com")
52//
53// By default, loggers are unbuffered. However, since zap's low-level APIs
54// allow buffering, calling Sync before letting your process exit is a good
55// habit.
56//
57// In the rare contexts where every microsecond and every allocation matter,
58// use the Logger. It's even faster than the SugaredLogger and allocates far
59// less, but it only supports strongly-typed, structured logging.
60//  logger := zap.NewExample()
61//  defer logger.Sync()
62//  logger.Info("failed to fetch URL",
63//    zap.String("url", "http://example.com"),
64//    zap.Int("attempt", 3),
65//    zap.Duration("backoff", time.Second),
66//  )
67//
68// Choosing between the Logger and SugaredLogger doesn't need to be an
69// application-wide decision: converting between the two is simple and
70// inexpensive.
71//   logger := zap.NewExample()
72//   defer logger.Sync()
73//   sugar := logger.Sugar()
74//   plain := sugar.Desugar()
75//
76// Configuring Zap
77//
78// The simplest way to build a Logger is to use zap's opinionated presets:
79// NewExample, NewProduction, and NewDevelopment. These presets build a logger
80// with a single function call:
81//  logger, err := zap.NewProduction()
82//  if err != nil {
83//    log.Fatalf("can't initialize zap logger: %v", err)
84//  }
85//  defer logger.Sync()
86//
87// Presets are fine for small projects, but larger projects and organizations
88// naturally require a bit more customization. For most users, zap's Config
89// struct strikes the right balance between flexibility and convenience. See
90// the package-level BasicConfiguration example for sample code.
91//
92// More unusual configurations (splitting output between files, sending logs
93// to a message queue, etc.) are possible, but require direct use of
94// go.uber.org/zap/zapcore. See the package-level AdvancedConfiguration
95// example for sample code.
96//
97// Extending Zap
98//
99// The zap package itself is a relatively thin wrapper around the interfaces
100// in go.uber.org/zap/zapcore. Extending zap to support a new encoding (e.g.,
101// BSON), a new log sink (e.g., Kafka), or something more exotic (perhaps an
102// exception aggregation service, like Sentry or Rollbar) typically requires
103// implementing the zapcore.Encoder, zapcore.WriteSyncer, or zapcore.Core
104// interfaces. See the zapcore documentation for details.
105//
106// Similarly, package authors can use the high-performance Encoder and Core
107// implementations in the zapcore package to build their own loggers.
108//
109// Frequently Asked Questions
110//
111// An FAQ covering everything from installation errors to design decisions is
112// available at https://github.com/uber-go/zap/blob/master/FAQ.md.
113package zap // import "go.uber.org/zap"
114