proxy.golang.org: github.com/go-logr/logr

Package logr defines a general-purpose logging API and abstract interfaces to back that API. Packages in the Go ecosystem can depend on this package, while callers can implement logging with whatever backend is appropriate. Logging is done using a Logger instance. Logger is a concrete type with methods, which defers the actual logging to a LogSink interface. The main methods of Logger are Info() and Error(). Arguments to Info() and Error() are key/value pairs rather than printf-style formatted strings, emphasizing "structured logging". With Go's standard log package, we might write: With logr's structured logging, we'd write: Errors are much the same. Instead of: We'd write: Info() and Error() are very similar, but they are separate methods so that LogSink implementations can choose to do things like attach additional information (such as stack traces) on calls to Error(). Error() messages are always logged, regardless of the current verbosity. If there is no error instance available, passing nil is valid. Often we want to log information only when the application in "verbose mode". To write log lines that are more verbose, Logger has a V() method. The higher the V-level of a log line, the less critical it is considered. Log-lines with V-levels that are not enabled (as per the LogSink) will not be written. Level V(0) is the default, and logger.V(0).Info() has the same meaning as logger.Info(). Negative V-levels have the same meaning as V(0). Error messages do not have a verbosity level and are always logged. Where we might have written: We can write: Logger instances can have name strings so that all messages logged through that instance have additional context. For example, you might want to add a subsystem name: The WithName() method returns a new Logger, which can be passed to constructors or other functions for further use. Repeated use of WithName() will accumulate name "segments". These name segments will be joined in some way by the LogSink implementation. It is strongly recommended that name segments contain simple identifiers (letters, digits, and hyphen), and do not contain characters that could muddle the log output or confuse the joining operation (e.g. whitespace, commas, periods, slashes, brackets, quotes, etc). Logger instances can store any number of key/value pairs, which will be logged alongside all messages logged through that instance. For example, you might want to create a Logger instance per managed object: With the standard log package, we might write: With logr we'd write: Logger has very few hard rules, with the goal that LogSink implementations might have a lot of freedom to differentiate. There are, however, some things to consider. The log message consists of a constant message attached to the log line. This should generally be a simple description of what's occurring, and should never be a format string. Variable information can then be attached using named values. Keys are arbitrary strings, but should generally be constant values. Values may be any Go value, but how the value is formatted is determined by the LogSink implementation. Logger instances are meant to be passed around by value. Code that receives such a value can call its methods without having to check whether the instance is ready for use. The zero logger (= Logger{}) is identical to Discard() and discards all log entries. Code that receives a Logger by value can simply call it, the methods will never crash. For cases where passing a logger is optional, a pointer to Logger should be used. Keys are not strictly required to conform to any specification or regex, but it is recommended that they: These guidelines help ensure that log data is processed properly regardless of the log implementation. For example, log implementations will try to output JSON data or will store data for later database (e.g. SQL) queries. While users are generally free to use key names of their choice, it's generally best to avoid using the following keys, as they're frequently used by implementations: Implementations are encouraged to make use of these keys to represent the above concepts, when necessary (for example, in a pure-JSON output form, it would be necessary to represent at least message and timestamp as ordinary named values). Implementations may choose to give callers access to the underlying logging implementation. The recommended pattern for this is: Logger grants access to the sink to enable type assertions like this: Custom `With*` functions can be implemented by copying the complete Logger struct and replacing the sink in the copy: Don't use New to construct a new Logger with a LogSink retrieved from an existing Logger. Source code attribution might not work correctly and unexported fields in Logger get lost. Beware that the same LogSink instance may be shared by different logger instances. Calling functions that modify the LogSink will affect all of those.

• Homepage: https://github.com/go-logr/logr
• Documentation: https://pkg.go.dev/github.com/go-logr/logr#section-documentation
• Licenses: Apache-2.0
• Latest release: v1.4.3 (published 12 months ago)
• Last Synced: 2026-05-16T14:51:18.844Z (2 days ago)
• Versions: 20
• Dependent Packages: 36,835
• Dependent Repositories: 50,012
• Docker Downloads: 56,535,761,674
• Rankings:
  • Docker downloads count: 0.004%
  • Dependent packages count: 0.009%
  • Dependent repos count: 0.024%
  • Average: 1.008%
  • Stargazers count: 2.044%
  • Forks count: 2.961%

proxy.golang.org: github.com/Go-Logr/logr

