派生自 TAI_OTS_Mail
Known issues:
(nothing yet)
This was reported privately as:
https://hackerone.com/reports/902739
bunyan - RCE via insecure command formatting
Previous to this version the 'bunyan' CLI was not escaping a given argument
to the '-p' option before executing ps -A -o pid,command | grep '$ARG'
which could lead to unintended execution.
bunyan CLI to not duplicate the "HTTP/1.1 ..." statusbunyan 1.x CLI adds a Host: $client_req.address[:$client_req.port]client_req field in a log record. Fix that here to:client_req.headers already includes a host header; andport if it is 80 or 443 (*assuming* that is thebunyan 2.x CLI will stop adding this Host header because it is a guessbunyan errors out if attempting to use -p PID andbunyan CLI versionSIGINT was ignored, such that Ctrl+C could not be used to"use strict;") error in some versions ofNote: Bad release. Use 1.8.8 or later.
Note: Bad release. Use 1.8.7 or later.
safeCycles is too slow when logging large objects.src usage with node v7.log.info(null) crash that resulted from #426 in v1.8.2.log.info({err: err}) results in a "msg" value, justlog.info(err).Note: Bad release. An addition in this release broke 'rotating-file' usage.
Use 1.8.1 or later.
bunyan -p ... (i.e. DTrace integration) on node[issue #332, pull #355] Ensure stream for type='stream' stream is a writable
stream. (By Michael Nisi.)
[issue #344] Fix "rotating-file" Bunyan streams to not miss rotations when configured
for a period greater than approximately 25 days. Before this there was an issue
where periods greater than node.js's maximum setTimeout length would fail to rotate.
(By Martijn Schrage.)
[issue #234, pull #345] Improve bunyan CLI rendering of "res" field
HTTP responses to not show two blank lines for an empty body.
(By Michael Nisi.)
[pull #311, #302, #310] Improve the runtime environment detection to fix
running under NW.js. Contributions by Adam Lynch, Jeremy
Ruppel, and Aleksey Timchenko.
[pull #318] Add reemitErrorEvents optional boolean for streams added to a
Bunyan logger to control whether an "error" event on the stream will be
re-emitted on the Logger instance.
var log = bunyan.createLogger({
name: 'foo',
streams: [
{
type: 'raw',
stream: new MyCustomStream(),
reemitErrorEvents: true
}
]
});
Before this change, "error" events were re-emitted on file
streams only. The new
behaviour is as follows:
- `reemitErrorEvents` not specified: `file` streams will re-emit error events
on the Logger instance.
- `reemitErrorEvents: true`: error events will be re-emitted on the Logger
for any stream with a `.on()` function -- which includes file streams,
process.stdout/stderr, and any object that inherits from EventEmitter.
- `reemitErrorEvents: false`: error events will not be re-emitted for any
streams.
Dev Note: Bunyan Logger objects don't currently have a .close() method
in which registered error event handlers can be *un*registered. That means
that a (presumably rare) situation where code adds dozens of Bunyan Logger
streams to, e.g. process.stdout, and with reemitErrorEvents: true, could
result in leaking Logger objects.
Original work for allowing "error" re-emitting on non-file streams is
by Marc Udoff in pull #318.
[pull #304, issue #245] Use [Moment.js][momentjs.com] library to handle
bunyan CLI time formatting in some cases, especially to fix display of
local time. It is now required for local time formatting (i.e. bunyan -L
or bunyan --time local). (By David M. Lee.)
[pull #252] Fix errant client_res={} in bunyan CLI rendering, and avoid
extra newlines in client_req rendering in some cases. (By Thomas Heymann.)
[pull #291, issue #303] Fix LOG.child(...) to not override the "hostname"
field of the parent. A use case is when one manually sets "hostname" to
something other than os.hostname(). (By github.com/Cactusbone.)
[issue #325] Allow one to set level: 0 in createLogger to turn on
logging for all levels. (Adapted from #336 by github.com/sometimesalready.)
Add guards (to resolveLevel) so that all "level" values are validated.
Before this, a bogus level like "foo" or -12 or ['some', 'array'] would
silently be accepted -- with undefined results.
Doc updates for #340 and #305.
Update make test to test against node 5, 4, 0.12 and 0.10.
src: true, which was broken in v1.5.0.Note: Bad release. The addition of 'use strict'; broke Bunyan's src: true
feature. Use 1.5.1 instead.
(Bumping minor ver b/c I'm wary of dtrace-provider changes. :)
bunyan defensive on res.header=null.bunyan defensive on res.header as a boolean.bunyan defensive on err.stack not being a string.log.child(...) to work even if the logger is a sub-classhaveNonRawStreams on <logger>.addStream.JSON.stringify throws -- possibly with an enumerable propertyExport bunyan.RotatingFileStream which is needed if one wants to
customize it. E.g. see issue #194.
[pull #122] Source Map support for caller line position for the "src"
field. This could be interesting
for CoffeeScript
users of Bunyan. By Manuel Schneider.
[issue #164] Ensure a top-level level given in bunyan.createLogger
is used for given streams. For example, ensure that the following
results in the stream having a DEBUG level:
var log = bunyan.createLogger({
name: 'foo',
level: 'debug',
streams: [
{
path: '/var/tmp/foo.log'
}
]
});
This was broken in the 1.0.1 release. Between that release and 1.3.0
the "/var/tmp/foo.log" stream would be at the INFO level (Bunyan's
default level).
[issue #103] bunyan -L (or bunyan --time local) to show local time.
Bunyan log records store time in UTC time. Sometimes it is convenient
to display in local time.
[issue #205] Fix the "The Bunyan CLI crashed!" checking to properly warn of
the common failure case when -c CONDITION is being used.
[issue #210] Export bunyan.nameFromLevel and bunyan.levelFromName. It can
be a pain for custom streams to have to reproduce that.
[issue #100] Gracefully handle the case of an unbound
Logger.{info,debug,...} being used for logging, e.g.:
myEmittingThing.on('data', log.info)
Before this change, bunyan would throw. Now it emits a warning to stderr
once, and then silently ignores those log attempts, e.g.:
bunyan usage error: /Users/trentm/tm/node-bunyan/foo.js:12: attempt to log with an unbound log method: `this` is: { _events: { data: [Function] } }
FATAL + 1 to turn logging off. While the standard named log levels areDtrace-provider version 0.3.0 add build sugar that should eliminate the
problems from older versions:
The build is not attempted on Linux and Windows. The build spew is
not emitted by default (use V=1 npm install to see it); instead a
short warning is emitted if the build fails.
Also, importantly, the new dtrace-provider fixes working with node
v0.11/0.12.
err fields in bunyan CLI output. Beforelog.info(err) on a logger with no serializers.Note: Bad release. It breaks log.info(err) on a logger with no serializers.
Use version 1.1.2.
log.info(err) to use the log Logger's err[issues #105, #138, #151] Export <Logger>.addStream(...) and
<Logger>.addSerializers(...) to be able to add them after Logger creation.
Thanks @andreineculau!
[issue #159] Fix bad handling in construtor guard intending to allow
creation without "new": var log = Logger(...). Thanks @rmg!
[issue #156] Smaller install size via .npmignore file.
[issue #126, #161] Ignore SIGINT (Ctrl+C) when processing stdin. ...| bunyan
should expect the preceding process in the pipeline to handle SIGINT. While
it is doing so, bunyan should continue to process any remaining output.
Thanks @timborodin and @jnordberg!
[issue #160] Stop using ANSI 'grey' in bunyan CLI output, because of the
problems that causes with Solarized Dark themes (see
https://github.com/altercation/solarized/issues/220).
-c CODE improvingThe -c CODE implementation was changed to use a JS function for processing
rather than vm.runInNewContext. The latter was specatularly slow, so
won't be missed. Unfortunately this does mean a few semantic differences in
the CODE, the most noticeable of which is that this is required to
access the object fields:
# Bad. Works with bunyan 0.x but not 1.x.
$ bunyan -c 'pid === 123' foo.log
...
# Good. Works with all versions of bunyan
$ bunyan -c 'this.pid === 123' foo.log
...
The old behaviour of -c can be restored with the BUNYAN_EXEC=vm
environment variable:
$ BUNYAN_EXEC=vm bunyan -c 'pid === 123' foo.log
...
Some sugar was also added: the TRACE, DEBUG, ... constants are defined, so
one can:
$ bunyan -c 'this.level >= ERROR && this.component === "http"' foo.log
...
And example of the speed improvement on a 10 MiB log example:
$ time BUNYAN_EXEC=vm bunyan -c 'this.level === ERROR' big.log | cat >slow
real 0m6.349s
user 0m6.292s
sys 0m0.110s
$ time bunyan -c 'this.level === ERROR' big.log | cat >fast
real 0m0.333s
user 0m0.303s
sys 0m0.028s
The change was courtesy Patrick Mooney (https://github.com/pfmooney). Thanks!
Add bunyan -0 ... shortcut for bunyan -o bunyan ....
[issue #135] Backward incompatible. Drop dtrace-provider even from
optionalDependencies. Dtrace-provider has proven a consistent barrier to
installing bunyan, because it is a binary dep. Even as an optional dep it
still caused confusion and install noise.
Users of Bunyan on dtrace-y platforms (SmartOS, Mac, Illumos, Solaris) will
need to manually npm install dtrace-provider themselves to get Bunyan's
dtrace support
to work. If not installed, bunyan should stub it out properly.
[issue #139] Fix bunyan crash on a log record with res.header that is an
object. A side effect of this improvement is that a record with res.statusCode
but no header info will render a response block, for example:
[2012-08-08T10:25:47.637Z] INFO: my-service/12859 on my-host: some message (...)
...
--
HTTP/1.1 200 OK
--
...
[pull #42] Fix bunyan crash on a log record with req.headers that is a string
(by https://github.com/aexmachina).
Drop node 0.6 support. I can't effectively npm install with a node 0.6
anymore.
[issue #85] Ensure logging a non-object/non-string doesn't throw (by
https://github.com/mhart). This changes fixes:
log.info(<bool>) # TypeError: Object.keys called on non-object
log.info(<function>) # "msg":"" (instead of wanted "msg":"[Function]")
log.info(<array>) # "msg":"" (instead of wanted "msg":util.format(<array>))
Note: Bad release. The published package in the npm registry got corrupted. Use 0.22.3 or later.
[issue #131] Allow log.info(<number>) and, most importantly, don't crash on that.
Update 'mv' optional dep to latest.
[issue #111] Fix a crash when attempting to use bunyan -p on a platform without
dtrace.
[issue #101] Fix a crash in bunyan rendering a record with unexpected "res.headers".
log.reopenFileStreams() convenience method to be used with external logbunyan to default to paging (with less) by default in node 0.10.0.bunyan -p '*' breakage in version 0.21.2.Note: Bad release. The switchrate change below broke bunyan -p '*' usage
(see issue #90). Use 0.21.3 or later.
[issue #88] Should be able to efficiently combine "-l" with "-p *".
Avoid DTrace buffer filling up, e.g. like this:
$ bunyan -p 42241 > /tmp/all.log
dtrace: error on enabled probe ID 3 (ID 75795: bunyan42241:mod-87ea640:log-trace:log-trace): out of scratch space in action #1 at DIF offset 12
dtrace: error on enabled probe ID 3 (ID 75795: bunyan42241:mod-87ea640:log-trace:log-trace): out of scratch space in action #1 at DIF offset 12
dtrace: 138 drops on CPU 4
...
From Bryan: "the DTrace buffer is filling up because the string size is so
large... by increasing the switchrate, you're increasing the rate at
which that buffer is emptied."
period (by github.com/ricardograca).This also makes a semantic change to custom serializers. Before this change
a serializer function was called for a log record key when that value was
truth-y. The semantic change is to call the serializer function as long
as the value is not undefined. That means that a serializer function
should handle falsey values such as false and null.
WARNING: This release includes a bug introduced in bunyan 0.18.3 (see
below). Please upgrade to bunyan 0.20.0.
bunyan.stdSerializers.err) to not serialize all additionalchild_process.exec).Concrete examples where this has hurt have been the "domain" change
necessitating 0.18.3 and a case where
node-restify uses an error object
as the response object. When logging the err and res in the same log
statement (common for restify audit logging), the res.body would be JSON
stringified as '[Circular]' as it had already been emitted for the err key.
This results in a WTF with the bunyan CLI because the err.body is not
rendered.
If you need the old behaviour back you will need to do this:
var bunyan = require('bunyan');
var errSkips = {
// Skip domain keys. `domain` especially can have huge objects that can
// OOM your app when trying to JSON.stringify.
domain: true,
domain_emitter: true,
domain_bound: true,
domain_thrown: true
};
bunyan.stdSerializers.err = function err(err) {
if (!err || !err.stack)
return err;
var obj = {
message: err.message,
name: err.name,
stack: getFullErrorStack(err)
}
Object.keys(err).forEach(function (k) {
if (err[k] !== undefined && !errSkips[k]) {
obj[k] = err[k];
}
});
return obj;
};
bunyan -o long is the defaultWARNING: This release introduced a bug such that all serializers are
applied to all log records even if the log record did not contain the key
for that serializer. If a logger serializer function does not handle
being given undefined, then you'll get warnings like this on stderr:
bunyan: ERROR: This should never happen. This is a bug in <https://github.com/trentm/node-bunyan> or in this application. Exception from "foo" Logger serializer: Error: ...
at Object.bunyan.createLogger.serializers.foo (.../myapp.js:20:15)
at Logger._applySerializers (.../lib/bunyan.js:644:46)
at Array.forEach (native)
at Logger._applySerializers (.../lib/bunyan.js:640:33)
...
and the following junk in written log records:
"foo":"(Error in Bunyan log "foo" serializer broke field. See stderr for details.)"
Please upgrade to bunyan 0.20.0.
Change the bunyan.stdSerializers.err serializer for errors to exclude
the "domain*" keys.
err.domain will include its assigned members which can arbitrarily large
objects that are not intended for logging.
Make the "dtrace-provider" dependency optional. I hate to do this, but
installing bunyan on Windows is made very difficult with this as a required
dep. Even though "dtrace-provider" stubs out for non-dtrace-y platforms,
without a compiler and Python around, node-gyp just falls over.
bunyan CLI to not automatically page (i.e. pipe to less)-p PID),Automatic paging support in the bunyan CLI (similar to git log et al).
IOW, bunyan will open your pager (by default less) and pipe rendered
log output through it. A main benefit of this is getting colored logs with
a pager without the pain. Before you had to explicit use --color to tell
bunyan to color output when the output was not a TTY:
bunyan foo.log --color | less -R # before
bunyan foo.log # now
Disable with the --no-pager option or the BUNYAN_NO_PAGER=1 environment
variable.
Limitations: Only supported for node >=0.8. Windows is not supported (at
least not yet).
[issue #33] Log rotation support:
var bunyan = require('bunyan');
var log = bunyan.createLogger({
name: 'myapp',
streams: [{
type: 'rotating-file',
path: '/var/log/myapp.log',
count: 7,
period: 'daily'
}]
});
Tweak to CLI default pretty output: don't special case "latency" field.
The special casing was perhaps nice, but less self-explanatory.
Before:
[2012-12-27T21:17:38.218Z] INFO: audit/45769 on myserver: handled: 200 (15ms, audit=true, bar=baz)
GET /foo
...
After:
[2012-12-27T21:17:38.218Z] INFO: audit/45769 on myserver: handled: 200 (audit=true, bar=baz, latency=15)
GET /foo
...
bunyan huge.log | head.Guards on -c CONDITION usage to attempt to be more user friendly.
Bogus JS code will result in this:
$ bunyan portal.log -c 'this.req.username==boo@foo'
bunyan: error: illegal CONDITION code: SyntaxError: Unexpected token ILLEGAL
CONDITION script:
Object.prototype.TRACE = 10;
Object.prototype.DEBUG = 20;
Object.prototype.INFO = 30;
Object.prototype.WARN = 40;
Object.prototype.ERROR = 50;
Object.prototype.FATAL = 60;
this.req.username==boo@foo
Error:
SyntaxError: Unexpected token ILLEGAL
at new Script (vm.js:32:12)
at Function.Script.createScript (vm.js:48:10)
at parseArgv (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:465:27)
at main (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1252:16)
at Object.<anonymous> (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1330:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
And all CONDITION scripts will be run against a minimal valid Bunyan
log record to ensure they properly guard against undefined values
(at least as much as can reasonably be checked). For example:
$ bunyan portal.log -c 'this.req.username=="bob"'
bunyan: error: CONDITION code cannot safely filter a minimal Bunyan log record
CONDITION script:
Object.prototype.TRACE = 10;
Object.prototype.DEBUG = 20;
Object.prototype.INFO = 30;
Object.prototype.WARN = 40;
Object.prototype.ERROR = 50;
Object.prototype.FATAL = 60;
this.req.username=="bob"
Minimal Bunyan log record:
{
"v": 0,
"level": 30,
"name": "name",
"hostname": "hostname",
"pid": 123,
"time": 1355514346206,
"msg": "msg"
}
Filter error:
TypeError: Cannot read property 'username' of undefined
at bunyan-condition-0:7:9
at Script.Object.keys.forEach.(anonymous function) [as runInNewContext] (vm.js:41:22)
at parseArgv (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:477:18)
at main (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1252:16)
at Object.<anonymous> (/Users/trentm/tm/node-bunyan-0.x/bin/bunyan:1330:3)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:492:10)
A proper way to do that condition would be:
$ bunyan portal.log -c 'this.req && this.req.username=="bob"'
[issue #56] Support bunyan -p NAME to dtrace all PIDs matching 'NAME' in
their command and args (using ps -A -o pid,command | grep NAME or, on SunOS
pgrep -lf NAME). E.g.:
bunyan -p myappname
This is useful for usage of node's cluster
module where you'll
have multiple worker processes.
bunyan -p '*' to capture bunyan dtrace probes from all processes.BUNYAN_NO_COLOR environment variable to--color--no-color options.bunyan -p PID) gets through. There had been a racebunyan -p PID)pipe usage wasn't working on SmartOS. This is importantbunyan -p PID) isAdd bunyan -p PID support. This is a convenience wrapper that effectively
calls:
dtrace -x strsize=4k -qn 'bunyan$PID:::log-*{printf("%s", copyinstr(arg0))}' | bunyan
issue #48: Dtrace support! The elevator pitch is you can watch all logging
from all Bunyan-using process with something like this:
dtrace -x strsize=4k -qn 'bunyan*:::log-*{printf("%d: %s: %s", pid, probefunc, copyinstr(arg0))}'
And this can include log levels below what the service is actually configured
to log. E.g. if the service is only logging at INFO level and you need to see
DEBUG log messages, with this you can. Obviously this only works on dtrace-y
platforms: Illumos derivatives of SunOS (e.g. SmartOS, OmniOS), Mac, FreeBSD.
Or get the bunyan CLI to render logs nicely:
dtrace -x strsize=4k -qn 'bunyan*:::log-*{printf("%s", copyinstr(arg0))}' | bunyan
See https://github.com/trentm/node-bunyan#dtrace-support for details. By
Bryan Cantrill.
Export bunyan.safeCycles(). This may be useful for custom type == "raw"
streams that may do JSON stringification of log records themselves. Usage:
var str = JSON.stringify(rec, bunyan.safeCycles());
[issue #49] Allow a log.child() to specify the level of inherited streams.
For example:
# Before
var childLog = log.child({...});
childLog.level('debug');
# After
var childLog = log.child({..., level: 'debug'});
Improve the Bunyan CLI crash message to make it easier to provide relevant
details in a bug report.
Fix a bug in the long-stack-trace error serialization added in 0.14.4. The
symptom:
bunyan@0.14.4: .../node_modules/bunyan/lib/bunyan.js:1002
var ret = ex.stack || ex.toString();
^
TypeError: Cannot read property 'stack' of undefined
at getFullErrorStack (.../node_modules/bunyan/lib/bunyan.js:1002:15)
...
Improve error serialization to walk the chain of .cause() errors
from the likes of WError or VError error classes from
verror and
restify v2.0. Example:
[2012-10-11T00:30:21.871Z] ERROR: imgapi/99612 on 0525989e-2086-4270-b960-41dd661ebd7d: my-message
ValidationFailedError: my-message; caused by TypeError: cause-error-message
at Server.apiPing (/opt/smartdc/imgapi/lib/app.js:45:23)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server.setupReq (/opt/smartdc/imgapi/lib/app.js:178:9)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server.parseBody (/opt/smartdc/imgapi/node_modules/restify/lib/plugins/body_parser.js:15:33)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server.parseQueryString (/opt/smartdc/imgapi/node_modules/restify/lib/plugins/query.js:40:25)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server._run (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:579:17)
at Server._handle.log.trace.req (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:480:38)
Caused by: TypeError: cause-error-message
at Server.apiPing (/opt/smartdc/imgapi/lib/app.js:40:25)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server.setupReq (/opt/smartdc/imgapi/lib/app.js:178:9)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server.parseBody (/opt/smartdc/imgapi/node_modules/restify/lib/plugins/body_parser.js:15:33)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server.parseQueryString (/opt/smartdc/imgapi/node_modules/restify/lib/plugins/query.js:40:25)
at next (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:550:50)
at Server._run (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:579:17)
at Server._handle.log.trace.req (/opt/smartdc/imgapi/node_modules/restify/lib/server.js:480:38)
bunyan CLI output of a res.body that is anreq.body.JSON.stringifying of emitted log records to avoid blowingclient_req handling in the default outputbunyan CLI.bunyan CLI output of a req.body that is anExport bunyan.resolveLevel(NAME-OR-NUM) to resolve a level name or number
to its log level number value:
> bunyan.resolveLevel('INFO')
30
> bunyan.resolveLevel('debug')
20
A side-effect of this change is that the uppercase level name is now allowed
in the logger constructor.
log.info(BUFFER), where BUFFER isreq.body, res.body and other request/response fieldsbunyan CLI (mostly by Rob Gulewich).[issue #31] Re-instate defines for the (uppercase) log level names (TRACE,
DEBUG, etc.) in bunyan -c "..." filtering condition code. E.g.:
$ ... | bunyan -c 'level >= ERROR'
[pull #32] bunyan -o short for more concise output (by Dave Pacheco). E.g.:
22:56:52.856Z INFO myservice: My message
instead of:
[2012-02-08T22:56:52.856Z] INFO: myservice/123 on example.com: My message
bunyan CLI to suppress all but legal Bunyan JSONbunyan CLI.bunyan -c "..."Add defines for the (uppercase) log level names (TRACE, DEBUG, etc.) in
bunyan -c "..." filtering condition code. E.g.:
$ ... | bunyan -c 'level >= ERROR'
[pull #29] Add -l/--level for level filtering, and -c/--condition for
arbitrary conditional filtering (by github.com/isaacs):
$ ... | bunyan -l error # filter out log records below error
$ ... | bunyan -l 50 # numeric value works too
$ ... | bunyan -c 'level===50' # equiv with -c filtering
$ ... | bunyan -c 'pid===123' # filter on any field
$ ... | bunyan -c 'pid===123' -c '_audit' # multiple filters
[pull #24] Support for gzip'ed log files in the bunyan CLI (by
github.com/mhart):
$ bunyan foo.log.gz
...
[pull #16] Bullet proof the bunyan.stdSerializers (by github.com/rlidwka).
[pull #15] The bunyan CLI will now chronologically merge multiple log
streams when it is given multiple file arguments. (by github.com/davepacheco)
$ bunyan foo.log bar.log
... merged log records ...
[pull #15] A new bunyan.RingBuffer stream class that is useful for
keeping the last N log messages in memory. This can be a fast way to keep
recent, and thus hopefully relevant, log messages. (by @dapsays,
github.com/davepacheco)
Potential uses: Live debugging if a running process could inspect those
messages. One could dump recent log messages at a finer log level than is
typically logged on
uncaughtException.
var ringbuffer = new bunyan.RingBuffer({ limit: 100 });
var log = new bunyan({
name: 'foo',
streams: [{
type: 'raw',
stream: ringbuffer,
level: 'debug'
}]
});
log.info('hello world');
console.log(ringbuffer.records);
Add support for "raw" streams. This is a logging stream that is given
raw log record objects instead of a JSON-stringified string.
function Collector() {
this.records = [];
}
Collector.prototype.write = function (rec) {
this.records.push(rec);
}
var log = new Logger({
name: 'mylog',
streams: [{
type: 'raw',
stream: new Collector()
}]
});
See "examples/raw-stream.js". I expect raw streams to be useful for
piping Bunyan logging to separate services (e.g. http://www.loggly.com/,
https://github.com/etsy/statsd) or to separate in-process handling.
[pull #21] Bunyan loggers now re-emit fs.createWriteStream error events.
By github.com/EvanOxfeld. See "examples/handle-fs-error.js" and
"test/error-event.js" for details.
var log = new Logger({name: 'mylog', streams: [{path: FILENAME}]});
log.on('error', function (err, stream) {
// Handle error writing to or creating FILENAME.
});
jsstyle'ing (via make check)
bunyan.createLogger(OPTIONS) form, as is more typical inChange bunyan CLI default output to color "src" info red. Before the "src"
information was uncolored. The "src" info is the filename, line number and
function name resulting from using src: true in Logger creation. I.e.,
the (/Users/trentm/tm/node-bunyan/examples/hi.js:10) in:
[2012-04-10T22:28:58.237Z] INFO: myapp/39339 on banana.local (/Users/trentm/tm/node-bunyan/examples/hi.js:10): hi
Tweak bunyan CLI default output to still show an "err" field if it doesn't
have a "stack" attribute.
log.child({...}, true); where the added child fields wouldtrue argument). A side-effect of fixing this is thatlog.child,bunyan CLI taking log file path args, bunyan foo.log,cat foo.log | bunyan.bunyan CLI.bunyan CLI tool (for the default output mode/style).cat my.log | bunyan --color | less -R. Use --no-color tolog.info() -> boolean to work properly. Previous all wereAllow an optional msg and arguments to the log.info(<Error> err) logging
form. For example, before:
log.debug(my_error_instance) // good
log.debug(my_error_instance, "boom!") // wasn't allowed
Now the latter is allowed if you want to expliciting set the log msg. Of course
this applies to all the log.{trace|debug|info...}() methods.
bunyan cli output: clarify extra fields with quoting if empty or have
spaces. E.g. 'cmd' and 'stderr' in the following:
[2012-02-12T00:30:43.736Z] INFO: mo-docs/43194 on banana.local: buildDocs results (req_id=185edca2-2886-43dc-911c-fe41c09ec0f5, route=PutDocset, error=null, stderr="", cmd="make docs")
bunyan CLIbunyan CLI default output to include all log record keys. Unknown keysnew Logger(...) and log.child(...)[issue #2] Add guard on JSON.stringifying of log records before emission.
This will prevent log.info et al throwing on record fields that cannot be
represented as JSON. An error will be printed on stderr and a clipped log
record emitted with a 'bunyanMsg' key including error details. E.g.:
bunyan: ERROR: could not stringify log record from /Users/trentm/tm/node-bunyan/examples/unstringifyable.js:12: TypeError: Converting circular structure to JSON
{
"name": "foo",
"hostname": "banana.local",
"bunyanMsg": "bunyan: ERROR: could not stringify log record from /Users/trentm/tm/node-bunyan/examples/unstringifyable.js:12: TypeError: Converting circular structure to JSON",
...
Some timing shows this does effect log speed:
$ node tools/timeguard.js # before
Time try/catch-guard on JSON.stringify:
- log.info: 0.07365ms per iteration
$ node tools/timeguard.js # after
Time try/catch-guard on JSON.stringify:
- log.info: 0.07368ms per iteration
log.level(...) and log.levels(...) API for changing logger streamTRACE|DEBUG|INFO|WARN|ERROR|FATAL level constants to exports.Add log.info(err) special case for logging an Error instance. For
example log.info(new TypeError("boom") will produce:
...
"err": {
"message": "boom",
"name": "TypeError",
"stack": "TypeError: boom\n at Object.<anonymous> ..."
},
"msg": "boom",
...
Add new Logger({src: true}) config option to have a 'src' attribute be
automatically added to log records with the log call source info. Example:
"src": {
"file": "/Users/trentm/tm/node-bunyan/examples/src.js",
"line": 20,
"func": "Wuzzle.woos"
},
log.child(options[, simple]) Added simple boolean arg. Set true tolog.clone -> log.child to better reflect the relationship: streams andlog.child usageLogger.stdSerializers.err serializer which is necessary to get goodLOG_VERSION to exports.First release.