Skip to content

Latest commit

 

History

History
139 lines (113 loc) · 5.51 KB

TODO.md

File metadata and controls

139 lines (113 loc) · 5.51 KB
Raw

v2

  • 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?
  • if doing ~/.bunyanrc, then consider color schemes

changes to ctor and log.child to separate fields from config

trentm#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

  • published organized advice for trentm#37 so can close that out. Perhaps a wiki page with examples and strategies.
  • 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 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