Skip to content
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

Better opt-in than opt-out for enable_prometheus_metrics #242

Open
jhgoebbert opened this issue Mar 9, 2025 · 2 comments
Open

Better opt-in than opt-out for enable_prometheus_metrics #242

jhgoebbert opened this issue Mar 9, 2025 · 2 comments
Labels

Comments

@jhgoebbert
Copy link

Thank you for this great extension! It is one of the basic extensions in our system-wide JupyterLab installation on multiple clusters and we love it :) Because of that I have very high interest that the following issue is known.

jupyter-resource-usage sets enable_prometheus_metrics = True by default.
But this has a huge impact on the whole JupyterLab installation:

At the moment jupyter-resource-usage is overloading tornado's task-pool for the prometheus- (and the cpuload- feature (?) ) without taking into account that this will result in less (or even worst) performance for the critical webserver.

We had a big issue with our server-proxies started via jupyter-server-proxy as we saw a significant performance degradation which was extremely time consuming to track down in a complex cloud environment. The remote desktop integration Xpra was showing stuttering effects ( jupyterhub/jupyter-server-proxy#494 ) and the robustness of web socket connections in general were affected at multiple places.

We were looking in all directions (NGINX, JupyterHub, Kubernetes, OpenStack, Network, JupyterLab, jupyter-server-proxy, etc) but unfortunately the last we had in mind was jupyter-resource-usage.

We are fine now as we have changed our jupyter-resource-usage's config of course. But other users will stumble over the issue in the same way.

This problem has already been discussed in the past here: #123 and an opt-out functionality was implemented here dleen@8c5d477 .

=> I would suggest to change that to an opt-in.

@jhgoebbert jhgoebbert added the bug label Mar 9, 2025
@jtpio
Copy link
Member

jtpio commented Mar 10, 2025

Thanks @jhgoebbert for the suggestion!

This problem has already been discussed in the past here: #123 and an opt-out functionality was implemented here dleen@8c5d477 .

If you feel like opening a PR with this change, that would be great.

At first glance it would indeed make sense to change the default. But since some users may expect the current default, maybe this would have to be released in a 2.0.0 version (unless there are some points for considering this as a minor change).

@jhgoebbert
Copy link
Author

Thank you for your response. I have created a PR here #243

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants