1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
# 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
<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
- published organized advice for
https://github.com/trentm/node-bunyan/issues/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
|
