make trace-events write to configurable sink

[mike-kaufman]

in stateless/paas environments, we want trace-event data to be written to a configurable, arbitrary "sink" (i.e., a stream that can be a socket, file, ...).

• can configure with an arbitrary file path
• network socket
• local shared memory?

For context, at diagnostics summit, we discussed getting "failure" data off of stateless environments in general. We identified three types of data we're interested in:

• stdout/stderr
• core dumps
• trace events

stdout/stderr is configurable by redirecting the stream.
core dumps are configurable via the host environment
This leaves only trace-event data that we want to configure.

[mike-kaufman]

some overlap here w/ #163?

[AndreasMadsen]

I don’t think so. Trace Events is a provider for our UDTP (user defined tracking point) implementation. The other implementations will have their own sink mechanism (the kernel).

PS: nodejs/node#18480 will land soon, so that will at least make it possible to write to an arbitrary file.

[jasnell]

Quick update on this: @ofrobots and I have been speaking about the possibility of using the inspector protocol to deliver trace events. Some work has already started in this direction with a PR to allow multiple concurrent inspector protocol sessions. There's a bit of work to do here but it should give us a number of solid options.

[ofrobots]

Some updates from our side:

• The tracing domain is part of the Chrome DevTools protocol, but it isn't available in Node just yet – it is implemented in Chrome and @eugeneo has been working on adding the Tracing domain to Node. We expect to open a PR for this shortly.
• Until recently Node was limited to a single inspector connection. Eugene recently added support for multiple clients to connect to DevTools to consume trace data. This should allow multiple clients to connect to consume trace data.

Once this is available, it would be fairly straightforward to write clients in JS, or otherwise, to connect and consume data. Here's a small program that I wrote that retrieves trace data. I tested this against Chrome – as node doesn't expose the Tracing domain through the inspector just yet.

const CDP = require('chrome-remote-interface');

async function main() {
  const client = await CDP();

  client.on('event', (message) => {
    console.log(message.method);
  });

  let result = await client.Tracing.start({ recordMode: 'recordContinuously', transferMode: 'ReturnAsStream'});
  client.Tracing.tracingComplete(async (params) => {
    const stream = params.stream;
    let eof = false;
    let num = 0;
    while (!eof) {
      const chunk = await client.IO.read({handle: stream, size: 128 * 1024});
      num++;
      console.log(`chunk ${num} eof:`, chunk.eof, 'data:', chunk.data.length);
      eof = chunk.eof;
    }
  });
  setTimeout(() => { client.Tracing.end(); }, 2000);
}

main().catch(console.error);

[mike-kaufman]

Having this data over CDP is really useful, but does it obviate desire to redirect trace events to a file/stream, e.g. via a command-line switch? Consuming CDP may be challenging in PaaS environments, due to network constraints, process constraints, ...

[ofrobots]

File output would still be supported.

[gireeshpunathil]

should this remain open? [ I am trying to chase dormant issues to closure ]

[jasnell]

This can be closed