Package logr defines abstract interfaces for logging. Packages can depend on these interfaces and callers can implement logging in whatever way is appropriate. This design derives from Dave Cheney's blog: This is a BETA grade API. Until there is a significant 2nd implementation, I don't really know how it will change. The logging specifically makes it non-trivial to use format strings, to encourage attaching structured information instead of unstructured format strings. Logging is done using a Logger. Loggers can have name prefixes and named values attached, so that all log messages logged with that Logger have some base context associated. The term "key" is used to refer to the name associated with a particular value, to disambiguate it from the general Logger name. For instance, suppose we're trying to reconcile the state of an object, and we want to log that we've made some decision. With the traditional log package, we might write With logr's structured logging, we'd write Depending on our logging implementation, we could then make logging decisions based on field values (like only logging such events for objects in a certain namespace), or copy the structured information into a structured log store. For logging errors, Logger has a method called Error. Suppose we wanted to log an error while reconciling. With the traditional log package, we might write With logr, we'd instead write This functions similarly to: However, it ensures that a standard key for the error value ("error") is used across all error logging. Furthermore, certain implementations may choose to attach additional information (such as stack traces) on calls to Error, so it's preferred to use Error to log errors. Each log message from a Logger has four types of context: logger name, log verbosity, log message, and the named values. The Logger name constists of a series of name "segments" added by successive calls to WithName. These name segments will be joined in some way by the underlying implementation. It is strongly reccomended that name segements contain simple identifiers (letters, digits, and hyphen), and do not contain characters that could muddle the log output or confuse the joining operation (e.g. whitespace, commas, periods, slashes, brackets, quotes, etc). Log verbosity represents how little a log matters. Level zero, the default, matters most. Increasing levels matter less and less. Try to avoid lots of different verbosity levels, and instead provide useful keys, logger names, and log messages for users to filter on. It's illegal to pass a log level below zero. The log message consists of a constant message attached to the the log line. This should generally be a simple description of what's occuring, and should never be a format string. Variable information can then be attached using named values (key/value pairs). Keys are arbitrary strings, while values may be any Go value. While users are generally free to use key names of their choice, it's generally best to avoid using the following keys, as they're frequently used by implementations: Implementations are encouraged to make use of these keys to represent the above concepts, when neccessary (for example, in a pure-JSON output form, it would be necessary to represent at least message and timestamp as ordinary named values).

• Homepage: https://github.com/Go-Logr/logr
• Documentation: https://pkg.go.dev/github.com/Go-Logr/logr#section-documentation
• Licenses: Apache-2.0
• Latest release: v1.4.3 (published 12 months ago)
• Last Synced: 2026-05-15T06:08:05.008Z (4 days ago)
• Versions: 20
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 2.211%
  • Forks count: 3.257%
  • Average: 4.04%
  • Dependent packages count: 5.173%
  • Dependent repos count: 5.52%

proxy.golang.org: github.com/go-logr/Logr

Package logr defines abstract interfaces for logging. Packages can depend on these interfaces and callers can implement logging in whatever way is appropriate. This design derives from Dave Cheney's blog: This is a BETA grade API. Until there is a significant 2nd implementation, I don't really know how it will change. The logging specifically makes it non-trivial to use format strings, to encourage attaching structured information instead of unstructured format strings. Logging is done using a Logger. Loggers can have name prefixes and named values attached, so that all log messages logged with that Logger have some base context associated. The term "key" is used to refer to the name associated with a particular value, to disambiguate it from the general Logger name. For instance, suppose we're trying to reconcile the state of an object, and we want to log that we've made some decision. With the traditional log package, we might write With logr's structured logging, we'd write Depending on our logging implementation, we could then make logging decisions based on field values (like only logging such events for objects in a certain namespace), or copy the structured information into a structured log store. For logging errors, Logger has a method called Error. Suppose we wanted to log an error while reconciling. With the traditional log package, we might write With logr, we'd instead write This functions similarly to: However, it ensures that a standard key for the error value ("error") is used across all error logging. Furthermore, certain implementations may choose to attach additional information (such as stack traces) on calls to Error, so it's preferred to use Error to log errors. Each log message from a Logger has four types of context: logger name, log verbosity, log message, and the named values. The Logger name constists of a series of name "segments" added by successive calls to WithName. These name segments will be joined in some way by the underlying implementation. It is strongly reccomended that name segements contain simple identifiers (letters, digits, and hyphen), and do not contain characters that could muddle the log output or confuse the joining operation (e.g. whitespace, commas, periods, slashes, brackets, quotes, etc). Log verbosity represents how little a log matters. Level zero, the default, matters most. Increasing levels matter less and less. Try to avoid lots of different verbosity levels, and instead provide useful keys, logger names, and log messages for users to filter on. It's illegal to pass a log level below zero. The log message consists of a constant message attached to the the log line. This should generally be a simple description of what's occuring, and should never be a format string. Variable information can then be attached using named values (key/value pairs). Keys are arbitrary strings, while values may be any Go value. While users are generally free to use key names of their choice, it's generally best to avoid using the following keys, as they're frequently used by implementations: Implementations are encouraged to make use of these keys to represent the above concepts, when neccessary (for example, in a pure-JSON output form, it would be necessary to represent at least message and timestamp as ordinary named values).

