diagnostics_channel: add USDT probes

[bengl]

Adds a dc__publish USDT probe for diagnostics channel publish events.

Attaching a tracer does not activate inactive channels or bypass subscriber checks in publishers.

Includes Linux CI coverage with and without USDT, plus a bpftrace snapshot-restore regression test. Both CI builds assert the expected USDT support.

[nodejs-github-bot]

Review requested:

• @nodejs/gyp

[RafaelGSS]

We have removed dtrace support long time ago. Wouldn't it require us to include a new suite for testing it on that environment?

[bengl]

I'm not sure what our build setup looks like now, but yes, everything that was required for the previous incarnation of probes in Node.js would likely be required again with this PR.

[richardlau]

I don't think we tested the dtrace stuff previously. I think when it was removed it had be broken for a while (or maybe that was one of the other non-tested removed features).

[bengl]

There's a possible path forward here where headers are pre-generated and added to git (much like we do for other cases of generated headers, in dependencies for example), and then a userland, self-contained test (at least on linux) checks for the placement and activation of the probe.

[bengl]

Alright, I've made some changes (many months later..)

Linux is now default-on with no dtrace build dependency. src/node_provider_linux.h is committed.
It can be regenerated via tools/usdt/generate_headers.py and a --check drift job runs in CI against it.
Default ./configure enables USDT whenever <sys/sdt.h> is present (systemtap-sdt-dev / systemtap-sdt-devel is the only build requirement on Linux).

macOS is opt-in via ./configure --with-dtrace (which at build-time calls dtrace -h -xnolibs).
--without-dtrace still disables everything.

New test-usdt CI job in test-linux.yml:

• default: end-to-end bpftrace test as root (verifies the probe fires with the channel name) plus the committed-header drift check
• --without-dtrace: pins the no-op tier

Bench (aarch64 VM, benchmark/diagnostics_channel/publish.js, subscribers=1, avg of 2): default ~282M ops/s vs --without-dtrace ~314M ops/s — ~10% on this microbench.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[codecov]

Codecov Report

❌ Patch coverage is 46.15385% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.43%. Comparing base (4bf4c00) to head (8ada985).
⚠️ Report is 596 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_diagnostics_channel.cc	6.66%	10 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62118      +/-   ##
==========================================
+ Coverage   90.17%   90.43%   +0.26%     
==========================================
  Files         771      791      +20     
  Lines      265496   276504   +11008     
  Branches    50483    53094    +2611     
==========================================
+ Hits       239401   250046   +10645     
+ Misses      17052    16858     -194     
- Partials     9043     9600     +557     

Files with missing lines	Coverage Δ
lib/diagnostics_channel.js	97.66% <100.00%> (+0.31%)	⬆️
src/node_diagnostics_channel.h	71.42% <ø> (+14.28%)	⬆️
src/node_diagnostics_channel.cc	80.64% <6.66%> (-3.01%)	⬇️

... and 312 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/77839/

[github-actions]

Failed to resume CI

✖ CI job 77839 is in status RUNNING, skipping resume

Full Auto Start CI output

�[36m⠋�[39m Validating Jenkins credentials
�[36m⠋�[39m Validating Jenkins credentials
✔  Jenkins credentials valid
�[36m⠙�[39m Looking for CI runs for pull request 62118
�[36m⠙�[39m Looking for CI runs for pull request 62118
�[36m⠙�[39m Getting PR from nodejs/node/pull/62118
�[36m⠙�[39m Getting reviews from nodejs/node/pull/62118
�[36m⠙�[39m Getting comments from nodejs/node/pull/62118
✔  Found PR CI job 77839
�[36m⠹�[39m Querying data for job/node-test-pull-request/77839/
�[36m⠹�[39m Querying data for job/node-test-pull-request/77839/
�[36m⠹�[39m Querying API for job/node-test-pull-request/77839/
✔  Build data downloaded
   ✖  CI job 77839 is in status RUNNING, skipping resume

View workflow run

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/77946/

[bengl]

@panva I think your comments are addressed now. PTAL.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78228/

[legendecas]

Can we use a platform assert to ensure that probeSemaphore is not undefined on Linux, where the support is enabled by default?

This ensures that the test does run on Linux CI.

[bengl]

Done.

[legendecas]

sorry I think the GitHub UI is broken for my comment. I mean something like this:

// test/common/usdt.js

function skipIfUsdtIsDisabled() {
  if (!process.config.variables.node_no_usdt && process.config.variables.node_use_dtrace) {
    return;
  }
  common.skip("USDT is not enabled);
}

and in this test:

skipIfUsdtIsDisabled();

assert.ok(
    probeSemaphore instanceof Uint16Array,
    `Expected probeSemaphore to be Uint16Array, got ${typeof probeSemaphore}`,
  );
assert.ok(
      probeSemaphore[0] === 0 || probeSemaphore[0] === 1,
      `Expected semaphore to be 0 or 1, got ${probeSemaphore[0]}`,
    );

[legendecas]

Same, it would be helpful to add a test condition in test/common/index.js (or a new test/common/usdt.js as this accesses an internal binding) to ensure that the test is determined to be enabled when the USDT support is supposed to be enabled.

[bengl]

Done.

[Qard]

+1 to the comments from @legendecas, but also, it sounds like JS subscribers are needed for the publishes to actually fire the probes? This appears to not be the case for the native-side publishes. This seems a bit unexpected to me. Is there some way we could read the semaphore or the bit the kernel modifies to detect liveness and use that to do the mode-swap on the channel somehow so it becomes active if a probe is attached?

Also, how exactly would the message object be consumed? It seems to be getting passed, but as just a void* which I'm not sure if there's any useful way to consume that externally? Is that actually useful?