-
Notifications
You must be signed in to change notification settings - Fork 824
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
[MM-60086][MM-60610] Implement performanceMonitor, collect CPU/memory usage data and send via API #3165
Conversation
… usage data and send via API
verified e2e tests locally. No blocking failures. |
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.
LGTM! thanks @devinbinnie
src/main/performanceMonitor.ts
Outdated
view.webContents.send(METRICS_REQUEST, view.name, view.serverId); | ||
}); | ||
}); | ||
await Promise.all(viewPromises); |
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.
maybe here would be good to add some preventive code:
- use
allSettled
instead ofall
so you can handle individual promise rejections (in case one of the promise rejects). - would be good to wrap this line and the following in a
try..finally
, so you can make sure that no matter what the removal of the listener will happen. - should there be a timeout maybe?
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 don't see a case where I wouldn't want the app to be loud about the Promise
failing, so the try/catch
doesn't seem as necessary. However I did want to add the timeout, thank you for reminding me :)
src/main/performanceMonitor.ts
Outdated
} | ||
|
||
const serverMetricsMap = new Map([...metricsMap].filter((value) => !value[1].serverId || value[1].serverId === view.serverId)); | ||
view.webContents?.send(METRICS_SEND, serverMetricsMap); |
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.
no need for optional chaining view.webContents?.send
since it occurs after checking if (!view.webContents)
@@ -83,6 +84,7 @@ export class ServerDropdownView { | |||
// @ts-ignore | |||
transparent: true, | |||
}}); | |||
performanceMonitor.registerView('ServerDropdownView', this.view.webContents); |
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.
nit: for this and all the other registered views, maybe put the names in global constant values.
performanceMonitor.registerView('ServerDropdownView', this.view.webContents); | |
performanceMonitor.registerView(SERVER_DROPDOWN_VIEW, this.view.webContents); |
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 would be worth doing I'd say if we were using these constants in multiple places, but right now they're just labels that get passed along with the data and will only matter once it hits the dashboard, so I'm okay to leave this one as is.
@amyblais Am I okay to cherry-pick this to v5.10 to include in the next RC? |
|
/cherry-pick release-5.10 |
Cherry pick is scheduled. |
… usage data and send via API (#3165) (#3171) * [MM-60086][MM-60610] Implement performanceMonitor, collect CPU/memory usage data and send via API * Translations * PR feedback * Update api-types package (cherry picked from commit 1029516) Co-authored-by: Devin Binnie <[email protected]>
Summary
This PR contains a new module called
performanceMonitor
, which is responsible for:This monitoring will take CPU and memory usage data and send it to servers that have elected to subscribe to the Desktop App for performance data. This data will then be available to administrators via Prometheus.
The idea behind this is to get a better idea of how hard users are getting hit in terms of system resources by various parts of our app. The data is divided up by unique process, so that should give us some idea of which part of the app is causing issues if there is a lot of system resources being dedicated to a process.
Not in scope for this change are load times, which we will calculate and send as part of a separate API created later.
Ticket Link
https://mattermost.atlassian.net/browse/MM-60610
https://mattermost.atlassian.net/browse/MM-60086
Screenshots