• Homepage: https://github.com/go-logr/Logr
• Documentation: https://pkg.go.dev/github.com/go-logr/Logr#section-documentation
• Licenses: Apache-2.0
• Latest release: v1.4.3 (published 12 months ago)
• Last Synced: 2026-05-15T06:08:51.565Z (4 days ago)
• Versions: 20
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 2.209%
  • Forks count: 3.264%
  • Average: 4.049%
  • Dependent packages count: 5.187%
  • Dependent repos count: 5.535%

proxy.golang.org: github.com/go-Logr/Logr

Package logr defines abstract interfaces for logging. Packages can depend on these interfaces and callers can implement logging in whatever way is appropriate. This design derives from Dave Cheney's blog: This is a BETA grade API. Until there is a significant 2nd implementation, I don't really know how it will change. The logging specifically makes it non-trivial to use format strings, to encourage attaching structured information instead of unstructured format strings. Logging is done using a Logger. Loggers can have name prefixes and named values attached, so that all log messages logged with that Logger have some base context associated. The term "key" is used to refer to the name associated with a particular value, to disambiguate it from the general Logger name. For instance, suppose we're trying to reconcile the state of an object, and we want to log that we've made some decision. With the traditional log package, we might write With logr's structured logging, we'd write Depending on our logging implementation, we could then make logging decisions based on field values (like only logging such events for objects in a certain namespace), or copy the structured information into a structured log store. For logging errors, Logger has a method called Error. Suppose we wanted to log an error while reconciling. With the traditional log package, we might write With logr, we'd instead write This functions similarly to: However, it ensures that a standard key for the error value ("error") is used across all error logging. Furthermore, certain implementations may choose to attach additional information (such as stack traces) on calls to Error, so it's preferred to use Error to log errors. Each log message from a Logger has four types of context: logger name, log verbosity, log message, and the named values. The Logger name constists of a series of name "segments" added by successive calls to WithName. These name segments will be joined in some way by the underlying implementation. It is strongly reccomended that name segements contain simple identifiers (letters, digits, and hyphen), and do not contain characters that could muddle the log output or confuse the joining operation (e.g. whitespace, commas, periods, slashes, brackets, quotes, etc). Log verbosity represents how little a log matters. Level zero, the default, matters most. Increasing levels matter less and less. Try to avoid lots of different verbosity levels, and instead provide useful keys, logger names, and log messages for users to filter on. It's illegal to pass a log level below zero. The log message consists of a constant message attached to the the log line. This should generally be a simple description of what's occuring, and should never be a format string. Variable information can then be attached using named values (key/value pairs). Keys are arbitrary strings, while values may be any Go value. While users are generally free to use key names of their choice, it's generally best to avoid using the following keys, as they're frequently used by implementations: Implementations are encouraged to make use of these keys to represent the above concepts, when neccessary (for example, in a pure-JSON output form, it would be necessary to represent at least message and timestamp as ordinary named values).

• Homepage: https://github.com/go-Logr/Logr
• Documentation: https://pkg.go.dev/github.com/go-Logr/Logr#section-documentation
• Licenses: Apache-2.0
• Latest release: v1.4.3 (published 12 months ago)
• Last Synced: 2026-05-15T06:08:03.346Z (4 days ago)
• Versions: 20
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 1.316%
  • Forks count: 1.84%
  • Average: 4.875%
  • Dependent packages count: 6.999%
  • Dependent repos count: 9.346%

proxy.golang.org: github.com/go-logr/logr/funcr

Package funcr implements formatting of structured log messages and optionally captures the call site and timestamp. The simplest way to use it is via its implementation of a github.com/go-logr/logr.LogSink with output through an arbitrary "write" function. See New and NewJSON for details. For users who need more control, a funcr.Formatter can be embedded inside your own custom LogSink implementation. This is useful when the LogSink needs to implement additional methods, for example. This will respect logr.Marshaler, fmt.Stringer, and error interfaces for values which are being logged. When rendering a struct, funcr will use Go's standard JSON tags (all except "string").

• Homepage: https://github.com/go-logr/logr
• Documentation: https://pkg.go.dev/github.com/go-logr/logr/funcr#section-documentation
• Licenses: Apache-2.0
• Latest release: v1.4.3 (published 11 days ago)
• Last Synced: 2026-05-15T06:07:32.507Z (4 days ago)
• Versions: 15
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 4.771%
  • Average: 4.931%
  • Dependent repos count: 5.092%

proxy.golang.org: github.com/go-lOGR/logr

