log

func (*ConfigWrapper) UnmarshalHCL ¶ added in v0.0.2

func (cw *ConfigWrapper) UnmarshalHCL(ctx *hcl.EvalContext, body hcl.Body) error

UnmarshalHCL processes a HCL configuration and returns a zap.Config and the unparsed remainder of body.

func (*ConfigWrapper) UnmarshalMap ¶ added in v0.0.2

func (cw *ConfigWrapper) UnmarshalMap(m map[string]interface{}) error

UnmarshalMap supports unmarshaling a zap logger configuration from a map. This way, in a pre-proccessing step, different configuration file formats can be parsed. Also, enhancements, like new encoders, are processed. Lastly, environment variables are resolved, including an attempt, at ensuring the variable HOSTNAME (not available on every platform), is made.

func (*EncoderConfigWrapper) UnmarshalHCL ¶ added in v0.0.2

func (ecw *EncoderConfigWrapper) UnmarshalHCL(ctx *hcl.EvalContext, body hcl.Body) error

UnmarshalHCL ...

func (*LogWriterWrapper) Write ¶ added in v0.0.2

func (w *LogWriterWrapper) Write(p []byte) (int, error)

Write implements the io.Writer interface.

func (Logger) Named ¶ added in v0.0.2

func (lg Logger) Named(name string) Logger

Named adds a new path segment to the logger's name. Segments are joined by periods. By default, Loggers are unnamed.

func (Logger) SetLevel ¶ added in v0.0.2

func (lg Logger) SetLevel(lvl zapcore.Level)

SetLevel alters a logger's logging level.

func (Logger) Sugared ¶ added in v0.0.2

func (lg Logger) Sugared() SugaredLogger

Sugared wraps the Logger to provide a more ergonomic, but slightly slower, API. Sugaring a Logger is quite inexpensive, so it's reasonable for a single application to use both Loggers and SugaredLoggers, converting between them on the boundaries of performance-sensitive code.

func (Logger) With ¶ added in v0.0.2

func (lg Logger) With(fields ...zap.Field) Logger

func (Logger) WithLazy ¶ added in v0.0.2

func (lg Logger) WithLazy(fields ...zap.Field) Logger

WithLazy creates a child logger and adds structured context to it lazily.

The fields are evaluated only if the logger is further chained with [With] or is written to with any of the log level methods. Until that occurs, the logger may retain references to objects inside the fields, and logging will reflect the state of an object at the time of logging, not the time of WithLazy().

WithLazy provides a worthwhile performance optimization for contextual loggers when the likelihood of using the child logger is low, such as error paths and rarely taken branches.

Similar to [With], fields added to the child don't affect the parent, and vice versa.

func (Logger) WithOptions ¶ added in v0.0.2

func (lg Logger) WithOptions(options ...zap.Option) Logger

WithOptions clones the current Logger, applies the supplied Options, and returns the resulting Logger. It's safe to use concurrently.

func (SugaredLogger) Desugar ¶ added in v0.0.2

func (lg SugaredLogger) Desugar() Logger

Desugar unwraps a SugaredLogger, exposing the original Logger. Desugaring is quite inexpensive, so it's reasonable for a single application to use both Loggers and SugaredLoggers, converting between them on the boundaries of performance-sensitive code.

func (SugaredLogger) Named ¶ added in v0.0.2

func (lg SugaredLogger) Named(name string) SugaredLogger

Named adds a sub-scope to the logger's name. See Logger.Named for details.

func (SugaredLogger) With ¶ added in v0.0.2

func (lg SugaredLogger) With(args ...interface{}) SugaredLogger

With adds a variadic number of fields to the logging context. It accepts a mix of strongly-typed Field objects and loosely-typed key-value pairs. When processing pairs, the first element of the pair is used as the field key and the second as the field value.

For example,

 sugaredLogger.With(
   "hello", "world",
   "failure", errors.New("oh no"),
   Stack(),
   "count", 42,
   "user", User{Name: "alice"},
)

is the equivalent of

unsugared.With(
  String("hello", "world"),
  String("failure", "oh no"),
  Stack(),
  Int("count", 42),
  Object("user", User{Name: "alice"}),
)

Note that the keys in key-value pairs should be strings. In development, passing a non-string key panics. In production, the logger is more forgiving: a separate error is logged, but the key-value pair is skipped and execution continues. Passing an orphaned key triggers similar behavior: panics in development and errors in production.