-
Notifications
You must be signed in to change notification settings - Fork 70
feat(telemetry): add device ID logging COMPASS-8443 #2411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f83cffc
to
09eca29
Compare
0a9e5a0
to
95d93a5
Compare
@addaleax I ended up sticking with device ID for reasons I mentioned in Alternative Considerations in the PR description, mainly easier adaptability from existing Atlas CLI data. I also re-organized the logic so now we have 2 parallel buffers for bus events in general as well as telemetry events in particular until the device ID is resolved. Let me know if you have any thoughts about either of that. |
try { | ||
this.deviceId ??= await Promise.race([ | ||
getDeviceId(), | ||
new Promise<string>((resolve) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may not be necessary I am just not sure if there's an issue with leaving the getDeviceId()
"running" while we're flushing the events; does this get killed? My guess is it this doesn't matter but don't want to end up delaying the shell exit because of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense. Like you said probably not strictly necessary, but nice to have. Personally I'd leave a comment in this code with this reasoning for our future selves, but consider that a nit.
packages/cli-repl/src/cli-repl.ts
Outdated
@@ -1206,11 +1207,14 @@ export class CliRepl implements MongoshIOProvider { | |||
* @param code The user-provided exit code, if any. | |||
*/ | |||
async exit(code?: number): Promise<never> { | |||
this.loggingAndTelemetry?.flush(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should be doing this generally in any case to make sure all telemetry (including the error afterwards?) get reported even before this change
26df86b
to
3dda787
Compare
3dda787
to
7484681
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So ... I don't want to slow down work that I know we want to just get done¹, but I do still feel pretty uneasy about using node-machine-id, the fact that we're spawning multiple extra child processes on each startup of mongosh just feels fairly wrong, from a performance¹ and security perspective, even if we don't see an immediate critical issue with it.
Can we try to align even more closely with the Atlas CLI and use the same approach, which is to essentially perform the lookups in native/compiled code? I know that that comes with a bit of overhead, but it's far from infeasible (we've done that for other smaller things as well, like https://github.com/mongodb-js/glibc-version) and I'm happy to help with getting that off the ground.
¹ Telemetry is still turned off for mongosh, so it's probably not super time-sensitive?
² Startup performance has been a big pain point in the past for us and even though the perf tests in CI seem okay here, this change feels a bit like we'd be pushing it 😞
@addaleax Sounds good, I can look into ways we could put this into the larger plan and see what we could come up with. Sorry, might have been meaningful to have more discussion about this earlier, I just figured after talking with Atlas CLI folk that we'd likely end up in some form of machine ID-powered setup anyways unless we'd like to push them to adopt the alternative instead. And potential of having to deal with directory permissions or whatnot seemed like a good enough argument against the shared directory idea. But yeah about |
Yeah, I'm also happy to support this in any way I can, overall I'd expect it to be somewhat straightforward to put together |
e839252
to
3c99a11
Compare
// to match it exactly with the denisbrodbeck/machineid library that Atlas CLI uses. | ||
const originalId: string = ( | ||
await require('native-machine-id').getMachineId({ raw: true }) | ||
)?.toUpperCase(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(and when you do update, I'd recommend wrapping this in a try/catch, since native addons will not always work in all environments)
/** | ||
* @returns A hashed, unique identifier for the running device or `"unknown"` if not known. | ||
*/ | ||
export async function getDeviceId({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could go inside the class but seems clearer to make it independent of it and avoid tying it to it to potentially even expose it on its own if we have some need for that in the future
f49ea47
to
c904f56
Compare
Going ahead as remaining tests are failing on main. regardless. |
To standardize identification across DevTools and Atlas CLI, this introduces a
native-machine-id
dependency 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.Both libraries use hashing to protect the machine-specific information.
We could using
anonymousId
asdeviceId
as 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 loseanonymousId
altogether. Therefore this instead adds a new identity field for Segment.We're using our own
native-machine-id
library for this as opposed tonode-machine-id
as:To Do: