23 lines
1.8 KiB
Go
23 lines
1.8 KiB
Go
// Copyright 2020 the Pinniped contributors. All Rights Reserved.
|
|
// SPDX-License-Identifier: Apache-2.0
|
|
|
|
// Package plog implements a thin layer over klog to help enforce pinniped's logging convention.
|
|
// Logs are always structured as a constant message with key and value pairs of related metadata.
|
|
// The logging levels in order of increasing verbosity are:
|
|
// error, warning, info, debug, trace and all.
|
|
// error and warning logs are always emitted (there is no way for the end user to disable them),
|
|
// and thus should be used sparingly. Ideally, logs at these levels should be actionable.
|
|
// info should be reserved for "nice to know" information. It should be possible to run a production
|
|
// pinniped server at the info log level with no performance degradation due to high log volume.
|
|
// debug should be used for information targeted at developers and to aid in support cases. Care must
|
|
// be taken at this level to not leak any secrets into the log stream. That is, even though debug may
|
|
// cause performance issues in production, it must not cause security issues in production.
|
|
// trace should be used to log information related to timing (i.e. the time it took a controller to sync).
|
|
// Just like debug, trace should not leak secrets into the log stream. trace will likely leak information
|
|
// about the current state of the process, but that, along with performance degradation, is expected.
|
|
// all is reserved for the most verbose and security sensitive information. At this level, full request
|
|
// metadata such as headers and parameters along with the body may be logged. This level is completely
|
|
// unfit for production use both from a performance and security standpoint. Using it is generally an
|
|
// act of desperation to determine why the system is broken.
|
|
package plog
|