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