10 KiB
v2
-
Exit handling:
- make a ticket with notes from "bunyan CLI exit handling" section below
- resolve it with the uncommited changes here
-
figure out how to 'make cutarelease' for 2.x but tag as beta
-
comment/grokking of bunyan.js flushing issues at https://github.com/trentm/node-bunyan/issues/37 would be nice. Even if just a link to exeunt and some examples. Wiki page?
- respond to Qs here: https://github.com/trentm/node-bunyan/issues/37#issuecomment-282933502
-
consider whether to backport the exit handling work to 1.x???
-
createLogger(<config-and-fields>, <fields>)
changes (#460)- see section below
-
the dtrace-provider thing (#487) TODO: answer Cody email
-
https://github.com/trentm/node-bunyan/issues/398 if easy, perhaps on 1.x as well
-
use package.json version for VERSION
-
use deps
- dashdash
- assert-plus?
- verror?
-
break out to multiple files
- want to work through PRs before that, so don't just break them all
-
TODO: a quick pass through tickets and pulls for other things to include
-
get ticket refs for the above, if any
-
formatters: read up again on
glp master..1.x
-
support for customer formatters
- for the CLI as well? How? ~/.bunyanrc?
-
if doing ~/.bunyanrc, then consider color schemes
bunyan CLI exit handling
It has some problems currently.
One basic problem is that our stdout.on('error') handler can call into drainStdoutAndExit multiple times, leading to the multiple Event Emitters leak warning, and with a pager we are waiting for the pager to exit. Why doesn't the pager exit on ^C? Is that a less thing? Perhaps due to our LESS opts?
Setting up a file to work with:
$ cat lots.js
var bunyan = require('./')
var log = bunyan.createLogger({
name: 'lots',
streams: [
{
type: 'file',
path: './lots.log'
}
]
});
N = Math.pow(2, 16);
for (var i = N; i >= 0; i--) {
log.info({i: i}, 'another record');
}
$ node lots.js
Issue 1: EventEmitter mem leak
$ node --version
v4.8.0
$ ./bin/bunyan lots.log | cat
[2017-04-05T01:47:15.899Z] INFO: lots/53218 on danger0.local: another record (i=65536)
[2017-04-05T01:47:15.901Z] INFO: lots/53218 on danger0.local: another record (i=65535)
...
^C # ^C quickly before it is done writing rendered logs
...
[2017-04-05T01:47:16.023Z] INFO: lots/53218 on danger0.local: another record (i=57351)
[2017-04-05T01:47:16.023Z] INFO: lots/53218
^C(node) warning: possible EventEmitter memory leak detected. 11 drain listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
at Socket.addListener (events.js:239:17)
at Socket.Readable.on (_stream_readable.js:680:33)
at drainStdoutAndExit (/Users/trentm/tm/node-bunyan/bin/bunyan:1116:12)
at Socket.<anonymous> (/Users/trentm/tm/node-bunyan/bin/bunyan:1597:13)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at onwriteError (_stream_writable.js:313:10)
at onwrite (_stream_writable.js:331:5)
at WritableState.onwrite (_stream_writable.js:90:5)
at fireErrorCallbacks (net.js:457:13)
Issue 2: "write after end" infinite loop with ^C in pager
Mac. Node v4.8.0. Happens with node 0.10 as well.
$ ./bin/bunyan lots.log
[2017-04-05T01:47:15.899Z] INFO: lots/53218 on danger0.local: another record (i=65536)
[2017-04-05T01:47:15.901Z] INFO: lots/53218 on danger0.local: another record (i=65535)
[2017-04-05T01:47:15.901Z] INFO: lots/53218 on danger0.local: another record (i=65534)
...
^C
...
[2017-04-05T01:47:15.909Z] INFO: lots/53218 on danger0.local: another record (i=65490)
:[Error: write after end]
[Error: write after end]
[Error: write after end]
[Error: write after end]
[Error: write after end]
(node) warning: possible EventEmitter memory leak detected. 11 drain listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
at Socket.addListener (events.js:239:17)
at Socket.Readable.on (_stream_readable.js:680:33)
at drainStdoutAndExit (/Users/trentm/tm/node-bunyan/bin/bunyan:1116:12)
at Socket.<anonymous> (/Users/trentm/tm/node-bunyan/bin/bunyan:1600:13)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at writeAfterEnd (_stream_writable.js:169:10)
at Socket.Writable.write (_stream_writable.js:212:5)
at Socket.write (net.js:645:40)
at emit (/Users/trentm/tm/node-bunyan/bin/bunyan:1097:32)
[Error: write after end]
[Error: write after end]
[Error: write after end]
[Error: write after end]
... # this goes forever until 'q' to quit pager
With bunyan's internal _DEBUG
:
...
[2017-04-05T01:47:15.909Z] INFO: lots/53218 on danger0.local: another record (i=65491)
[2017-04-05T01:47:15.909Z] INFO: lots/53218 on danger0.local: another record (i=65490)
:(bunyan: cleanupAndExit)
(stdout error event: Error: write after end)
[Error: write after end]
(drainStdoutAndExit(1))
(stdout error event: Error: write after end)
[Error: write after end]
(drainStdoutAndExit(1))
(stdout error event: Error: write after end)
[Error: write after end]
(drainStdoutAndExit(1))
(stdout error event: Error: write after end)
[Error: write after end]
...
(drainStdoutAndExit(1))
(stdout error event: Error: write EPIPE)
(drainStdoutAndExit(0))
(bunyan: pager exit)
(bunyan: pager exit -> process.exit(1))
changes to ctor and log.child to separate fields from config
https://github.com/trentm/node-bunyan/issues/460
Current:
createLogger(<config-and-fields>)
log.child(<config-and-fields>, <just-fields-bool>)
Could be:
createLogger(<config-and-fields>, <fields>)
log.child(<config-and-fields>, <fields>)
# Still support: log.child(<config-and-fields>, <just-fields-bool>)
Pros: Compat issues are minimal: a change is only required if there is a
collision with used field and a new config var name.
Cons: A slight con is that my guess is the common usage of child is
log.child(<fields>)
, so the more future-proof common usage becomes:
log.child(null, <fields>)
That's not too bad. It is clearer at least than:
log.child(<fields>, true)
TODO:
- is there a ticket for this work already? #460
- make the change
- do a migration guide? i.e. provide the grep commands to find all
possible calls to inspect. E.g. if don't have
rg logUndefined
in your code, then you are fine. And one time future-proofing via changing to fields in the second arg. - list of issues/pulls that wanted to add new config fields
higher prio
- man page for the bunyan CLI (refer to it in the readme)
- perhaps wait for a bunyan new version with deps, and use dashdash with a (vapour) man page generator
docs
- document log.addStream() and log.addSerializers()
someday/maybe
-
2.0 (?) with
v: 1
in log records. Fwd/bwd compat inbunyan
CLI -
tail -f
-like support -
full-on docs
-
better examples/
-
better coloring
-
look at pino (bunyan style, perf benefits)
-
would be exciting to have bunyan support in http://lnav.org/ if that made sense
-
"template" support for 'rotating-file' stream to get dated rolled files
-
"all" or "off" levels? log4j? logging.py? logging.py has NOTSET === 0. I think that is only needed/used for multi-level hierarchical effective level.
-
buffered writes to increase speed:
- I'd start with a tools/timeoutput.js for some numbers to compare before/after. Sustained high output to a file.
- perhaps this would be a "buffered: true" option on the stream object
- then wrap the "stream" with a local class that handles the buffering
- to finish this, need the 'log.close' and
process.on('exit', ...)
work that Trent has started.
-
"canWrite" handling for full streams. Need to buffer a la log4js
-
test file log with logadm rotation: does it handle that?
-
test suite:
- test for a cloned logger double-
stream.end()
causing problems. Perhaps the "closeOnExit" for existing streams should be false for clones. - test that a
log.clone(...)
adding a new field matching a serializer works and that an existing field in the parent is not re-serialized.
- test for a cloned logger double-
-
split out
bunyan
cli to a "bunyan" or "bunyan-reader" or "node-bunyan-reader" as the basis for tools to consume bunyan logs. It can grow indep of node-bunyan for generating the logs. It would take a Bunyan log record object and be expected to emit it.node-bunyan-reader .createReadStream(path, [options]) ?
-
coloring bug: in less the indented extra info lines only have the first line colored. Do we need the ANSI char on each line? That'll be slower.
-
document "well-known" keys from bunyan CLI p.o.v.. Add "client_req".
-
More
bunyan
output formats and filtering features. -
Think about a bunyan dashboard that supports organizing and viewing logs from multiple hosts and services.
-
doc the restify RequestCaptureStream usage of RingBuffer. Great example.
-
A vim plugin (a la http://vim.cybermirror.org/runtime/autoload/zip.vim ?) to allow browsing (read-only) a bunyan log in rendered form.
-
Some speed comparisons with others to get a feel for Bunyan's speed.
-
what about promoting 'latency' field and making that easier?
-
log.close
to close streams and shutdown andthis.closed
process.on('exit', log.close) -> 'end' for the name -
bunyan cli: more layouts (http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/EnhancedPatternLayout.html) Custom log formats (in config file? in '-f' arg) using printf or hogan.js or whatever. Dap wants field width control for lining up. Hogan.js is probably overkill for this.
-
loggly example using raw streams, hook.io?, whatever.
-
serializer support:
- restify-server.js example -> restifyReq ? or have
req
detect that. That is nicer for the "use all standard ones". Does restify req have anything special? - differential HTTP client req/res with server req/res.
- restify-server.js example -> restifyReq ? or have
-
statsd stream? http://codeascraft.etsy.com/2011/02/15/measure-anything-measure-everything/ Think about it.
-
web ui. Ideas: http://googlecloudplatform.blogspot.ca/2014/04/a-new-logs-viewer-for-google-cloud.html