Skip to content

lib/log: initial implementation

Administrator requested to merge zap-logger-proposal into main

Created by: bobheadxi

Sets up an initial draft of the logging library, and what the implementation might look like. Closes https://github.com/sourcegraph/sourcegraph/issues/33953 , closes https://github.com/sourcegraph/sourcegraph/issues/33477, closes https://github.com/sourcegraph/sourcegraph/issues/33474 as part of https://github.com/sourcegraph/sourcegraph/issues/33192

Some core concepts:

  1. Do not export directly usable log functions. We want to encourage users to hold their own references to loggers, so that fields can be attached. 2. Internally we still maintain a global logger with Resource information though, which tracks the current program.
  2. Export a subset of Zap API. Hopefully, users of this package will never have to import zap directly. Whether or not that's a good idea yet... not sure, but I think it is - makes the API surface much smaller
    1. Related - we're only exporting the strongly typed logger implementation. Too verbose? Maybe, but I think this interface is better than the log15-like SugaredLogger, and in combination with restricted API avoids having giant objects be logged.
    2. If we're okay with this, it makes https://github.com/sourcegraph/sourcegraph/issues/33473 much easier, because we can just hook into the re-exported Field constructors
  3. The standard logger tries its hardest to be OpenTelemtry-compliant https://opentelemetry.io/docs/reference/specification/logs/data-mode , and as such requires some slight hackery with zapAdapter
  4. Desired (distant) end state: ban imports of log15, log, zap, etc. - all logging must handle by log.Scoped() and then using that

Prior art:

Currently not in scope:

Test plan

unit tests and manual tests. this is mostly pretty self-contained at the moment

Merge request reports

Loading