138 lines
5.4 KiB
Markdown
138 lines
5.4 KiB
Markdown
# higher prio
|
|
|
|
- `bunyan` (without redir) ^C should stop, doesn't since recent change
|
|
- 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
|
|
|
|
# v2
|
|
|
|
- ^C fix
|
|
- node-exeunt
|
|
- `createLogger(<config-and-fields>, <fields>)` changes (#460)
|
|
- see section below
|
|
- the dtrace-provider thing (#487)
|
|
TODO: answer Cody email
|
|
- 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?
|
|
|
|
|
|
# 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?
|
|
- 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
|
|
|
|
|
|
|
|
# docs
|
|
|
|
- document log.addStream() and log.addSerializers()
|
|
|
|
|
|
# someday/maybe
|
|
|
|
- 2.0 (?) with `v: 1` in log records. Fwd/bwd compat in `bunyan` 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*.
|
|
- 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 and `this.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.
|
|
- 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
|