dd-trace-js
dd-trace-js copied to clipboard
WIP hooks fine tuning
What does this PR do?
The idea is to provide the hooks with a way to obtain the caller Module. That way when a wrapped method publishes messages via dc it could include the caller module to help subscribers to discard the message based on the caller (without the need to obtain the stacktrace for example) .
// a.js
const fs = require('fs')
fs.readFileSync('/path') // -> triggers 'apm:fs:operation:start' { operation: 'readFileSync', path: '/path', caller: a.js }
At the moment, once a module has been instrumented, it is cached and reused from the cache.
But rim could use a Proxy to link the requested module with its parent.
The Proxy would provide a __getCallerMethod
method which returns the parent module.
// ritm
new Proxy(fs, {
... // get trap omitted
__getCallerMethod: () => a.js
})
Allowing instrumentation hooks to obtain the module which is calling the fs function
Introduces the 'dd-trace:moduleLoadCachedStart' channel to demonstrate how a subscriber could choose between using the real module or a proxy.
Motivation
Some modules like fs
or crypto
generate a large number of events due its instrumentation.
A lot of them have not interest for its subscribers (IAST or RASP soon) because the operations are triggered by third party modules or in contexts where there are not tainted values.
If subscribers had information of the caller, the event could be discarded sooner and without taint checking or without relying on the stacktrace.
Plugin Checklist
- [ ] Unit tests.
- [ ] TypeScript definitions.
- [ ] TypeScript tests.
- [ ] API documentation.
- [ ] CircleCI jobs/workflows.
- [ ] Plugin is exported.