TheThing/node-bunyan-lite
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Wiki Activity

clarify log level best practices

Browse source
This commit is contained in:
Trent Mick 2012-09-10 12:13:31 -07:00
parent d96b1c757f
commit 02b5863f46
1 changed files with 18 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
README.md
View file

@ -227,20 +227,25 @@ in production.**
# Levels # Levels
The log levels in bunyan are: The log levels in bunyan are as follows. The level descriptions are best
practice *opinions*.
- "fatal" (60): the service/app is going to stop or become unusable now - "fatal" (60): The service/app is going to stop or become unusable now.
- "error" (50): fatal for a particular request, but the service/app continues servicing other requests An operator should definitely look into this soon.
- "warn" (40): a note on something that should probably be looked at by an operator - "error" (50): Fatal for a particular request, but the service/app continues
- "info" (30): detail on regular operation servicing other requests. An operator should look at this soon(ish).
- "debug" (20): anything else, i.e. too verbose to be included in "info" level. - "warn" (40): A note on something that should probably be looked at by an
- "trace" (10): logging from external libraries used by your app operator eventually.
- "info" (30): Detail on regular operation.
- "debug" (20): Anything else, i.e. too verbose to be included in "info" level.
- "trace" (10): Logging from external libraries used by your app or *very*
detailed application logging.
General level usage suggestions: "debug" should be used sparingly. Suggestions: Use "debug" sparingly. Information that will be useful to debug
Information that will be useful to debug errors *post mortem* should usually errors *post mortem* should usually be included in "info" messages if it's
be included in "info" messages if it's generally relevant or else with the generally relevant or else with the corresponding "error" event. Don't rely
corresponding "error" event. Don't rely on spewing mostly irrelevant debug on spewing mostly irrelevant debug messages all the time and sifting through
messages all the time and sifting through them when an error occurs. them when an error occurs.
Integers are used for the actual level values (10 for "trace", ..., 60 for Integers are used for the actual level values (10 for "trace", ..., 60 for
"fatal") and constants are defined for the (Logger.TRACE ... Logger.DEBUG). "fatal") and constants are defined for the (Logger.TRACE ... Logger.DEBUG).
@ -515,7 +520,7 @@ This example emits:
# Versioning # Versioning
The scheme I follow is most succintly described by the bootstrap guys The scheme I follow is most succintly described by the bootstrap guys
[here](https://github.com/twitter/bootstrap#versioning). [here](https://github.com/twitter/bootstrap#versioning).
tl;dr: All versions are `<major>.<minor>.<patch>` which will be incremented for tl;dr: All versions are `<major>.<minor>.<patch>` which will be incremented for
breaking backward compat and major reworks, new features without breaking breaking backward compat and major reworks, new features without breaking