feat(telemetry): add device ID logging COMPASS-8443 #2411
Conversation
| } catch (error) { | ||
| props.bus.emit( | ||
| 'mongosh:error', | ||
| new Error('Failed to get device ID'), |
There was a problem hiding this comment.
is it safe for us to pass the error to our telemetry? In Atlas CLI they do https://github.com/mongodb/mongodb-atlas-cli/blob/4c36ccfeecc95f208b7d276126c70cf16c5cde58/internal/telemetry/event.go#L156 but seems risky to me considering this potentially has traces with OS-level call output or whatnot.
There was a problem hiding this comment.
You mean, the original error? Yeah I'd include that at least for logging ... maybe we could make it the cause of this new error object, and then add logging for the cause in the mongosh:error listener (but not analytics)?
|
|
||
| export function setupLoggingAndTelemetry( | ||
| props: MongoshLoggingAndTelemetryArguments | ||
| ): MongoshLoggingAndTelemetry { | ||
| if (!props.deviceId) { |
There was a problem hiding this comment.
Seemed more logical for me for the device Id determination to exist here rather than in the class itself as then its state is immutable
|
|
||
| export function setupLoggingAndTelemetry( | ||
| props: MongoshLoggingAndTelemetryArguments | ||
| ): MongoshLoggingAndTelemetry { | ||
| if (!props.deviceId) { | ||
| try { | ||
| props.deviceId = machineIdSync(); |
There was a problem hiding this comment.
Let's do our very best to avoid synchronous I/O calls in the mongosh startup path, if we can at all? We already have a mechanism for deferring telemetry in place here, maybe we could use that with the async version of this function?
| } catch (error) { | ||
| props.bus.emit( | ||
| 'mongosh:error', | ||
| new Error('Failed to get device ID'), |
There was a problem hiding this comment.
You mean, the original error? Yeah I'd include that at least for logging ... maybe we could make it the cause of this new error object, and then add logging for the cause in the mongosh:error listener (but not analytics)?
| @@ -22,7 +22,8 @@ | |||
| "@mongosh/history": "2.4.6", | |||
| "@mongosh/types": "3.6.0", | |||
| "mongodb-log-writer": "^2.3.1", | |||
| "mongodb-redact": "^1.1.5" | |||
| "mongodb-redact": "^1.1.5", | |||
| "node-machine-id": "^1.1.12" | |||
There was a problem hiding this comment.
This is an unmaintained package which always runs multiple child processes to get its result, I do wonder if there are better alternatives out there, even if it's just hashing os.hostname() and maybe the mac addresses reported in os.networkInterfaces()?
There was a problem hiding this comment.
yeah I agree, I wasn't sure about the package though it is used by some pretty big projects and with no good alternatives. If we go in a different direction we'd likely want the Atlas CLI to adopt the same as well but considering the library talks about lack of reliability of Mac addresses etc., seem like it won't be that reliable.
I'm wondering if we could instead do a shared mongodb devtools like ~/.mongodb-tools/config.yaml directory or something where we write a new UUID for anonymousId and let mongosh, Compass, and Atlas CLI read and use this if it exists already. Seems like hoping all tools can reliably come up with the same device identifier is more unreliable anyhow.
There was a problem hiding this comment.
haha just realized the "big projects which use this" includes https://www.npmjs.com/package/realm?activeTab=dependencies 😅
There was a problem hiding this comment.
I'm wondering if we could instead do a shared mongodb devtools like
~/.mongodb-tools/config.yamldirectory or something where we write a new UUID for anonymousId and let mongosh, Compass, and Atlas CLI read and use this if it exists already.
If that is an option, we should definitely go with it. I had assumed we'd want a true "device" ID, not something that would be per-user, but in today's world the latter is probably at least as good as the former. (It also has the advantage of the user being able to control it, if necessary.)
Seems like hoping all tools can reliably come up with the same device identifier is more unreliable anyhow.
Agreed 👍
There was a problem hiding this comment.
I'll ask analytics team, seems like a cleaner option; I think our motivation is to be able to associate the user between our various tools rather than actually identify a device. The only concern is maybe whether an application can always write/read that directory, wherever we decide to put that across OSes
To standardize identification across DevTools and Atlas CLI, this introduces a
node-machine-iddependency which uses the same base system calls for determining the device Id as https://github.com/denisbrodbeck/machineid that is used for the device ID by the Atlas CLI. The only exception being the lack of BSD fallback of using/etc/hostidandsmbios.system.uuidthat the Go library uses but the Node one does not; in that case our device ID will likely be undefined or different.Both libraries use hashing to protect the machine-specific information.
We could using
anonymousIdasdeviceIdas done in the Atlas CLI but the concerns are: a) this transition may break many existing user associations we have and b) if for whatever reason device ID cannot be determined on a given OS, we'd loseanonymousIdaltogether. Therefore this instead adds a new identity field for Segment.To Do: