Mirrors/coredns
1
0
Fork 0
mirror of https://github.com/coredns/coredns.git synced 2025-10-27 00:04:15 -04:00
Code Issues Packages Projects Releases Wiki Activity

pkg/log: ability for debug logs (#1689)

Browse Source 
* pkg/log: ability for debug logs

When the debug plugin is enabled all log.Debug calls will print to
standard; if not there are a noop (almost).

The log package wraps some standard log functions as well, so just
replacing "log" with "plugin/pkg/log" should be enough to use this
package.

* docs

* Add docs

* lint

* Test fallthrough to log pkg as well

* simple package - up test coverage

* add other log levels as well

* update docs
This commit is contained in:
Miek Gieben
2018-04-18 21:02:01 +01:00
committed by GitHub
parent 51e1442bd9
commit b4b65fbc18
4 changed files with 140 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
plugin.md
View File

@@ -35,11 +35,15 @@ See a couple of blog posts on how to write and add plugin to CoreDNS:
## Logging
If your plugin needs to output a log line you should use the `log` package. CoreDNS does not
implement log levels. The standard way of outputing is: `log.Printf("[LEVEL] ...")`, and LEVEL
can be: `INFO`, `WARNING` or `ERROR`.
If your plugin needs to output a log line you should use the `plugin/pkg/log` package. This package
implements log levels. The standard way of outputting is: `log.Info` for info level messages. The
levels available are `log.Info`, `log.Warning`, `log.Error`, `log.Debug`. Each of these also has
a `f` variant.
In general, logging should be left to the higher layers by returning an error. However, if there is
a reason to consume the error but notify the user, then logging in the plugin can be acceptable.
a reason to consume the error and notify the user, then logging in the plugin itself can be
acceptable. The `Debug*` functions only output something when the *debug* plugin is loaded in the
server.
## Metrics