node-bunyan-lite/README.md

127 lines
3.4 KiB
Markdown
Raw Normal View History

2012-01-30 06:26:47 +00:00
Bunyan -- a JSON Logger for node.js servers.
Server logs should be structured. JSON's a good format. Let's do that: a log
record is one line of `JSON.stringify`'d output. Let's also specify some common
names for the requisite and common fields for a log record (see below).
Also: log4j is way more than you need.
2012-01-31 00:30:05 +00:00
# Current Status
Just play stuff here. Don't try to use this for realz yet.
2012-01-30 06:26:47 +00:00
# Usage
2012-01-31 00:30:05 +00:00
The usual. All loggers must provide a "service" name. This is somewhat akin
to log4j logger "name", but Bunyan doesn't so hierarchical logger names.
$ cat hi.js
2012-01-30 06:26:47 +00:00
var Logger = require('bunyan');
2012-01-31 00:30:05 +00:00
var log = new Logger({service: "myapp", level: "info"});
2012-01-30 06:26:47 +00:00
log.info("hi");
2012-01-31 00:30:05 +00:00
Log records are JSON. "hostname", "time" and "v" (the Bunyan log
format version) are added for you.
2012-01-30 06:26:47 +00:00
$ node hi.js
2012-01-31 00:30:05 +00:00
{"service":"myapp","hostname":"banana.local","level":2,"msg":"hi","time":"2012-01-31T00:07:44.216Z","v":0}
A `bunyan` tool is provided for pretty-printing bunyan logs and, eventually,
for filtering (e.g. `| bunyan -c 'level>3'`). This shows the default output
(which is fluid right now) and indented-JSON output. More output formats will
be added, including support for custom formats.
2012-01-30 06:26:47 +00:00
2012-01-31 00:30:05 +00:00
$ node hi.js | ./bin/bunyan # CLI tool to filter/pretty-print JSON logs.
[2012-01-31T00:08:11.387Z] INFO: myapp on banana.local: hi (<no-request_id>)
$ node hi.js | ./bin/bunyan -o json
2012-01-30 06:26:47 +00:00
{
2012-01-31 00:30:05 +00:00
"service": "myapp",
"hostname": "banana.local",
2012-01-30 06:26:47 +00:00
"level": 2,
2012-01-31 00:30:05 +00:00
"msg": "hi",
"time": "2012-01-31T00:10:00.676Z",
"v": 0
2012-01-30 06:26:47 +00:00
}
2012-01-31 00:30:05 +00:00
By default, log output is to stdout. Explicitly that looks like:
var log = new Logger({service: "myapp", stream: process.stdout});
That is an abbreviated form for a single stream. You can defined multiple
streams at different levels:
var log = new Logger({
service: "amon",
streams: [
{
level: "info",
stream: process.stdout, // log INFO and above to stdout
},
{
level: "error",
path: "tmp/error.log" // log ERROR and above to a file
}
]
});
Support for syslog is planned.
# Future
See "TODO.md", but basically:
- "Renderer" support to handle extracting a JSON object for a log record
for particular object types, e.g. an HTTP request. So for example we
could do:
log.info({req: req}, "something about handling this request")
And the "req" renderer would extract a reasonable JSON object for that
request object -- presumably a subset of all attributes on the request
object.
This will key off the field name, IOW by convention, rather than getting
into `instanceof` grossness.
- Spec'ing and enforcing the fields (from dap's section in eng guide).
- Syslog support. Ring-buffer support for storing last N debug messages
(or whatever) in memory to support debugability without too much log load.
- More `bunyan` output formats and filtering features.
- Think about a bunyan dashboard that supports organizing and viewing logs
from multiple hosts and services.
2012-01-30 06:26:47 +00:00
# Levels
fatal
error
warn
info
debug
2012-01-31 00:30:05 +00:00
TODO: doc these.
2012-01-30 06:26:47 +00:00
# Log Record Fields
2012-01-31 00:30:05 +00:00
TODO: from dap and enforce these
- "request_id" (better name?) can't be required because some things don't
happen in a per-request context. Startup and background processing stuff
for example. Tho for request-y things, it is strongly encouraged because it
allows collating logs from multiple services for the same request.
2012-01-30 06:26:47 +00:00
# License
MIT.