elide Bunyan 'pid' and 'hostname' fields in OTel log record attributes

Because they are redundant with 'process.pid' and 'host.name'
resource attributes. Add some docs on how to use resource detectors
to the example, because the HostDetector is not on by default in
the NodeSDK.

plugins/node/opentelemetry-instrumentation-bunyan/README.md

@@ -34,13 +34,14 @@ const sdk = new NodeSDK({
   ]
 })
 
+const bunyan = require('bunyan');
 const logger = bunyan.createLogger({name: 'example'});
 
 logger.info('hi');
 // 1. Log records will be sent to the SDK-registered log record processor, if any.
 //    This is called "bridging".
 
-const tracer = api.getTracer('example');
+const tracer = api.trace.getTracer('example');
 tracer.startActiveSpan('manual-span', span => {
   logger.info('in a span');
   // 2. Fields identifying the current span will be injected into log records:

plugins/node/opentelemetry-instrumentation-bunyan/examples/README.md

@@ -29,7 +29,7 @@ $ node -r ./telemetry.js app.js
   severityText: 'debug',
   severityNumber: 5,
   body: 'hi',
-  attributes: { name: 'myapp', hostname: 'amachine.local', pid: 93017 }
+  attributes: { name: 'myapp', foo: 'bar' }
 }
 {"name":"myapp","hostname":"amachine.local","pid":93017,"level":30,"msg":"this record will have trace_id et al fields for the current span","time":"2023-09-27T23:24:06.079Z","v":0,"trace_id":"af5ce23816c4feabb713ee1dc84ef4d3","span_id":"5f50e181ec7bc621","trace_flags":"01"}
 {
@@ -42,8 +42,6 @@ $ node -r ./telemetry.js app.js
   body: 'this record will have trace_id et al fields for the current span',
   attributes: {
     name: 'myapp',
-    hostname: 'amachine.local',
-    pid: 93017,
     trace_id: 'af5ce23816c4feabb713ee1dc84ef4d3',
     span_id: '5f50e181ec7bc621',
     trace_flags: '01'
@@ -65,15 +63,53 @@ $ node -r ./telemetry.js app.js
 }
 ```
 
-There are two separate Bunyan instrumentation functionalities. The first is
-that Bunyan log records emitted in the context of a tracing span will include
-`trace_id` and `span_id` fields that can be used for correlating with collect
-tracing data. Line 3 shows an example of this.
+There are two separate Bunyan instrumentation functionalities. The first, called
+"log injection", is that Bunyan log records emitted in the context of a tracing
+span will include `trace_id` and `span_id` fields that can be used for
+correlating with collected tracing data.
 
-The second is that a [Bunyan
+The second, called "logs bridging", is that a [Bunyan
 stream](https://github.com/trentm/node-bunyan#streams) is automatically added
 to created Loggers that will send every log record to the OpenTelemetry Logs
 Bridge API. This means that if the OpenTelemetry SDK has been configured with
 a Logger Provider, it will receive them. (If the OpenTelemetry SDK is not
-configured for this, then the added Bunyan stream will be a no-op.) Lines 2
-and 4 show a dumped OpenTelemetry Log Record.
+configured for this, then the added Bunyan stream will be a no-op.)
+
+
+# Resource attributes
+
+One thing the `ConsoleLogRecordExporter` output above does not show is some
+additional data that is included in exported log records: resource attributes.
+
+Every OpenTelemetry LoggerProvider has a "resource". The OpenTelemetry SDK
+provides configurable "resource detectors" that collect data that is then
+included with log records. This can include "host.name" (provided by the
+`HostDetector`) and "process.pid" (provided by the `ProcessDetector`) -- which
+is why this instrumentation does **not** include the Bunyan "hostname" and "pid"
+fields in the log record attributes.
+
+When configured with the `HostDetector` and `ProcessDetector` (as shown in
+"telemetry.js") the log records above also include resource attributes such
+as the following:
+
+```js
+{
+  'process.pid': 93017,
+  'process.executable.name': 'node',
+  'process.executable.path': '/Users/trentm/.nvm/versions/node/v18.18.2/bin/node',
+  'process.command_args': [
+    '/Users/trentm/.nvm/versions/node/v18.18.2/bin/node',
+    '-r',
+    './telemetry.js',
+    '/Users/trentm/src/opentelemetry-js-contrib/plugins/node/opentelemetry-instrumentation-bunyan/examples/app.js'
+  ],
+  'process.runtime.version': '18.18.2',
+  'process.runtime.name': 'nodejs',
+  'process.runtime.description': 'Node.js',
+  'process.command': '/Users/trentm/src/opentelemetry-js-contrib/plugins/node/opentelemetry-instrumentation-bunyan/examples/app.js',
+  'process.owner': 'trentm'
+  'host.name': 'amachine.local',
+  'host.arch': 'amd64',
+  'host.id': '...'
+}
+```

plugins/node/opentelemetry-instrumentation-bunyan/examples/app.js

@@ -23,7 +23,7 @@ const bunyan = require('bunyan');
 
 const log = bunyan.createLogger({name: 'myapp', level: 'debug'});
 
-log.debug('hi');
+log.debug({foo: 'bar'}, 'hi');
 
 const tracer = otel.trace.getTracer('example');
 tracer.startActiveSpan('manual-span', span => {

plugins/node/opentelemetry-instrumentation-bunyan/examples/app.mjs

@@ -23,7 +23,7 @@ import bunyan from 'bunyan';
 
 const log = bunyan.createLogger({name: 'myapp', level: 'debug'});
 
-log.debug('hi');
+log.debug({foo: 'bar'}, 'hi');
 
 const tracer = trace.getTracer('example');
 tracer.startActiveSpan('manual-span', span => {

plugins/node/opentelemetry-instrumentation-bunyan/examples/package.json

@@ -1,7 +1,7 @@
 {
   "name": "bunyan-example",
   "private": true,
-  "version": "0.43.0",
+  "version": "0.45.1",
   "description": "Example of Bunyan integration with OpenTelemetry",
   "scripts": {
     "start": "node -r ./telemetry.js app.js"
@@ -19,7 +19,8 @@
   "dependencies": {
     "@opentelemetry/api": "^1.6.0",
     "@opentelemetry/instrumentation-bunyan": "../",
-    "@opentelemetry/sdk-node": "^0.43.0",
+    "@opentelemetry/resources": "^1.17.0",
+    "@opentelemetry/sdk-node": "^0.44.0",
     "bunyan": "^1.8.15"
   }
 }

plugins/node/opentelemetry-instrumentation-bunyan/examples/telemetry.js

@@ -21,12 +21,23 @@
 // for viewing and analysis.
 
 const { NodeSDK, tracing, logs, api } = require('@opentelemetry/sdk-node');
-// api.diag.setLogger(new api.DiagConsoleLogger(), api.DiagLogLevel.DEBUG);
+const { envDetectorSync, hostDetectorSync, processDetectorSync } = require('@opentelemetry/resources');
+api.diag.setLogger(new api.DiagConsoleLogger(), api.DiagLogLevel.DEBUG);
 
 const { BunyanInstrumentation } = require('@opentelemetry/instrumentation-bunyan');
 
 const sdk = new NodeSDK({
   serviceName: 'bunyan-example',
+  resourceDetectors: [
+    envDetectorSync,
+    // ProcessDetector adds `process.pid` (among other resource attributes),
+    // which replaces the usual Bunyan `pid` field.
+    processDetectorSync,
+    // The HostDetector adds `host.name` and `host.arch` fields. `host.name`
+    // replaces the usual Bunyan `hostname` field. HostDetector is *not* a
+    // default detector of the `NodeSDK`.
+    hostDetectorSync
+  ],
   spanProcessor: new tracing.SimpleSpanProcessor(new tracing.ConsoleSpanExporter()),
   logRecordProcessor: new logs.SimpleLogRecordProcessor(new logs.ConsoleLogRecordExporter()),
   instrumentations: [

plugins/node/opentelemetry-instrumentation-bunyan/package.json

@@ -52,7 +52,7 @@
     "@opentelemetry/sdk-logs": "^0.44.0",
     "@opentelemetry/sdk-trace-base": "^1.8.0",
     "@opentelemetry/sdk-trace-node": "^1.8.0",
-    "@opentelemetry/semantic-conventions": "^1.17.0",
+    "@opentelemetry/semantic-conventions": "^1.0.0",
     "@types/mocha": "7.0.2",
     "@types/node": "18.6.5",
     "@types/sinon": "10.0.18",

plugins/node/opentelemetry-instrumentation-bunyan/src/OpenTelemetryBunyanStream.ts

@@ -116,19 +116,33 @@ export class OpenTelemetryBunyanStream {
    * Dev Notes:
    * - We drop the Bunyan 'v' field. It is meant to indicate the format
    *   of the Bunyan log record. FWIW, it has always been `0`.
-   * - Some Bunyan fields would naturally map to Resource attributes:
-   *      hostname -> host.name
-   *      name -> service.name
-   *      pid -> process.pid
-   *   However, AFAIK there isn't a way to influence the LoggerProvider's
-   *   `resource` from here.
+   * - The standard Bunyan `hostname` and `pid` fields are removed because they
+   *   are redundant with the OpenTelemetry `host.name` and `process.pid`
+   *   Resource attributes, respectively. This code cannot change the
+   *   LoggerProvider's `resource`, so getting the OpenTelemetry equivalents
+   *   depends on the user using relevant OpenTelemetry resource detectors.
+   *   "examples/telemetry.js" shows using HostDetector and ProcessDetector for
+   *   this.
+   * - The Bunyan `name` field *could* naturally map to OpenTelemetry's
+   *   `service.name` resource attribute. However, that is debatable, as some
+   *   users might use `name` more like a log4j logger name.
    * - Strip the `trace_id` et al fields that may have been added by the
    *   the _emit wrapper.
    */
   write(rec: Record<string, any>) {
     // eslint-disable-next-line @typescript-eslint/no-unused-vars
-    const { time, level, msg, v, trace_id, span_id, trace_flags, ...fields } =
-      rec;
+    const {
+      time,
+      level,
+      msg,
+      v,
+      hostname,
+      pid,
+      trace_id,
+      span_id,
+      trace_flags,
+      ...fields
+    } = rec;
     let timestamp = undefined;
     if (typeof time.getTime === 'function') {
       timestamp = time.getTime(); // ms