Open frostmar opened 3 years ago
Until this is fixed, is there any way to prevent the socket.io probe from installing? We only use data from other probes.
appMetrics.disable('socketio')
doesn't help. It looks to me that all probes are installed very early, by the appmetrics index.js, and whether a probe is disabled doesn't affect it attempting to hook in during the require of the target library.
Our code is approximately:
appMetrics = require('appmetrics')
appMetrics.configure({ mqtt: 'off' })
const appMetricsMonitor = appMetrics.monitor()
appMetrics.disable('socketio')
// ... later ...
require('socket.io')
Same issue, I need socket.io v3, and that impedes me to use appmetrics-dash due to this issue with appmatrics. I used it in the past, before using v3, and I'd like to continue... Has this problem been acknowledged by the devs?
If you require socket.io BEFORE appmetrics then it will not be instrumented by appmetrics regardless of the later disable call.
The socket.io probe https://github.com/RuntimeTools/appmetrics/blob/master/probes/socketio-probe.js works fine with socket.io@2
However socket.io was rewritten for it's v3 and v4. The socket.io interface has changed slightly, causing the following exception to be thrown when socket.io is require'd and the probe attempts to hook in:
I've done a little debugging and can see:
socket.io@2 exports a function with a prototype containing the methods the probe wants to patch.
socket.io@4 exports a factory function. The class is available as as export
.Server
(ierequre('socket.io').Server
) however it's now a proper javascript Class, and it's constructor can't be hooked in the way used previously.