317 lines
54 KiB
JSON
317 lines
54 KiB
JSON
{
|
|
"// dtrace-provider": "required for dtrace features",
|
|
"// moment": "required for local time with CLI",
|
|
"// mv": "required for RotatingFileStream",
|
|
"_args": [
|
|
[
|
|
{
|
|
"raw": "@expo/bunyan@1.8.10",
|
|
"scope": "@expo",
|
|
"escapedName": "@expo%2fbunyan",
|
|
"name": "@expo/bunyan",
|
|
"rawSpec": "1.8.10",
|
|
"spec": "1.8.10",
|
|
"type": "version"
|
|
},
|
|
"/Volumes/2009-SSD/GT2/GT2-iOS/node_modules/react-native-scripts"
|
|
]
|
|
],
|
|
"_from": "@expo/bunyan@1.8.10",
|
|
"_id": "@expo/bunyan@1.8.10",
|
|
"_inCache": true,
|
|
"_location": "/@expo/bunyan",
|
|
"_nodeVersion": "8.0.0",
|
|
"_npmOperationalInternal": {
|
|
"host": "s3://npm-registry-packages",
|
|
"tmp": "tmp/bunyan-1.8.10.tgz_1498866056673_0.21135162212885916"
|
|
},
|
|
"_npmUser": {
|
|
"name": "ccheever",
|
|
"email": "ccheever@gmail.com"
|
|
},
|
|
"_npmVersion": "4.2.0",
|
|
"_phantomChildren": {},
|
|
"_requested": {
|
|
"raw": "@expo/bunyan@1.8.10",
|
|
"scope": "@expo",
|
|
"escapedName": "@expo%2fbunyan",
|
|
"name": "@expo/bunyan",
|
|
"rawSpec": "1.8.10",
|
|
"spec": "1.8.10",
|
|
"type": "version"
|
|
},
|
|
"_requiredBy": [
|
|
"/react-native-scripts",
|
|
"/xdl"
|
|
],
|
|
"_resolved": "https://registry.npmjs.org/@expo/bunyan/-/bunyan-1.8.10.tgz",
|
|
"_shasum": "7d19354a6bce85aae5fea0e973569d3f0142533e",
|
|
"_shrinkwrap": null,
|
|
"_spec": "@expo/bunyan@1.8.10",
|
|
"_where": "/Volumes/2009-SSD/GT2/GT2-iOS/node_modules/react-native-scripts",
|
|
"author": {
|
|
"name": "Trent Mick",
|
|
"email": "trentm@gmail.com",
|
|
"url": "http://trentm.com"
|
|
},
|
|
"bin": {
|
|
"bunyan": "./bin/bunyan"
|
|
},
|
|
"bugs": {
|
|
"url": "https://github.com/trentm/node-bunyan/issues"
|
|
},
|
|
"contributors": [
|
|
{
|
|
"name": "Trent Mick",
|
|
"url": "http://trentm.com"
|
|
},
|
|
{
|
|
"name": "Mark Cavage",
|
|
"url": "https://github.com/mcavage"
|
|
},
|
|
{
|
|
"name": "Dave Pacheco",
|
|
"url": "https://github.com/davepacheco"
|
|
},
|
|
{
|
|
"name": "Michael Hart",
|
|
"url": "https://github.com/mhart"
|
|
},
|
|
{
|
|
"name": "Isaac Schlueter",
|
|
"url": "https://github.com/isaacs"
|
|
},
|
|
{
|
|
"name": "Rob Gulewich",
|
|
"url": "https://github.com/rgulewich"
|
|
},
|
|
{
|
|
"name": "Bryan Cantrill",
|
|
"url": "https://github.com/bcantrill"
|
|
},
|
|
{
|
|
"name": "Michael Hart",
|
|
"url": "https://github.com/mhart"
|
|
},
|
|
{
|
|
"name": "Simon Wade",
|
|
"url": "https://github.com/aexmachina"
|
|
},
|
|
{
|
|
"name": "https://github.com/glenn-murray-bse"
|
|
},
|
|
{
|
|
"name": "Chakrit Wichian",
|
|
"url": "https://github.com/chakrit"
|
|
},
|
|
{
|
|
"name": "Patrick Mooney",
|
|
"url": "https://github.com/pfmooney"
|
|
},
|
|
{
|
|
"name": "Johan Nordberg",
|
|
"url": "https://github.com/jnordberg"
|
|
},
|
|
{
|
|
"name": "https://github.com/timborodin"
|
|
},
|
|
{
|
|
"name": "Ryan Graham",
|
|
"url": "https://github.com/rmg"
|
|
},
|
|
{
|
|
"name": "Alex Kocharin",
|
|
"url": "https://github.com/rlidwka"
|
|
},
|
|
{
|
|
"name": "Andrei Neculau",
|
|
"url": "https://github.com/andreineculau"
|
|
},
|
|
{
|
|
"name": "Mihai Tomescu",
|
|
"url": "https://github.com/matomesc"
|
|
},
|
|
{
|
|
"name": "Daniel Juhl",
|
|
"url": "https://github.com/danieljuhl"
|
|
},
|
|
{
|
|
"name": "Chris Barber",
|
|
"url": "https://github.com/cb1kenobi"
|
|
},
|
|
{
|
|
"name": "Manuel Schneider",
|
|
"url": "https://github.com/manuelschneider"
|
|
},
|
|
{
|
|
"name": "Martin Gausby",
|
|
"url": "https://github.com/gausby"
|
|
},
|
|
{
|
|
"name": "Stéphan Kochen",
|
|
"url": "https://github.com/stephank"
|
|
},
|
|
{
|
|
"name": "Shakeel Mohamed",
|
|
"url": "https://github.com/shakeelmohamed"
|
|
},
|
|
{
|
|
"name": "Denis Izmaylov",
|
|
"url": "https://github.com/DenisIzmaylov"
|
|
},
|
|
{
|
|
"name": "Guillermo Grau Panea",
|
|
"url": "https://github.com/guigrpa"
|
|
},
|
|
{
|
|
"name": "Mark LeMerise",
|
|
"url": "https://github.com/MarkLeMerise"
|
|
},
|
|
{
|
|
"name": "https://github.com/sometimesalready"
|
|
},
|
|
{
|
|
"name": "Charly Koza",
|
|
"url": "https://github.com/Cactusbone"
|
|
},
|
|
{
|
|
"name": "Thomas Heymann",
|
|
"url": "https://github.com/cyberthom"
|
|
},
|
|
{
|
|
"name": "David M. Lee",
|
|
"url": "https://github.com/leedm777"
|
|
},
|
|
{
|
|
"name": "Marc Udoff",
|
|
"url": "https://github.com/mlucool"
|
|
},
|
|
{
|
|
"name": "Mark Stosberg",
|
|
"url": "https://github.com/markstos"
|
|
},
|
|
{
|
|
"name": "Alexander Ray",
|
|
"url": "https://github.com/aray12"
|
|
},
|
|
{
|
|
"name": "Adam Lynch",
|
|
"url": "https://github.com/adam-lynch"
|
|
},
|
|
{
|
|
"name": "Michael Nisi",
|
|
"url": "https://github.com/michaelnisi"
|
|
},
|
|
{
|
|
"name": "Martijn Schrage",
|
|
"url": "https://github.com/Oblosys"
|
|
},
|
|
{
|
|
"name": "Paul Milham",
|
|
"url": "https://github.com/domrein"
|
|
},
|
|
{
|
|
"name": "Frankie O'Rourke",
|
|
"url": "https://github.com/psfrankie"
|
|
},
|
|
{
|
|
"name": "Cody Mello",
|
|
"url": "https://github.com/melloc"
|
|
},
|
|
{
|
|
"name": "Todd Whiteman",
|
|
"url": "https://github.com/twhiteman"
|
|
},
|
|
{
|
|
"name": "Zach Bjornson",
|
|
"url": "https://github.com/zbjornson"
|
|
}
|
|
],
|
|
"dependencies": {
|
|
"moment": "^2.10.6",
|
|
"mv": "~2",
|
|
"safe-json-stringify": "~1"
|
|
},
|
|
"description": "a JSON logging library for node.js services, now without d-trace",
|
|
"devDependencies": {
|
|
"ben": "0.0.0",
|
|
"markdown-toc": "0.12.x",
|
|
"nodeunit": "0.9",
|
|
"vasync": "1.4.3",
|
|
"verror": "1.3.3"
|
|
},
|
|
"directories": {},
|
|
"dist": {
|
|
"shasum": "7d19354a6bce85aae5fea0e973569d3f0142533e",
|
|
"tarball": "https://registry.npmjs.org/@expo/bunyan/-/bunyan-1.8.10.tgz"
|
|
},
|
|
"engines": [
|
|
"node >=0.10.0"
|
|
],
|
|
"gitHead": "456b6ebaa3c5e7ab7fbc0ff998b29e7cfcb0cee9",
|
|
"homepage": "https://github.com/trentm/node-bunyan#readme",
|
|
"keywords": [
|
|
"log",
|
|
"logging",
|
|
"log4j",
|
|
"json",
|
|
"bunyan"
|
|
],
|
|
"license": "MIT",
|
|
"main": "./lib/bunyan.js",
|
|
"maintainers": [
|
|
{
|
|
"name": "jesseruder",
|
|
"email": "jesse@sixfivezero.net"
|
|
},
|
|
{
|
|
"name": "terribleben",
|
|
"email": "ben@exp.host"
|
|
},
|
|
{
|
|
"name": "ccheever",
|
|
"email": "ccheever@gmail.com"
|
|
},
|
|
{
|
|
"name": "dikaiosune",
|
|
"email": "adam.n.perry@gmail.com"
|
|
},
|
|
{
|
|
"name": "nikki93",
|
|
"email": "s.nikhilesh@gmail.com"
|
|
},
|
|
{
|
|
"name": "brentvatne",
|
|
"email": "brentvatne@gmail.com"
|
|
},
|
|
{
|
|
"name": "skevy",
|
|
"email": "adam@sk3vy.com"
|
|
},
|
|
{
|
|
"name": "ide",
|
|
"email": "ide+npm@jameside.com"
|
|
},
|
|
{
|
|
"name": "expoadmin",
|
|
"email": "exponent.team@gmail.com"
|
|
}
|
|
],
|
|
"name": "@expo/bunyan",
|
|
"optionalDependencies": {
|
|
"moment": "^2.10.6",
|
|
"mv": "~2",
|
|
"safe-json-stringify": "~1"
|
|
},
|
|
"readme": "[](https://www.npmjs.com/package/bunyan)\n[](https://travis-ci.org/trentm/node-bunyan)\n\nBunyan is **a simple and fast JSON logging library** for node.js services:\n\n```js\nvar bunyan = require('bunyan');\nvar log = bunyan.createLogger({name: \"myapp\"});\nlog.info(\"hi\");\n```\n\nand **a `bunyan` CLI tool** for nicely viewing those logs:\n\n\n\nManifesto: Server logs should be structured. JSON's a good format. Let's do\nthat. A log record is one line of `JSON.stringify`'d output. Let's also\nspecify some common names for the requisite and common fields for a log\nrecord (see below).\n\n\n## Table of Contents\n\n<!-- toc -->\n\n- [Current Status](#current-status)\n- [Installation](#installation)\n- [Features](#features)\n- [Introduction](#introduction)\n * [Constructor API](#constructor-api)\n * [Log Method API](#log-method-api)\n * [CLI Usage](#cli-usage)\n * [Streams Introduction](#streams-introduction)\n * [log.child](#logchild)\n * [Serializers](#serializers)\n + [Requirements for serializers functions](#requirements-for-serializers-functions)\n + [Standard Serializers](#standard-serializers)\n * [src](#src)\n- [Levels](#levels)\n * [Level suggestions](#level-suggestions)\n- [Log Record Fields](#log-record-fields)\n * [Core fields](#core-fields)\n * [Recommended/Best Practice Fields](#recommendedbest-practice-fields)\n * [Other fields to consider](#other-fields-to-consider)\n- [Streams](#streams)\n * [Adding a Stream](#adding-a-stream)\n * [stream errors](#stream-errors)\n * [stream type: `stream`](#stream-type-stream)\n * [stream type: `file`](#stream-type-file)\n * [stream type: `rotating-file`](#stream-type-rotating-file)\n * [stream type: `raw`](#stream-type-raw)\n * [`raw` + RingBuffer Stream](#raw--ringbuffer-stream)\n * [third-party streams](#third-party-streams)\n- [Runtime log snooping via DTrace](#runtime-log-snooping-via-dtrace)\n * [DTrace examples](#dtrace-examples)\n- [Runtime environments](#runtime-environments)\n * [Browserify](#browserify)\n * [Webpack](#webpack)\n- [Versioning](#versioning)\n- [License](#license)\n- [See Also](#see-also)\n\n<!-- tocstop -->\n\n# Current Status\n\nSolid core functionality is there. Joyent is using this for a number of\nproduction services. Bunyan supports node 0.10 and greater. Follow\n<a href=\"https://twitter.com/intent/user?screen_name=trentmick\" target=\"_blank\">@trentmick</a>\nfor updates to Bunyan.\n\nThere is an email discussion list\n[bunyan-logging@googlegroups.com](mailto:bunyan-logging@googlegroups.com),\nalso [as a forum in the\nbrowser](https://groups.google.com/forum/?fromgroups#!forum/bunyan-logging).\n\n\n# Installation\n\n```sh\nnpm install bunyan\n```\n\n**Tip**: The `bunyan` CLI tool is written to be compatible (within reason) with\nall versions of Bunyan logs. Therefore you might want to `npm install -g bunyan`\nto get the bunyan CLI on your PATH, then use local bunyan installs for\nnode.js library usage of bunyan in your apps.\n\n\n# Features\n\n- elegant [log method API](#log-method-api)\n- extensible [streams](#streams) system for controlling where log records\n go (to a stream, to a file, [log file rotation](#stream-type-rotating-file),\n etc.)\n- [`bunyan` CLI](#cli-usage) for pretty-printing and filtering of Bunyan logs\n- simple include of log call source location (file, line, function) with\n [`src: true`](#src)\n- lightweight specialization of Logger instances with [`log.child`](#logchild)\n- custom rendering of logged objects with [\"serializers\"](#serializers)\n- [Runtime log snooping via DTrace support](#runtime-log-snooping-via-dtrace)\n- Support for a few [runtime environments](#runtime-environments): Node.js,\n [Browserify](http://browserify.org/), [Webpack](https://webpack.github.io/), [NW.js](http://nwjs.io/).\n\n\n# Introduction\n\nLike most logging libraries you create a Logger instance and call methods\nnamed after the logging levels:\n\n```js\n// hi.js\nvar bunyan = require('bunyan');\nvar log = bunyan.createLogger({name: 'myapp'});\nlog.info('hi');\nlog.warn({lang: 'fr'}, 'au revoir');\n```\n\nAll loggers must provide a \"name\". This is somewhat akin to the log4j logger\n\"name\", but Bunyan doesn't do hierarchical logger names.\n\n**Bunyan log records are JSON.** A few fields are added automatically:\n\"pid\", \"hostname\", \"time\" and \"v\".\n\n```sh\n$ node hi.js\n{\"name\":\"myapp\",\"hostname\":\"banana.local\",\"pid\":40161,\"level\":30,\"msg\":\"hi\",\"time\":\"2013-01-04T18:46:23.851Z\",\"v\":0}\n{\"name\":\"myapp\",\"hostname\":\"banana.local\",\"pid\":40161,\"level\":40,\"lang\":\"fr\",\"msg\":\"au revoir\",\"time\":\"2013-01-04T18:46:23.853Z\",\"v\":0}\n```\n\n\n## Constructor API\n\n```js\nvar bunyan = require('bunyan');\nvar log = bunyan.createLogger({\n name: <string>, // Required\n level: <level name or number>, // Optional, see \"Levels\" section\n stream: <node.js stream>, // Optional, see \"Streams\" section\n streams: [<bunyan streams>, ...], // Optional, see \"Streams\" section\n serializers: <serializers mapping>, // Optional, see \"Serializers\" section\n src: <boolean>, // Optional, see \"src\" section\n\n // Any other fields are added to all log records as is.\n foo: 'bar',\n ...\n});\n```\n\n\n## Log Method API\n\nThe example above shows two different ways to call `log.info(...)`. The\nfull API is:\n\n```js\nlog.info(); // Returns a boolean: is the \"info\" level enabled?\n // This is equivalent to `log.isInfoEnabled()` or\n // `log.isEnabledFor(INFO)` in log4j.\n\nlog.info('hi'); // Log a simple string message (or number).\nlog.info('hi %s', bob, anotherVar); // Uses `util.format` for msg formatting.\n\nlog.info({foo: 'bar'}, 'hi');\n // The first field can optionally be a \"fields\" object, which\n // is merged into the log record.\n\nlog.info(err); // Special case to log an `Error` instance to the record.\n // This adds an \"err\" field with exception details\n // (including the stack) and sets \"msg\" to the exception\n // message.\nlog.info(err, 'more on this: %s', more);\n // ... or you can specify the \"msg\".\n\nlog.info({foo: 'bar', err: err}, 'some msg about this error');\n // To pass in an Error *and* other fields, use the `err`\n // field name for the Error instance.\n```\n\nNote that this implies **you cannot blindly pass any object as the first\nargument to log it** because that object might include fields that collide with\nBunyan's [core record fields](#core-fields). In other words,\n`log.info(mywidget)` may not yield what you expect. Instead of a string\nrepresentation of `mywidget` that other logging libraries may give you, Bunyan\nwill try to JSON-ify your object. It is a Bunyan best practice to always give a\nfield name to included objects, e.g.:\n\n```js\nlog.info({widget: mywidget}, ...)\n```\n\nThis will dove-tail with [Bunyan serializer support](#serializers), discussed\nlater.\n\nThe same goes for all of Bunyan's log levels: `log.trace`, `log.debug`,\n`log.info`, `log.warn`, `log.error`, and `log.fatal`. See the [levels\nsection](#levels) below for details and suggestions.\n\n\n## CLI Usage\n\nBunyan log output is a stream of JSON objects. This is great for processing,\nbut not for reading directly. A **`bunyan` tool** is provided **for\npretty-printing bunyan logs** and for **filtering** (e.g.\n`| bunyan -c 'this.foo == \"bar\"'`). Using our example above:\n\n```sh\n$ node hi.js | ./node_modules/.bin/bunyan\n[2013-01-04T19:01:18.241Z] INFO: myapp/40208 on banana.local: hi\n[2013-01-04T19:01:18.242Z] WARN: myapp/40208 on banana.local: au revoir (lang=fr)\n```\n\nSee the screenshot above for an example of the default coloring of rendered\nlog output. That example also shows the nice formatting automatically done for\nsome well-known log record fields (e.g. `req` is formatted like an HTTP request,\n`res` like an HTTP response, `err` like an error stack trace).\n\nOne interesting feature is **filtering** of log content, which can be useful\nfor digging through large log files or for analysis. We can filter only\nrecords above a certain level:\n\n```sh\n$ node hi.js | bunyan -l warn\n[2013-01-04T19:08:37.182Z] WARN: myapp/40353 on banana.local: au revoir (lang=fr)\n```\n\nOr filter on the JSON fields in the records (e.g. only showing the French\nrecords in our contrived example):\n\n```sh\n$ node hi.js | bunyan -c 'this.lang == \"fr\"'\n[2013-01-04T19:08:26.411Z] WARN: myapp/40342 on banana.local: au revoir (lang=fr)\n```\n\nSee `bunyan --help` for other facilities.\n\n\n## Streams Introduction\n\nBy default, log output is to stdout and at the \"info\" level. Explicitly that\nlooks like:\n\n```js\nvar log = bunyan.createLogger({\n name: 'myapp',\n stream: process.stdout,\n level: 'info'\n});\n```\n\nThat is an abbreviated form for a single stream. **You can define multiple\nstreams at different levels**.\n\n```js\nvar log = bunyan.createLogger({\n name: 'myapp',\n streams: [\n {\n level: 'info',\n stream: process.stdout // log INFO and above to stdout\n },\n {\n level: 'error',\n path: '/var/tmp/myapp-error.log' // log ERROR and above to a file\n }\n ]\n});\n```\n\nMore on streams in the [Streams section](#streams) below.\n\n## log.child\n\nBunyan has a concept of a child logger to **specialize a logger for a\nsub-component of your application**, i.e. to create a new logger with\nadditional bound fields that will be included in its log records. A child\nlogger is created with `log.child(...)`.\n\nIn the following example, logging on a \"Wuzzle\" instance's `this.log` will\nbe exactly as on the parent logger with the addition of the `widget_type`\nfield:\n\n```js\nvar bunyan = require('bunyan');\nvar log = bunyan.createLogger({name: 'myapp'});\n\nfunction Wuzzle(options) {\n this.log = options.log.child({widget_type: 'wuzzle'});\n this.log.info('creating a wuzzle')\n}\nWuzzle.prototype.woos = function () {\n this.log.warn('This wuzzle is woosey.')\n}\n\nlog.info('start');\nvar wuzzle = new Wuzzle({log: log});\nwuzzle.woos();\nlog.info('done');\n```\n\nRunning that looks like (raw):\n\n```sh\n$ node myapp.js\n{\"name\":\"myapp\",\"hostname\":\"myhost\",\"pid\":34572,\"level\":30,\"msg\":\"start\",\"time\":\"2013-01-04T07:47:25.814Z\",\"v\":0}\n{\"name\":\"myapp\",\"hostname\":\"myhost\",\"pid\":34572,\"widget_type\":\"wuzzle\",\"level\":30,\"msg\":\"creating a wuzzle\",\"time\":\"2013-01-04T07:47:25.815Z\",\"v\":0}\n{\"name\":\"myapp\",\"hostname\":\"myhost\",\"pid\":34572,\"widget_type\":\"wuzzle\",\"level\":40,\"msg\":\"This wuzzle is woosey.\",\"time\":\"2013-01-04T07:47:25.815Z\",\"v\":0}\n{\"name\":\"myapp\",\"hostname\":\"myhost\",\"pid\":34572,\"level\":30,\"msg\":\"done\",\"time\":\"2013-01-04T07:47:25.816Z\",\"v\":0}\n```\n\nAnd with the `bunyan` CLI (using the \"short\" output mode):\n\n```sh\n$ node myapp.js | bunyan -o short\n07:46:42.707Z INFO myapp: start\n07:46:42.709Z INFO myapp: creating a wuzzle (widget_type=wuzzle)\n07:46:42.709Z WARN myapp: This wuzzle is woosey. (widget_type=wuzzle)\n07:46:42.709Z INFO myapp: done\n```\n\nA more practical example is in the\n[node-restify](https://github.com/mcavage/node-restify) web framework.\nRestify uses Bunyan for its logging. One feature of its integration, is that\nif `server.use(restify.requestLogger())` is used, each restify request handler\nincludes a `req.log` logger that is:\n\n```js\nlog.child({req_id: <unique request id>}, true)\n```\n\nApps using restify can then use `req.log` and have all such log records\ninclude the unique request id (as \"req\\_id\"). Handy.\n\n\n## Serializers\n\nBunyan has a concept of **\"serializer\" functions to produce a JSON-able object\nfrom a JavaScript object**, so you can easily do the following:\n\n```js\nlog.info({req: <request object>}, 'something about handling this request');\n```\n\nand have the `req` entry in the log record be just a reasonable subset of\n`<request object>` fields (or computed data about those fields).\n\n\nA logger instance can have a `serializers` mapping of log record field name\n(\"req\" in this example) to a serializer function. When creating the log\nrecord, Bunyan will call the serializer function for fields of that name.\nAn example:\n\n```js\nfunction reqSerializer(req) {\n return {\n method: req.method,\n url: req.url,\n headers: req.headers\n };\n}\nvar log = bunyan.createLogger({\n name: 'myapp',\n serializers: {\n req: reqSerializer\n }\n});\n```\n\n\nTypically serializers are added to a logger at creation time via\n`bunyan.createLogger({..., serializers: <serializers>})`. However, serializers\ncan be added after creation via `<logger>.addSerializers(...)`, e.g.:\n\n```js\nvar log = bunyan.createLogger({name: 'myapp'});\nlog.addSerializers({req: reqSerializer});\n```\n\n### Requirements for serializers functions\n\nA serializer function is passed unprotected objects that are passed to the\n`log.info`, `log.debug`, etc. call. This means a poorly written serializer\nfunction can case side-effects. Logging shouldn't do that. Here are a few\nrules and best practices for serializer functions:\n\n- A serializer function *should never throw*. The bunyan library *does*\n protect somewhat from this: if the serializer throws an error, then\n bunyan will (a) write an ugly message on stderr (along with the traceback),\n and (b) the field in the log record will be replace with a short error message.\n For example:\n\n ```\n bunyan: ERROR: Exception thrown from the \"foo\" Bunyan serializer. This should never happen. This is a bug in that serializer function.\n TypeError: Cannot read property 'not' of undefined\n at Object.fooSerializer [as foo] (/Users/trentm/tm/node-bunyan/bar.js:8:26)\n at /Users/trentm/tm/node-bunyan/lib/bunyan.js:873:50\n at Array.forEach (native)\n at Logger._applySerializers (/Users/trentm/tm/node-bunyan/lib/bunyan.js:865:35)\n at mkRecord (/Users/trentm/tm/node-bunyan/lib/bunyan.js:978:17)\n at Logger.info (/Users/trentm/tm/node-bunyan/lib/bunyan.js:1044:19)\n at Object.<anonymous> (/Users/trentm/tm/node-bunyan/bar.js:13:5)\n at Module._compile (module.js:409:26)\n at Object.Module._extensions..js (module.js:416:10)\n at Module.load (module.js:343:32)\n {\"name\":\"bar\",\"hostname\":\"danger0.local\",\"pid\":47411,\"level\":30,\"foo\":\"(Error in Bunyan log \\\"foo\\\" serializer broke field. See stderr for details.)\",\"msg\":\"one\",\"time\":\"2017-03-08T02:53:51.173Z\",\"v\":0}\n ```\n\n- A serializer function *should never mutate the given object*. Doing so will\n change the object in your application.\n\n- A serializer function *should be defensive*. In my experience it is common to\n set a serializer in an app, say for field name \"foo\", and then accidentally\n have a log line that passes a \"foo\" that is undefined, or null, or of some\n unexpected type. A good start at defensiveness is to start with this:\n\n ```javascript\n function fooSerializers(foo) {\n // Guard against foo be null/undefined. Check that expected fields\n // are defined.\n if (!foo || !foo.bar)\n return foo;\n var obj = {\n // Create the object to be logged.\n bar: foo.bar\n }\n return obj;\n };\n ```\n\n\n### Standard Serializers\n\nBunyan includes a small set of \"standard serializers\", exported as\n`bunyan.stdSerializers`. Their use is completely optional. Example using\nall of them:\n\n```js\nvar log = bunyan.createLogger({\n name: 'myapp',\n serializers: bunyan.stdSerializers\n});\n```\n\nor particular ones:\n\n```js\nvar log = bunyan.createLogger({\n name: 'myapp',\n serializers: {err: bunyan.stdSerializers.err}\n});\n```\n\nStandard serializers are:\n\n| Field | Description |\n| ----- | ----------- |\n| err | Used for serializing JavaScript error objects, including traversing an error's cause chain for error objects with a `.cause()` -- e.g. as from [verror](https://github.com/davepacheco/node-verror). |\n| req | Common fields from a node.js HTTP request object. |\n| res | Common fields from a node.js HTTP response object. |\n\nNote that the `req` and `res` serializers intentionally do not include the\nrequest/response *body*, as that can be prohibitively large. If helpful, the\n[restify framework's audit logger plugin](https://github.com/restify/node-restify/blob/ac13902ad9716dcb20aaa62295403983075b1841/lib/plugins/audit.js#L38-L87)\nhas its own req/res serializers that include more information (optionally\nincluding the body).\n\n\n## src\n\nThe **source file, line and function of the log call site** can be added to\nlog records by using the `src: true` config option:\n\n```js\nvar log = bunyan.createLogger({src: true, ...});\n```\n\nThis adds the call source info with the 'src' field, like this:\n\n```js\n{\n \"name\": \"src-example\",\n \"hostname\": \"banana.local\",\n \"pid\": 123,\n \"component\": \"wuzzle\",\n \"level\": 4,\n \"msg\": \"This wuzzle is woosey.\",\n \"time\": \"2012-02-06T04:19:35.605Z\",\n \"src\": {\n \"file\": \"/Users/trentm/tm/node-bunyan/examples/src.js\",\n \"line\": 20,\n \"func\": \"Wuzzle.woos\"\n },\n \"v\": 0\n}\n```\n\n**WARNING: Determining the call source info is slow. Never use this option\nin production.**\n\n\n# Levels\n\nThe log levels in bunyan are as follows. The level descriptions are best\npractice *opinions* of the author.\n\n- \"fatal\" (60): The service/app is going to stop or become unusable now.\n An operator should definitely look into this soon.\n- \"error\" (50): Fatal for a particular request, but the service/app continues\n servicing other requests. An operator should look at this soon(ish).\n- \"warn\" (40): A note on something that should probably be looked at by an\n operator eventually.\n- \"info\" (30): Detail on regular operation.\n- \"debug\" (20): Anything else, i.e. too verbose to be included in \"info\" level.\n- \"trace\" (10): Logging from external libraries used by your app or *very*\n detailed application logging.\n\nSetting a logger instance (or one of its streams) to a particular level implies\nthat all log records *at that level and above* are logged. E.g. a logger set to\nlevel \"info\" will log records at level info and above (warn, error, fatal).\n\nWhile using log level *names* is preferred, the actual level values are integers\ninternally (10 for \"trace\", ..., 60 for \"fatal\"). Constants are defined for\nthe levels: `bunyan.TRACE` ... `bunyan.FATAL`. The lowercase level names are\naliases supported in the API, e.g. `log.level(\"info\")`. There is one exception:\nDTrace integration uses the level names. The fired DTrace probes are named\n'bunyan-$levelName'.\n\nHere is the API for querying and changing levels on an existing logger.\nRecall that a logger instance has an array of output \"streams\":\n\n```js\nlog.level() -> INFO // gets current level (lowest level of all streams)\n\nlog.level(INFO) // set all streams to level INFO\nlog.level(\"info\") // set all streams to level INFO\n\nlog.levels() -> [DEBUG, INFO] // get array of levels of all streams\nlog.levels(0) -> DEBUG // get level of stream at index 0\nlog.levels(\"foo\") // get level of stream with name \"foo\"\n\nlog.levels(0, INFO) // set level of stream 0 to INFO\nlog.levels(0, \"info\") // can use \"info\" et al aliases\nlog.levels(\"foo\", WARN) // set stream named \"foo\" to WARN\n```\n\n\n## Level suggestions\n\nTrent's biased suggestions for server apps: Use \"debug\" sparingly. Information\nthat will be useful to debug errors *post mortem* should usually be included in\n\"info\" messages if it's generally relevant or else with the corresponding\n\"error\" event. Don't rely on spewing mostly irrelevant debug messages all the\ntime and sifting through them when an error occurs.\n\nTrent's biased suggestions for node.js libraries: IMHO, libraries should only\never log at `trace`-level. Fine control over log output should be up to the\napp using a library. Having a library that spews log output at higher levels\ngets in the way of a clear story in the *app* logs.\n\n\n# Log Record Fields\n\nThis section will describe *rules* for the Bunyan log format: field names,\nfield meanings, required fields, etc. However, a Bunyan library doesn't\nstrictly enforce all these rules while records are being emitted. For example,\nBunyan will add a `time` field with the correct format to your log records,\nbut you can specify your own. It is the caller's responsibility to specify\nthe appropriate format.\n\nThe reason for the above leniency is because IMO logging a message should\nnever break your app. This leads to this rule of logging: **a thrown\nexception from `log.info(...)` or equivalent (other than for calling with the\nincorrect signature) is always a bug in Bunyan.**\n\n\nA typical Bunyan log record looks like this:\n\n```js\n{\"name\":\"myserver\",\"hostname\":\"banana.local\",\"pid\":123,\"req\":{\"method\":\"GET\",\"url\":\"/path?q=1#anchor\",\"headers\":{\"x-hi\":\"Mom\",\"connection\":\"close\"}},\"level\":3,\"msg\":\"start request\",\"time\":\"2012-02-03T19:02:46.178Z\",\"v\":0}\n```\n\nPretty-printed:\n\n```js\n{\n \"name\": \"myserver\",\n \"hostname\": \"banana.local\",\n \"pid\": 123,\n \"req\": {\n \"method\": \"GET\",\n \"url\": \"/path?q=1#anchor\",\n \"headers\": {\n \"x-hi\": \"Mom\",\n \"connection\": \"close\"\n },\n \"remoteAddress\": \"120.0.0.1\",\n \"remotePort\": 51244\n },\n \"level\": 3,\n \"msg\": \"start request\",\n \"time\": \"2012-02-03T19:02:57.534Z\",\n \"v\": 0\n}\n```\n\n## Core fields\n\n- `v`: Required. Integer. Added by Bunyan. Cannot be overridden.\n This is the Bunyan log format version (`require('bunyan').LOG_VERSION`).\n The log version is a single integer. `0` is until I release a version\n \"1.0.0\" of node-bunyan. Thereafter, starting with `1`, this will be\n incremented if there is any backward incompatible change to the log record\n format. Details will be in \"CHANGES.md\" (the change log).\n- `level`: Required. Integer. Added by Bunyan. Cannot be overridden.\n See the \"Levels\" section.\n- `name`: Required. String. Provided at Logger creation.\n You must specify a name for your logger when creating it. Typically this\n is the name of the service/app using Bunyan for logging.\n- `hostname`: Required. String. Provided or determined at Logger creation.\n You can specify your hostname at Logger creation or it will be retrieved\n vi `os.hostname()`.\n- `pid`: Required. Integer. Filled in automatically at Logger creation.\n- `time`: Required. String. Added by Bunyan. Can be overridden.\n The date and time of the event in [ISO 8601\n Extended Format](http://en.wikipedia.org/wiki/ISO_8601) format and in UTC,\n as from\n [`Date.toISOString()`](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toISOString).\n- `msg`: Required. String.\n Every `log.debug(...)` et al call must provide a log message.\n- `src`: Optional. Object giving log call source info. This is added\n automatically by Bunyan if the \"src: true\" config option is given to the\n Logger. Never use in production as this is really slow.\n\n\nGo ahead and add more fields, and nested ones are fine (and recommended) as\nwell. This is why we're using JSON. Some suggestions and best practices\nfollow (feedback from actual users welcome).\n\n\n## Recommended/Best Practice Fields\n\n- `err`: Object. A caught JS exception. Log that thing with `log.info(err)`\n to get:\n\n ```js\n ...\n \"err\": {\n \"message\": \"boom\",\n \"name\": \"TypeError\",\n \"stack\": \"TypeError: boom\\n at Object.<anonymous> ...\"\n },\n \"msg\": \"boom\",\n ...\n ```\n\n Or use the `bunyan.stdSerializers.err` serializer in your Logger and\n do this `log.error({err: err}, \"oops\")`. See \"examples/err.js\".\n\n- `req_id`: String. A request identifier. Including this field in all logging\n tied to handling a particular request to your server is strongly suggested.\n This allows post analysis of logs to easily collate all related logging\n for a request. This really shines when you have a SOA with multiple services\n and you carry a single request ID from the top API down through all APIs\n (as [node-restify](https://github.com/mcavage/node-restify) facilitates\n with its 'Request-Id' header).\n\n- `req`: An HTTP server request. Bunyan provides `bunyan.stdSerializers.req`\n to serialize a request with a suggested set of keys. Example:\n\n ```js\n {\n \"method\": \"GET\",\n \"url\": \"/path?q=1#anchor\",\n \"headers\": {\n \"x-hi\": \"Mom\",\n \"connection\": \"close\"\n },\n \"remoteAddress\": \"120.0.0.1\",\n \"remotePort\": 51244\n }\n ```\n\n- `res`: An HTTP server response. Bunyan provides `bunyan.stdSerializers.res`\n to serialize a response with a suggested set of keys. Example:\n\n ```js\n {\n \"statusCode\": 200,\n \"header\": \"HTTP/1.1 200 OK\\r\\nContent-Type: text/plain\\r\\nConnection: keep-alive\\r\\nTransfer-Encoding: chunked\\r\\n\\r\\n\"\n }\n ```\n\n## Other fields to consider\n\n- `req.username`: Authenticated user (or for a 401, the user attempting to\n auth).\n- Some mechanism to calculate response latency. \"restify\" users will have\n a \"X-Response-Time\" header. A `latency` custom field would be fine.\n- `req.body`: If you know that request bodies are small (common in APIs,\n for example), then logging the request body is good.\n\n\n# Streams\n\nA \"stream\" is Bunyan's name for where it outputs log messages (the equivalent\nto a log4j Appender). Ultimately Bunyan uses a\n[Writable Stream](https://nodejs.org/docs/latest/api/all.html#writable_Stream)\ninterface, but there are some additional attributes used to create and\nmanage the stream. A Bunyan Logger instance has one or more streams.\nIn general streams are specified with the \"streams\" option:\n\n```js\nvar bunyan = require('bunyan');\nvar log = bunyan.createLogger({\n name: \"foo\",\n streams: [\n {\n stream: process.stderr,\n level: \"debug\"\n },\n ...\n ]\n});\n```\n\nFor convenience, if there is only one stream, it can specified with the\n\"stream\" and \"level\" options (internally converted to a `Logger.streams`).\n\n```js\nvar log = bunyan.createLogger({\n name: \"foo\",\n stream: process.stderr,\n level: \"debug\"\n});\n```\n\nNote that \"file\" streams do not support this shortcut (partly for historical\nreasons and partly to not make it difficult to add a literal \"path\" field\non log records).\n\nIf neither \"streams\" nor \"stream\" are specified, the default is a stream of\ntype \"stream\" emitting to `process.stdout` at the \"info\" level.\n\n## Adding a Stream\n\nAfter a bunyan instance has been initialized, you may add additional streams by\ncalling the `addStream` function.\n\n```js\nvar bunyan = require('bunyan');\nvar log = bunyan.createLogger('myLogger');\nlog.addStream({\n name: \"myNewStream\",\n stream: process.stderr,\n level: \"debug\"\n});\n```\n\n## stream errors\n\nA Bunyan logger instance can be made to re-emit \"error\" events from its\nstreams. Bunyan does so by default for [`type === \"file\"`\nstreams](#stream-type-file), so you can do this:\n\n```js\nvar log = bunyan.createLogger({name: 'mylog', streams: [{path: LOG_PATH}]});\nlog.on('error', function (err, stream) {\n // Handle stream write or create error here.\n});\n```\n\nAs of bunyan@1.7.0, the `reemitErrorEvents` field can be used when adding a\nstream to control whether \"error\" events are re-emitted on the Logger. For\nexample:\n\n var EventEmitter = require('events').EventEmitter;\n var util = require('util');\n\n function MyFlakyStream() {}\n util.inherits(MyFlakyStream, EventEmitter);\n\n MyFlakyStream.prototype.write = function (rec) {\n this.emit('error', new Error('boom'));\n }\n\n var log = bunyan.createLogger({\n name: 'this-is-flaky',\n streams: [\n {\n type: 'raw',\n stream: new MyFlakyStream(),\n reemitErrorEvents: true\n }\n ]\n });\n log.info('hi there');\n\nThe behaviour is as follows:\n\n- `reemitErrorEvents` not specified: `file` streams will re-emit error events\n on the Logger instance.\n- `reemitErrorEvents: true`: error events will be re-emitted on the Logger\n for any stream with a `.on()` function -- which includes file streams,\n process.stdout/stderr, and any object that inherits from EventEmitter.\n- `reemitErrorEvents: false`: error events will not be re-emitted for any\n streams.\n\nNote: \"error\" events are **not** related to log records at the \"error\" level\nas produced by `log.error(...)`. See [the node.js docs on error\nevents](https://nodejs.org/api/events.html#events_error_events) for details.\n\n\n## stream type: `stream`\n\nA `type === 'stream'` is a plain ol' node.js [Writable\nStream](http://nodejs.org/docs/latest/api/all.html#writable_Stream). A\n\"stream\" (the writable stream) field is required. E.g.: `process.stdout`,\n`process.stderr`.\n\n```js\nvar log = bunyan.createLogger({\n name: 'foo',\n streams: [{\n stream: process.stderr\n // `type: 'stream'` is implied\n }]\n});\n```\n\n<table>\n<tr>\n<th>Field</th>\n<th>Required?</th>\n<th>Default</th>\n<th>Description</th>\n</tr>\n<tr>\n<td>stream</td>\n<td>Yes</td>\n<td>-</td>\n<td>A \"Writable Stream\", e.g. a std handle or an open file write stream.</td>\n</tr>\n<tr>\n<td>type</td>\n<td>No</td>\n<td>n/a</td>\n<td>`type == 'stream'` is implied if the `stream` field is given.</td>\n</tr>\n<tr>\n<td>level</td>\n<td>No</td>\n<td>info</td>\n<td>The level to which logging to this stream is enabled. If not\nspecified it defaults to \"info\". If specified this can be one of the\nlevel strings (\"trace\", \"debug\", ...) or constants (`bunyan.TRACE`,\n`bunyan.DEBUG`, ...). This serves as a severity threshold for that stream\nso logs of greater severity will also pass through (i.e. If level=\"warn\",\nerror and fatal will also pass through this stream).</td>\n</tr>\n<tr>\n<td>name</td>\n<td>No</td>\n<td>-</td>\n<td>A name for this stream. This may be useful for usage of `log.level(NAME,\nLEVEL)`. See the [Levels section](#levels) for details. A stream \"name\" isn't\nused for anything else.</td>\n</tr>\n</table>\n\n\n## stream type: `file`\n\nA `type === 'file'` stream requires a \"path\" field. Bunyan will open this\nfile for appending. E.g.:\n\n```js\nvar log = bunyan.createLogger({\n name: 'foo',\n streams: [{\n path: '/var/log/foo.log',\n // `type: 'file'` is implied\n }]\n});\n```\n\n<table>\n<tr>\n<th>Field</th>\n<th>Required?</th>\n<th>Default</th>\n<th>Description</th>\n</tr>\n<tr>\n<td>path</td>\n<td>Yes</td>\n<td>-</td>\n<td>A file path to which to log.</td>\n</tr>\n<tr>\n<td>type</td>\n<td>No</td>\n<td>n/a</td>\n<td>`type == 'file'` is implied if the `path` field is given.</td>\n</tr>\n<tr>\n<td>level</td>\n<td>No</td>\n<td>info</td>\n<td>The level to which logging to this stream is enabled. If not\nspecified it defaults to \"info\". If specified this can be one of the\nlevel strings (\"trace\", \"debug\", ...) or constants (`bunyan.TRACE`,\n`bunyan.DEBUG`, ...). This serves as a severity threshold for that\nstream so logs of greater severity will also pass through (i.e. If\nlevel=\"warn\", error and fatal will also pass through this stream).</td>\n</tr>\n<tr>\n<td>name</td>\n<td>No</td>\n<td>-</td>\n<td>A name for this stream. This may be useful for usage of `log.level(NAME,\nLEVEL)`. See the [Levels section](#levels) for details. A stream \"name\" isn't\nused for anything else.</td>\n</tr>\n</table>\n\n\n## stream type: `rotating-file`\n\n**WARNING on node 0.8 usage:** Users of Bunyan's `rotating-file` should (a) be\nusing at least bunyan 0.23.1 (with the fix for [this\nissue](https://github.com/trentm/node-bunyan/pull/97)), and (b) should use at\nleast node 0.10 (node 0.8 does not support the `unref()` method on\n`setTimeout(...)` needed for the mentioned fix). The symptom is that process\ntermination will hang for up to a full rotation period.\n\n**WARNING on [cluster](http://nodejs.org/docs/latest/api/all.html#all_cluster)\nusage:** Using Bunyan's `rotating-file` stream with node.js's \"cluster\" module\ncan result in unexpected file rotation. You must not have multiple processes\nin the cluster logging to the same file path. In other words, you must have\na separate log file path for the master and each worker in the cluster.\nAlternatively, consider using a system file rotation facility such as\n`logrotate` on Linux or `logadm` on SmartOS/Illumos. See\n[this comment on issue #117](https://github.com/trentm/node-bunyan/issues/117#issuecomment-44804938)\nfor details.\n\nA `type === 'rotating-file'` is a file stream that handles file automatic\nrotation.\n\n```js\nvar log = bunyan.createLogger({\n name: 'foo',\n streams: [{\n type: 'rotating-file',\n path: '/var/log/foo.log',\n period: '1d', // daily rotation\n count: 3 // keep 3 back copies\n }]\n});\n```\n\nThis will rotate '/var/log/foo.log' every day (at midnight) to:\n\n```sh\n/var/log/foo.log.0 # yesterday\n/var/log/foo.log.1 # 1 day ago\n/var/log/foo.log.2 # 2 days ago\n```\n\n*Currently*, there is no support for providing a template for the rotated\nfiles, or for rotating when the log reaches a threshold size.\n\n<table>\n<tr>\n<th>Field</th>\n<th>Required?</th>\n<th>Default</th>\n<th>Description</th>\n</tr>\n<tr>\n<td>type</td>\n<td>Yes</td>\n<td>-</td>\n<td>\"rotating-file\"</td>\n</tr>\n<tr>\n<td>path</td>\n<td>Yes</td>\n<td>-</td>\n<td>A file path to which to log. Rotated files will be \"$path.0\",\n\"$path.1\", ...</td>\n</tr>\n<tr>\n<td>period</td>\n<td>No</td>\n<td>1d</td>\n<td>The period at which to rotate. This is a string of the format\n\"$number$scope\" where \"$scope\" is one of \"ms\" (milliseconds -- only useful for\ntesting), \"h\" (hours), \"d\" (days), \"w\" (weeks), \"m\" (months), \"y\" (years). Or\none of the following names can be used \"hourly\" (means 1h), \"daily\" (1d),\n\"weekly\" (1w), \"monthly\" (1m), \"yearly\" (1y). Rotation is done at the start of\nthe scope: top of the hour (h), midnight (d), start of Sunday (w), start of the\n1st of the month (m), start of Jan 1st (y).</td>\n</tr>\n<tr>\n<td>count</td>\n<td>No</td>\n<td>10</td>\n<td>The number of rotated files to keep.</td>\n</tr>\n<tr>\n<td>level</td>\n<td>No</td>\n<td>info</td>\n<td>The level at which logging to this stream is enabled. If not\nspecified it defaults to \"info\". If specified this can be one of the\nlevel strings (\"trace\", \"debug\", ...) or constants (`bunyan.TRACE`,\n`bunyan.DEBUG`, ...).</td>\n</tr>\n<tr>\n<td>name</td>\n<td>No</td>\n<td>-</td>\n<td>A name for this stream. This may be useful for usage of `log.level(NAME,\nLEVEL)`. See the [Levels section](#levels) for details. A stream \"name\" isn't\nused for anything else.</td>\n</tr>\n</table>\n\n\n**Note on log rotation**: Often you may be using external log rotation utilities\nlike `logrotate` on Linux or `logadm` on SmartOS/Illumos. In those cases, unless\nyour are ensuring \"copy and truncate\" semantics (via `copytruncate` with\nlogrotate or `-c` with logadm) then the fd for your 'file' stream will change.\nYou can tell bunyan to reopen the file stream with code like this in your\napp:\n\n```js\nvar log = bunyan.createLogger(...);\n...\nprocess.on('SIGUSR2', function () {\n log.reopenFileStreams();\n});\n```\n\nwhere you'd configure your log rotation to send SIGUSR2 (or some other signal)\nto your process. Any other mechanism to signal your app to run\n`log.reopenFileStreams()` would work as well.\n\n\n## stream type: `raw`\n\n- `raw`: Similar to a \"stream\" writable stream, except that the write method\n is given raw log record *Object*s instead of a JSON-stringified string.\n This can be useful for hooking on further processing to all Bunyan logging:\n pushing to an external service, a RingBuffer (see below), etc.\n\n\n\n## `raw` + RingBuffer Stream\n\nBunyan comes with a special stream called a RingBuffer which keeps the last N\nrecords in memory and does *not* write the data anywhere else. One common\nstrategy is to log 'info' and higher to a normal log file but log all records\n(including 'trace') to a ringbuffer that you can access via a debugger, or your\nown HTTP interface, or a post-mortem facility like MDB or node-panic.\n\nTo use a RingBuffer:\n\n```js\n/* Create a ring buffer that stores the last 100 records. */\nvar bunyan = require('bunyan');\nvar ringbuffer = new bunyan.RingBuffer({ limit: 100 });\nvar log = bunyan.createLogger({\n name: 'foo',\n streams: [\n {\n level: 'info',\n stream: process.stdout\n },\n {\n level: 'trace',\n type: 'raw', // use 'raw' to get raw log record objects\n stream: ringbuffer\n }\n ]\n});\n\nlog.info('hello world');\nconsole.log(ringbuffer.records);\n```\n\nThis example emits:\n\n```js\n[ { name: 'foo',\n hostname: '912d2b29',\n pid: 50346,\n level: 30,\n msg: 'hello world',\n time: '2012-06-19T21:34:19.906Z',\n v: 0 } ]\n```\n\n## third-party streams\n\nSee the [user-maintained list in the Bunyan\nwiki](https://github.com/trentm/node-bunyan/wiki/Awesome-Bunyan).\n\n\n# Runtime log snooping via DTrace\n\nOn systems that support DTrace (e.g., illumos derivatives like SmartOS and\nOmniOS, FreeBSD, Mac), Bunyan will create a DTrace provider (`bunyan`) that\nmakes available the following probes:\n\n```sh\nlog-trace\nlog-debug\nlog-info\nlog-warn\nlog-error\nlog-fatal\n```\n\nEach of these probes has a single argument: the string that would be\nwritten to the log. Note that when a probe is enabled, it will\nfire whenever the corresponding function is called, even if the level of\nthe log message is less than that of any stream.\n\n\n## DTrace examples\n\nTrace all log messages coming from any Bunyan module on the system.\n(The `-x strsize=4k` is to raise dtrace's default 256 byte buffer size\nbecause log messages are longer than typical dtrace probes.)\n\n```sh\ndtrace -x strsize=4k -qn 'bunyan*:::log-*{printf(\"%d: %s: %s\", pid, probefunc, copyinstr(arg0))}'\n```\n\nTrace all log messages coming from the \"wuzzle\" component:\n\n```sh\ndtrace -x strsize=4k -qn 'bunyan*:::log-*/strstr(this->str = copyinstr(arg0), \"\\\"component\\\":\\\"wuzzle\\\"\") != NULL/{printf(\"%s\", this->str)}'\n```\n\nAggregate debug messages from process 1234, by message:\n\n```sh\ndtrace -x strsize=4k -n 'bunyan1234:::log-debug{@[copyinstr(arg0)] = count()}'\n```\n\nHave the bunyan CLI pretty-print the traced logs:\n\n```sh\ndtrace -x strsize=4k -qn 'bunyan1234:::log-*{printf(\"%s\", copyinstr(arg0))}' | bunyan\n```\n\nA convenience handle has been made for this:\n\n```sh\nbunyan -p 1234\n```\n\nOn systems that support the\n[`jstack`](http://dtrace.org/blogs/dap/2012/04/25/profiling-node-js/) action\nvia a node.js helper, get a stack backtrace for any debug message that\nincludes the string \"danger!\":\n\n```sh\ndtrace -x strsize=4k -qn 'log-debug/strstr(copyinstr(arg0), \"danger!\") != NULL/{printf(\"\\n%s\", copyinstr(arg0)); jstack()}'\n```\n\nOutput of the above might be:\n\n```\n{\"name\":\"foo\",\"hostname\":\"763bf293-d65c-42d5-872b-4abe25d5c4c7.local\",\"pid\":12747,\"level\":20,\"msg\":\"danger!\",\"time\":\"2012-10-30T18:28:57.115Z\",\"v\":0}\n\n node`0x87e2010\n DTraceProviderBindings.node`usdt_fire_probe+0x32\n DTraceProviderBindings.node`_ZN4node11DTraceProbe5_fireEN2v85LocalINS1_5ValueEEE+0x32d\n DTraceProviderBindings.node`_ZN4node11DTraceProbe4FireERKN2v89ArgumentsE+0x77\n << internal code >>\n (anon) as (anon) at /root/node-bunyan/lib/bunyan.js position 40484\n << adaptor >>\n (anon) as doit at /root/my-prog.js position 360\n (anon) as list.ontimeout at timers.js position 4960\n << adaptor >>\n << internal >>\n << entry >>\n node`_ZN2v88internalL6InvokeEbNS0_6HandleINS0_10JSFunctionEEENS1_INS0_6ObjectEEEiPS5_Pb+0x101\n node`_ZN2v88internal9Execution4CallENS0_6HandleINS0_6ObjectEEES4_iPS4_Pbb+0xcb\n node`_ZN2v88Function4CallENS_6HandleINS_6ObjectEEEiPNS1_INS_5ValueEEE+0xf0\n node`_ZN4node12MakeCallbackEN2v86HandleINS0_6ObjectEEENS1_INS0_8FunctionEEEiPNS1_INS0_5ValueEEE+0x11f\n node`_ZN4node12MakeCallbackEN2v86HandleINS0_6ObjectEEENS1_INS0_6StringEEEiPNS1_INS0_5ValueEEE+0x66\n node`_ZN4node9TimerWrap9OnTimeoutEP10uv_timer_si+0x63\n node`uv__run_timers+0x66\n node`uv__run+0x1b\n node`uv_run+0x17\n node`_ZN4node5StartEiPPc+0x1d0\n node`main+0x1b\n node`_start+0x83\n\n node`0x87e2010\n DTraceProviderBindings.node`usdt_fire_probe+0x32\n DTraceProviderBindings.node`_ZN4node11DTraceProbe5_fireEN2v85LocalINS1_5ValueEEE+0x32d\n DTraceProviderBindings.node`_ZN4node11DTraceProbe4FireERKN2v89ArgumentsE+0x77\n << internal code >>\n (anon) as (anon) at /root/node-bunyan/lib/bunyan.js position 40484\n << adaptor >>\n (anon) as doit at /root/my-prog.js position 360\n (anon) as list.ontimeout at timers.js position 4960\n << adaptor >>\n << internal >>\n << entry >>\n node`_ZN2v88internalL6InvokeEbNS0_6HandleINS0_10JSFunctionEEENS1_INS0_6ObjectEEEiPS5_Pb+0x101\n node`_ZN2v88internal9Execution4CallENS0_6HandleINS0_6ObjectEEES4_iPS4_Pbb+0xcb\n node`_ZN2v88Function4CallENS_6HandleINS_6ObjectEEEiPNS1_INS_5ValueEEE+0xf0\n node`_ZN4node12MakeCallbackEN2v86HandleINS0_6ObjectEEENS1_INS0_8FunctionEEEiPNS1_INS0_5ValueEEE+0x11f\n node`_ZN4node12MakeCallbackEN2v86HandleINS0_6ObjectEEENS1_INS0_6StringEEEiPNS1_INS0_5ValueEEE+0x66\n node`_ZN4node9TimerWrap9OnTimeoutEP10uv_timer_si+0x63\n node`uv__run_timers+0x66\n node`uv__run+0x1b\n node`uv_run+0x17\n node`_ZN4node5StartEiPPc+0x1d0\n node`main+0x1b\n node`_start+0x83\n```\n\n\n# Runtime environments\n\nNode-bunyan supports running in a few runtime environments:\n\n- [Node.js](https://nodejs.org/)\n- [Browserify](http://browserify.org/): See the\n [Browserify section](#browserify) below.\n- [Webpack](https://webpack.github.io/): See the [Webpack section](#webpack) below.\n- [NW.js](http://nwjs.io/)\n\nSupport for other runtime environments is welcome. If you have suggestions,\nfixes, or mentions that node-bunyan already works in some other JavaScript\nruntime, please open an [issue](https://github.com/trentm/node-bunyan/issues/new)\nor a pull request.\n\nThe primary target is Node.js. It is the only environment in which I\nregularly test. If you have suggestions for how to automate testing for other\nenvironments, I'd appreciate feedback on [this automated testing\nissue](https://github.com/trentm/node-bunyan/issues/342).\n\n## Browserify\n\nAs the [Browserify](http://browserify.org/) site says it \"lets you\n`require('modules')` in the browser by bundling up all of your dependencies.\"\nIt is a build tool to run on your node.js script to bundle up your script and\nall its node.js dependencies into a single file that is runnable in the\nbrowser via:\n\n```html\n<script src=\"play.browser.js\"></script>\n```\n\nAs of version 1.1.0, node-bunyan supports being run via Browserify. The\ndefault [stream](#streams) when running in the browser is one that emits\nraw log records to `console.log/info/warn/error`.\n\nHere is a quick example showing you how you can get this working for your\nscript.\n\n1. Get browserify and bunyan installed in your module:\n\n ```sh\n $ npm install browserify bunyan\n ```\n\n2. An example script using Bunyan, \"play.js\":\n\n ```js\n var bunyan = require('bunyan');\n var log = bunyan.createLogger({name: 'play', level: 'debug'});\n log.trace('this one does not emit');\n log.debug('hi on debug'); // console.log\n log.info('hi on info'); // console.info\n log.warn('hi on warn'); // console.warn\n log.error('hi on error'); // console.error\n ```\n\n3. Build this into a bundle to run in the browser, \"play.browser.js\":\n\n ```sh\n $ ./node_modules/.bin/browserify play.js -o play.browser.js\n ```\n\n4. Put that into an HTML file, \"play.html\":\n\n ```html\n <!DOCTYPE html>\n <html>\n <head>\n <meta charset=\"utf-8\">\n <script src=\"play.browser.js\"></script>\n </head>\n <body>\n <div>hi</div>\n </body>\n </html>\n ```\n\n5. Open that in your browser and open your browser console:\n\n ```sh\n $ open play.html\n ```\n\nHere is what it looks like in Firefox's console: \n\nFor some, the raw log records might not be desired. To have a rendered log line\nyou'll want to add your own stream, starting with something like this:\n\n```js\nvar bunyan = require('./lib/bunyan');\n\nfunction MyRawStream() {}\nMyRawStream.prototype.write = function (rec) {\n console.log('[%s] %s: %s',\n rec.time.toISOString(),\n bunyan.nameFromLevel[rec.level],\n rec.msg);\n}\n\nvar log = bunyan.createLogger({\n name: 'play',\n streams: [\n {\n level: 'info',\n stream: new MyRawStream(),\n type: 'raw'\n }\n ]\n});\n\nlog.info('hi on info');\n```\n\n## Webpack\nWebpack can work with the same example Browserify above. To do this, we need to make webpack ignore optional files:\nCreate \"empty_shim.js\":\n```javascript\n// This is an empty shim for things that should be not be included in webpack\n```\nNow tell webpack to use this file for\n[optional dependencies](https://webpack.github.io/docs/configuration.html#resolve-alias)\nin your \"webpack.config.js\":\n```\nresolve: {\n // These shims are needed for bunyan\n alias: {\n 'dtrace-provider': '/path/to/shim/empty_shim.js',\n fs: '/path/to/shim/empty_shim.js',\n 'safe-json-stringify': '/path/to/shim/empty_shim.js',\n mv: '/path/to/shim/empty_shim.js',\n 'source-map-support': '/path/to/shim/empty_shim.js'\n }\n}\n```\nNow webpack builds, ignoring these optional dependencies via shimming in an empty JS file!\n\n# Versioning\n\nAll versions are `<major>.<minor>.<patch>` which will be incremented for\nbreaking backward compat and major reworks, new features without breaking\nchange, and bug fixes, respectively. tl;dr: [Semantic\nversioning](http://semver.org/).\n\n# License\n\n[MIT](./LICENSE.txt).\n\n# See Also\n\nSee the [user-maintained list of Bunyan-related software in the Bunyan\nwiki](https://github.com/trentm/node-bunyan/wiki/Awesome-Bunyan).\n",
|
|
"readmeFilename": "README.md",
|
|
"repository": {
|
|
"type": "git",
|
|
"url": "git://github.com/trentm/node-bunyan.git"
|
|
},
|
|
"scripts": {
|
|
"test": "make test"
|
|
},
|
|
"version": "1.8.10"
|
|
}
|