Package logr defines abstract interfaces for logging. Packages can depend on these interfaces and callers can implement logging in whatever way is appropriate. This design derives from Dave Cheney's blog: This is a BETA grade API. Until there is a significant 2nd implementation, I don't really know how it will change. The logging specifically makes it non-trivial to use format strings, to encourage attaching structured information instead of unstructured format strings. Logging is done using a Logger. Loggers can have name prefixes and named values attached, so that all log messages logged with that Logger have some base context associated. The term "key" is used to refer to the name associated with a particular value, to disambiguate it from the general Logger name. For instance, suppose we're trying to reconcile the state of an object, and we want to log that we've made some decision. With the traditional log package, we might write With logr's structured logging, we'd write Depending on our logging implementation, we could then make logging decisions based on field values (like only logging such events for objects in a certain namespace), or copy the structured information into a structured log store. For logging errors, Logger has a method called Error. Suppose we wanted to log an error while reconciling. With the traditional log package, we might write With logr, we'd instead write This functions similarly to: However, it ensures that a standard key for the error value ("error") is used across all error logging. Furthermore, certain implementations may choose to attach additional information (such as stack traces) on calls to Error, so it's preferred to use Error to log errors. Each log message from a Logger has four types of context: logger name, log verbosity, log message, and the named values. The Logger name constists of a series of name "segments" added by successive calls to WithName. These name segments will be joined in some way by the underlying implementation. It is strongly reccomended that name segements contain simple identifiers (letters, digits, and hyphen), and do not contain characters that could muddle the log output or confuse the joining operation (e.g. whitespace, commas, periods, slashes, brackets, quotes, etc). Log verbosity represents how little a log matters. Level zero, the default, matters most. Increasing levels matter less and less. Try to avoid lots of different verbosity levels, and instead provide useful keys, logger names, and log messages for users to filter on. It's illegal to pass a log level below zero. The log message consists of a constant message attached to the the log line. This should generally be a simple description of what's occuring, and should never be a format string. Variable information can then be attached using named values (key/value pairs). Keys are arbitrary strings, while values may be any Go value. While users are generally free to use key names of their choice, it's generally best to avoid using the following keys, as they're frequently used by implementations: Implementations are encouraged to make use of these keys to represent the above concepts, when neccessary (for example, in a pure-JSON output form, it would be necessary to represent at least message and timestamp as ordinary named values).

• Homepage: https://github.com/go-lOGR/logr
• Documentation: https://pkg.go.dev/github.com/go-lOGR/logr#section-documentation
• Licenses: Apache-2.0
• Latest release: v1.4.3 (published 12 months ago)
• Last Synced: 2026-05-15T06:08:36.300Z (4 days ago)
• Versions: 20
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 4.948%
  • Average: 5.114%
  • Dependent repos count: 5.28%

debian-12: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Documentation: https://packages.debian.org/bookworm/golang-github-go-logr-logr
• Licenses:
• Latest release: 1.2.3-1 (published 3 months ago)
• Last Synced: 2026-03-12T20:11:52.273Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

ubuntu-23.04: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Licenses:
• Latest release: 1.2.3-1 (published 3 months ago)
• Last Synced: 2026-03-11T09:03:35.307Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

debian-13: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Documentation: https://packages.debian.org/trixie/golang-github-go-logr-logr
• Licenses:
• Latest release: 1.4.2-2 (published 3 months ago)
• Last Synced: 2026-03-13T20:10:24.124Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

ubuntu-24.10: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Licenses:
• Latest release: 1.2.3-1 (published 3 months ago)
• Last Synced: 2026-03-08T15:43:51.980Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

ubuntu-24.04: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Licenses:
• Latest release: 1.2.3-1 (published 3 months ago)
• Last Synced: 2026-03-05T17:09:47.202Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

guix: go-github-com-go-logr-logr

Minimal logging API for Go

• Homepage: https://github.com/go-logr/logr
• Documentation: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/golang-xyz.scm#n10866
• Licenses: asl2.0
• Latest release: 1.4.2 (published 3 months ago)
• Last Synced: 2026-04-27T18:18:33.069Z (21 days ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

ubuntu-23.10: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Licenses:
• Latest release: 1.2.3-1 (published 3 months ago)
• Last Synced: 2026-03-10T04:11:23.228Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

ubuntu-22.04: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Licenses:
• Latest release: 0.4.0-1 (published 3 months ago)
• Last Synced: 2026-03-07T03:38:31.109Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%

debian-11: golang-github-go-logr-logr

• Homepage: https://github.com/go-logr/logr
• Documentation: https://packages.debian.org/bullseye/golang-github-go-logr-logr
• Licenses:
• Latest release: 0.4.0-1 (published 3 months ago)
• Last Synced: 2026-03-14T15:33:39.182Z (2 months ago)
• Versions: 1
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent repos count: 0.0%
  • Dependent packages count: 0.0%
  • Average: 100%